Mark

может проблема в самом php
ini_set('session.gc_maxlifetime', 86400);
ini_set('session.cookie_lifetime', 86400);
если хостинг не Ваш то можно еще воспользоваться:
ini_set('session.save_path', $_SERVER['DOCUMENT_ROOT'] .'../sessions/');

Конечно, каждый решает сам, тут стоит учесть, что вычислительные мощности налоговиков растут, разбирать и сопоставлять транзакции становится проще. Кроме того, если не ошибаюсь, с января 2018 года РФ подписала соглашение об обмене транзакционными данными, например, с США, а значит это немного, но уже бросает тень, например, на Payoneer. Конечно, лимит до 600 т.р. ,чтобы привлечь внимание банковского контроля, пока не отменяли, да и небольшие хаотичные транзакции скорее не интересны, но все меняется. Прецедентов с блокировкой звучит все больше, ну и в целом, судя по состоянию экономики в стране, фискальная политика будет только крепчать. Кстати, есть знакомая из Сбера, они действительно обкатывают новые решения по обнаружению подозрительных транзакций...а дальше действует, как и со штрафами на дороге, чистейшая презумпция виновности - налоговая решает, что вы что-то недоплатили..банк что-то блокирует, бегите доказывайте, что не осел. Все зависит от суммы, регулярности... налоговая и банк могут несколько вольно это трактовать. В общем, решайте сами, лично я ИП.

Нужно засабмитить майлстоун с работой и через 2 недели деньги разлочатся. В остальном забить и просто ждать.

Никак. Не отдавайте ему работу, пока не объявится. Подписавшись на fixed price, вы взяли на себя такой риск.

Заказчики - занятые люди и у них бывают дела поважнее. У меня были случаи, что заказчик пропадал на 3 месяца, а потом внезапно объявлялся и работа продолжалась.
В общем, отложите в дальний ящик и берите другой проект.

Лучше коворкинг. Там все вопросы уже решены.

для отключения любого поведения можно вызвать
$model->detachBehavior('behaviorName');
Для этого надо указывать behavior c именем

public function behaviors()
    {
        return [
           'behaviorName'=> [
                'class' => IndividualServicePriceBehavior::className(),
                /// ,,,
            ],
        ];
    }

В принципе кеширование - логично, если индивидульные цены назначаются/меняются не так часто.
Но не совсем понятна структура ваших таблиц , возможно вместо поведения уместнее будет использовать обычную реляцию

<?php
$arr1 = [
'key1' => 'val1',
'key2' => 'val2',
'key3' => 'val3',
];

$arr2 = array_intersect_key($arr1, array_flip(['key2', 'key1']));
var_dump($arr2);

По гуглите на тему "троллинг".

Многие оценивают php с колокольни своего языка, и увидев, что задачи этого самого языка решаются лучше, чем на php - делают вывод, что php - гуано. Например:
* вот, на nodejs легче делать чаты, посему php - гуано.
* вот, на QT + C++ легче делать десктопные апликухи, а php c qt - хренов, посему php - ...
* вот на яве вот, прям правильное ooп, а в php - ...
* вот демона сделать на php - геморно посему php - ...
Чаще всего это банальная не компетенция, либо НЕ целевое использование.
Если вас напрягает такое отношение - спросите, сможет ли человек любым способом сделать сайт-админку с обычным CRUD-ом моделей, например для 10 таблиц за пол часа, на языке, которым он любит обмазываться. Если таки сможет - просто игнорьте его аргументы, если не сможет - поздравляю, вы победитель в споре, но он будет игнорить ваши аргументы))

->orderBy('some_field ASC')
sql order by

Имеем 4 колонки на kanban-доске:

1. Список заданий
   
2. В процессе
   
3. На проверке
   
4. Исполнено
   

Теперь о каждом чуть более детально.

Список задач, он же backlog - список того, что вообще надо сделать. Сортируется это дело по приоритетам, т.е. самая верхня задача самая важная, самая нижняя - самая не важная. Отдельно отмечу, что только в данный момент времени. Отметок "Важная", "Важная 1", "Важная 2", "Срочная", "Горящая" и т.п. быть не должно. Если задача есть в этом списке, значит она важна для команды. Ее исполнение необходимо для нормальной работы команды. Акцентирую Ваше внимание, что именно в данный момент. Как тимлид Вы можете сделать только одну доработку в этой колонке - присвоить цвет каждому подчиненному. Например, Иван берет только синие задачи, Николай только желтые и т.п. Срочнось задач в компетенцию тимлида не входит, это зона ответственности менеджмента.

