Leaderboard

теоретическая часть. мы подаем заявку. заявка имеет отличительный признак-метку client/order/zayavka. На данный момент это имя модели. приложение ищет нужную модель. получает по ее структуре данные из запроса. по этой модели проверяет обязательные поля. это первый этап. далее, если существует физическая таблица такой модели, то заявка на основании модели сохраняется в нее. если нет, то не сохраняется. на соновании полученных из запроса данных (именно их. так как заявка только подана, то даже если таблица есть, то ид в запросе этой заявки нет. поэтому и не фиксировались первичные ключи заявки в резюме заявки в приложении Клиенты) формируется табличный вид данных заявки - резюме - то, что вы виите в Клиенты, если нажать Подробнее. Но, так как присоединенные элементы (картинки, доки) связываются с объектом после его сохранения, а резюме заявки для Клиенты формируется на основании данных запроса (а не данных заявки из ее таблицы), пусть даже после сохранения заявки, то доков и картинок в резюме нет. форма гостевого добавления, работает почти так же, но, перед формированием письма админу, она "поднимает" заявку из БД, уже с связанными картинками и доками. так же следует помнить, что резюме заявки и сама заявка в своей таблицы не связаны. и то, что формировщик табличного вида модельки для заявки может обрабатывать не все относительно новые поля. для того, что бы в Подробнее в Клиенты отображались все элементы заявки, включая картинки и доки я готовлю обновление.

DDOS - надо решать на уровне провайдера. Серьезный DDOS - не атакует обычные порты HTTP, там все на низком уровне TCP, поэтому заморачиваться таким для нашей cms нет смысла.