что-то мы ушли вбок и сделали красивше действие по архивации проекта (хотя на самом деле не уверены .что при архивации стоит закрывать все в проекте).

Теперь главный вопрос, так будет ли обновляться дата проекта при редактировании его самого, например его архивации?

А если мы просто редактируем проект, нужно ли нам обновлять его дату?

• согласно неймингу атрибута - да, безусловно
• согласно бизнес-идее совсем не обязательно, атрибут нам нужен показывать над чем идет работа, а настройка проекта не работа над ним, как ни странно

tndt-106 поправили уже самостоятельно, переводя php в нужную временную зону.

В tndt-108 поправили taskSettings и теперь эта ошибка всплыла. Надо делать

По хорошему в этой задаче в принципе избавиться бы от @Timestampable, @Blameable, ничего хорошего они не несут. Кстати это решит и задачу tndt-106 так как там @Timestampable берет не ту дефолтную таймзону, что и new DateTime(), из-за чего возникает расхождение.

И тут мы вновь приходим к диллеме.

• Либо у нас появляется слой моделей, и сущности в него перегружаются вместе, с десериализацией запакованных в них объектах. (из-за чего мы дублируем все (или многие) сущности моделями)
• Либо мы считаем сущности тупыми dto и их подобъекты храним как-то отдельно.

Причем никто специально Project не дергает. Просто мы подменяем taskSetting из базы десериализованным объектом. Это вобще-то весьма плохо, и надо это убрать, а потом уже самостоятельно евентами обновлять проект

Есть подозрение, что проект не обновляет время специально, а зачем-то кем-то обновляется TaskSettings, что и приводит к обновлению updated

Раз часть действий обновляет, а часть нет, давайте минимально пока просто будем апать project.updated, а вычисление за счет last activity оставим к моменту его введения

Вобще некоторые действия, например появление или обновление в нем задач время проекта обновляет, и в список их вытаскивает, а создание документов - нет.

Хотел тут написать, что ждать систему активностей не надо, а

• надо вешать листенер не на onFlush, а на набор бизнес-евентов которые мы считаем достаточно серьёзными для обновления даты проекта. - Create/Edit/Close Task, Create/Edit/Archive Doc, ChangeSetting, и т.д.
  • как-то неэффективно делать save сущности проект при каждом изменеиии, которых будет много
• вешаться на не бизнес-евенты, а в принципе брать дату обновления через ledtJoin Activity order By activity.updatedAt DESC.
  • делать leftJoin при выборке проектов, и сортировать выборку по результатам join может быть совсем не оптимально, а делаем этот запрос мы куда чаще, чем нам кажется, например на каждой странице в дроп-довн выбора проекта. (Впрочем его можно кешировтаь)

Слушать целую кучу сущностей и вместе с ними обновлять проект не очень оптимально, лучше дождаться появляения системы активности, и не обновлять дату проекта, а просто читать проекты с join на активность и сортировкой по дате последней активности. Система активности все равно сама будет следить за изменениями всех сущностей, которые мы считаем полезной работой над проектом.