В процессе - задачи, над которыми именно сейчас работают Ваши подчиненные. Не вообще работают, а вот конкретно в данный момент, когда Вы открывайте доску и смотрите на нее, Ваш человек сидит в IDE и пишет/отлаживает код. Колонка обязана иметь лимит. Все книжки рекомендуют начинать с 2n - 1, где N - количество людей в команде, а минус 1 потому что кто-то может с чем-то застрять и ему надо будет помочь. Порядок задач в этой колонке не важен. Важно только то, сколько они там находятся. У Вас должно быть какое-то время реагирования, т.е. если задача висит там 3-й день, то нужно спросить условного Николая, что у него там за проблема и не нужно ли ему там с ней помочь. Часто, это колонка разбивается на на две: в процессе и отложено. Вторая означает, что когда исполнитель начал работу над задачей, он не нашел, скажем, доступа к хостингу или данные к FTP/cPanel, предоставленные клиентом, оказались не верными. Колонка "Отложено" требует уже реакции менеджеров в духе "Звонок клиенту". Задачи от колонки "Отложено" менеджеры должны обрабатывать, дополнять и перемещать снова в backlog. Продуктовые команды, обычно, такую колонку не используют. Разного рода digital-агенства применяют это очень часто.

На проверке - думаю, из названия понятно. Ваш подчиненный завершил задачу, Вам/Менеджерам/Клиенту надо ее проверить. В эту колонку задачи могут переносить Ваши подчиненные, но из нее переносить задачи могут только менеджеры или Вы.

Исполнего или Готово - опять же, думаю понятно. Завершенные задачи. В конце рабочей недели по наполнению этой колонки можно оценить продуктивность команды или/и продуктивность конкретного разработчика, если Вы будите использовать схему "Человек - Цвет". Карточки из этой колонки отправляются в архив в пятницу в 19:00 или когда Вы там выгоняйте всех программистов из-за мониторов. Также, в конце каждой недели, должен чиститься backlog от более не актуальных задач. Помните что я писал выше? В первой колонке у нас только важные задачи, которые необходимы именно в данный момент. Если клиент "заглох" или "слетел" - его задачи из backlog должны быть отправлены в архив, вместе с завершенными задачами в пятницу в 19:00

Отдельно отмечу, что появление задач с метками "Важное 1", "Срочное", "Очень-Очень срочное" в любой системе управления, не только scram/kanban, говорит о том, что в компании слабый менеджмент. Есть задача. Ее либо надо сделать прямо сейчас или в ближайшее время либо ее нет смысла делать совсем.

Следует также помнить, что замена менеджмента и/или системы управления, ровно как и изменения в ней, должны исходить от собственика/директора либо при его одобрении и полной поддержки. В противном случае это очень быстро все заглохнет, окончившись не чем. Каким образом Вы донесете эту необходимость до своего Босса - уже вопрос отдельный.

Одним запросом это сделать не возможно. Owner_id должен быть целым числом, т.е. содержать всего 1 значение. Иначе выдаёт ошибку "error_msg": "One of the parameters specified was missing or invalid: owner_id not integer"

Решается с использованием нескольких запросов в цикле

Что и как тестируют ???.... простым языком.... смотрю про тестирование, мне кажется там больше заумной терминологии чем реальной работы

Да нет, там как раз все просто. Грубо говоря есть три уровня:

• "Делает ли эта функция то, что должна?": Мы (как тестировщики) знаем, что функция делает внутри себя, и убеждаемся, что она продолжает это делать и в будущем. Это именуют модульным или юнит-тестированием. В маленьких проектах обычно его не делают или покрывают такими тестами только определенные части проекта. Помогает оперативно находить изменения в поведении существующих модулей, которые так могут долго оставаться незамеченными и потом не понятно, что вызвало поломку. По идее такие тесты должны в автоматическом режиме проходить перед сборкой кода для продакшена.
  
• "Работают ли несколько модулей вместе так, как задумано?": Мы не знаем, что происходит внутри связки, но знаем, что есть на входе и что должно быть на выходе. Это именуют интеграционным тестированием. По идее оно помогает находить проблемы на стыке модулей, когда поведение одного модуля поменяли, а про другой забыли. В реальном мире встречается не так часто, т.к. требует включения мозгов для написания тестов.
  
• "Решает ли система задачи пользователя?": Это по-разному называют. Тут идет работа от ТЗ. Мы знаем, что должен получить пользователь от готовой системы в ответ на свои действия, но как она работает внутри нам фиолетово. Наиболее понятный сценарий такого тестирования - заранее написать кейсы, примеры того, как пользователь решает какую-то задачу, а потом перед каждым релизом "прокликивать" нужные последовательности кнопок или что-то вроде того. Это могут делать руками (студенты-обезьянки) или можно автоматизировать. Посмотрите примеры использования CodeceptJS и все станет ясно. По-хорошему это стоит делать на проектах любого размера, но на практике...
  

Еще есть точечные тестирования, которые делают далеко не всегда и они как-то сами по себе существуют. Например проверка производительности или безопасности системы. На небольших проектах таким практически никогда не занимаются.