Datarange_piker - период "последние 30 дней" превращается в кастомный

Баг-трекер Недостаточно информации
1

В продолжение темы

Значит сделал я все так, как там описал. И вроде бы счастье. Но не могу же как нормальный человек, вечером оставляю комп включенным (сон), чтобы утром продолжить работу. И вот. Весь день работал с этой страницей с выставленным периодом “Последние 30 дней” например с 15.06 по 15.07. Эта страница и осталась открытой. На следующий день (16.07) прихожу, прохожу авторизацию, и понимаю, что не вижу заказов, которые точно есть! А почему? А потому, что в пикере период “Последние 30 дней” превратился в “Пользовательский” с 15.06 по 15.07. То есть определяющими стали даты периода, а не сам период?
Далее. Сегодня.
Вчера я также работал в периоде “Последние 30 дней”. Но закончил работу на другой странице. Сегодня авторизовался с переходом на страницу с пикером, и, о чудо!, период остался “Последние 30 дней”! Но на самом деле думаю тут как раз никакого волшебства - сработала та самая строчка в начале кода,
так как через запрос никакие даты не передаются, а сессия давно закончилась.

Вобщем-то, если для дашборда - пофиг, но если пользоваться пикером на других страницах - неудобство выростает до степени геморроя

1 лайк
2

Здравствуйте, @alex_vp

Спасибо за ваше сообщение.

Не совсем понимаю, в чем проблема. Период называется “Пользовательский” и сохраняет выбранное пользователем значение до следующего изменения этого значения.

Уточните, пожалуйста, какое поведение вы ожидаете от данного периода.

3

Добрый день! Период называется “Последние 30 дней”. Но почему-то в отличие от периодов “Последний месяц”, “Текущий месяц” и прочих ( когда в сессии сохраняется time_period

fn_set_session_data('dashboard_selected_period', serialize(['period' => $_REQUEST['time_period']]));

)
период “Последние 30 дней” приравнивается к “Пользовательскому” и сохраняется как

        fn_set_session_data('dashboard_selected_period', serialize([
            'from' => $time_period['from']->format(DateTime::ISO8601),
            'to' => $time_period['to']->format(DateTime::ISO8601),
        ]));

То есть если это все остальные периоды - в сессию пишется соответствующее значение из DateTimeHelper.
Но если это DateTimeHelper::PERIOD_MONTH_AGO_TILL_NOW - то ведет он себя как CUSTOM

Я ожидаю, что если я выбираю период “Последние 30 дней” сегодня, и сегодня он мне показывает с 3.09 по 2.10, то завтра когда я открою эту страницу, то увижу с 4.09 по 3.10. Послезавтра - с 5.09 по 4.10.

На данный момент - если сегодня я выберу период “Последние 30 дней” и период будет с 3.09 по 2.10, то завтра период так и останется с 3.09 по 2.10, только именоваться станет “Пользовательский”.

2 лайка
4

@Asya , передайте разработчикам, чтобы не ждали, когда я сам решу проблему и выложу им решение )) я не выложу :laughing:

Хотел привести пример на других платформах, но что далеко ходить? мы выбираем период Сегодня, и завтра как ни странно период так и останется “Сегодня” и будет показывать текущий день, то есть завтра - завтра. Текущий месяц - аналогично. Текуший год - 31 декабря показывает выборку за весь текущий год, и вот наступает полночь, обновляем страницу, период остался “Текущий год” - и мы видим выборку за 1 января, текущего года, разумеется.
Аналогичного поведения ожидаешь от периода “Последние 30 дней”. Но нет… тут логика дала какой-то сбой. Точнее, у программиста оказался непроработанный алгоритм, и вместо того, чтобы его проработать до конца и закрыть вопрос, программмист закрыл вопрос тем, что сделал затычку из периода.

Период “Последние 30 дней” при этом является наиболее удобным периодом для работы, так как с теми же заказами имеем дело максимум в этом периоде - получение, обработка и доставка заказов очень редко занимают больше месяца. При этом период “текущий месяц” не может быть ему заменой - так первого числа каждого месяца у нас вообще не будет никаких данных на дашборде…
В конце-концов, посмотрите дашборды любого крупного маркетплейса. Везде (!) графики и данные показываются за период(ы) с возможностью переключаться между ними - последние 7, 14, 30 дней.
У CS-Cart свой путь?

4 лайка
5

На главной Карта дашборд кстати тоже за 30 дней))
Логика такая разная в разных местах))

6

Интересно, а можно тут на форуме создать закрытый канал и выкладывать решения там и чтобы туда не было доступа определенным лицам :rofl:

1 лайк
7

Там логика такая заложена, что периоду назначается последние 30, и затем, если запрошен другой период или есть период, сохранённый в сессии - то заменяется на него.
Тут беда в том, что для периодов “последние Х дней” в сессии сохраняется не буквенное значение периода, а его значение в датах. И вот такая логика программистов и вызывает вроде законный вопрос: Почему?

1 лайк
8

Думаю тут все просто. :slightly_smiling_face: Была задача, сделали логику, обратной связи по этой логике, скорее всего, особо не было, значит можно и не трогать. Если было бы больше обращений, переделали бы конечно. Наверное)

9

99% клиентов будут делать рутинные вещи и не думая, что это можно упростить.
Люди просто каждый раз делают фильтрацию по дате снова и все, знаю как люди чуть ли не с бубном танцуют порой, считая, что это нормально, хотя нужно сделать пару правок и жизнь становится проще в десятки раз.

1 лайк
10

Основное правило cs-cart “не трогай то что и так работает” пусть и не правильно, но работает ))

11

Конечно не было, потому что дашборд тупой и абсолютно неинформативный, работать с ним невозможно, потому что не с чем, а datarange_piker как и dashboard_selected_period - используются только на дашборде.
Я вот переделал себе дашборд, и решил выбранный период использовать на нескольких разделах (дашборд, список заказов, отчеты - которые тоже переделал итд) - и вот тут то и столкнулся…
А так да, с текущим дашбордом то что только на нем используется - никому на фиг не нать

1 лайк