Хотелось бы поделиться эмоциями по кастомизации стандартного календаря событий от Битрикс. По форуму видно, что многие сталкиваются с его ужасно разработкой, но после испытанного нельзя было это держать в себе.
Клиент представлял из себя фотостудию с большим стаффом фотографов. При первом разговоре ему требовалось два календаря с похожим функционалом, но некоторыми отличиями. В данной статье речь пойдет только о первом, а в большей степени о стандартном календаре Битрикс. И так требуется календарь с наглядным отображением съёмок и информации по ним: менеджеры, фотографы, визажисты, сюжет и т.п. Так же была необходима фильтрация по менеджерам и некоторым свойствам. На первый взгляд всего лишь изменён шаблон, добавлены поля и фильтр. Зная архитектуру Битрикс, это не должно было составить трудностей. Так сильно я ещё никогда не ошибался.
Естественно на этапе полного построение ТЗ появилось ещё множество необходимого функционала:
Ограничение по количество съёмок/событий в день (15 шт) (количество созданных съёмок должно отображаться в правом нижнем углу ячейки; если 15, то создание события запрещено)
Ограниченное количество сюжетов в день (у каждого сюжета своё количество) (событие/съёмка представляет собой строку с названием сюжета и числом их оставшегося количества, т.е. при если в этот день добавляется событие с таким же сюжетом, то дополнительная строка не появляется (как в стандартном календаре Битрикс), а просто должно уменьшаться их доступное количество в этот день)
В календаре дни с понедельника по пятницу
“Проблемы всегда возникают задолго до того, как мы их замечаем.”
Теперь к самой разработке и проблемах, с которыми мы столкнулись, а так же их решениями. Некоторые решения у нас были недостаточно гибкими и являются костылями для решения той или иной задачи, но у нас не стояло цели сделать гибкий функционал под любую сферу деятельности. Конечно, теперь в дальнейшем мы задумались о гибкой настройке и будем переписывать с дополнительными свойствами и функционалом, чтобы пользователи смогли сами кастомизировать календарь под свои нужны. Как раз ближе к этой реализации мы выпустим продолжение темы текущей статьи.
Календарь предназначен для возможности определения оставшегося количества съёмок в определённый день, а так же оставшееся количество съёмок с определённым сюжетом. Основное требование это максимально быстрая оценка данных и максимально просто создание нового сделки вместе с событием. Это одна из проблем. Заказчик хочет в календаре иметь сделку, а не событие, как сделано в стандартном календаре Битрикс. Первая проблема, что при создании события нет полей, которые необходимы для создания сделки. В первоначальном диалоговом окне можно лишь ввести название, выбрать занятость и календарь, в который нужно занести событие. При нажатии на кнопку редактировать появляется более дополненный вариант создания. Можно уже внести описание, выбрать участников и даже прикрепить любой элемент CRM, т.е. мы могли прикрепить нужную нам компанию и т.п. для того, чтобы как раз создавать сделку.
Т.к. переписывать компонент или модуль является почти последним вариантом решения задач в Битрикс, мы сразу поняли, что оптимальным вариантом будет использовать события модуля календарь. Конечно, их было не так много, но благо было нам необходимое OnAfterCalendarEventEdit. Ивент вызывался после создания события в календаре, можно было используя его поля создавать сделку в crm (CCrmDeal::Add). Достаточно хороший вариант, но надо было как-то хранить информацию о связи сделки и события. Как вариант таблица в БД, но исключая прямые запросы к БД, решили просто сделать свойство у сделки, в которое записывается id события.
Спасибо за описание , если откинуть эмоции на "НЕДОЧЁТ" разработчика, хорошая инструкция к кастомизации календаря.
Концепция продукта понятна и проста - есть как то написанный функционал, который нужен только как галочка о наличии при сравнении с другими решениями. Календарь не уникальная фишка Битрикса, поэтому от просто есть в портале. Но пока есть коробочная версия в наших силах любую такую "галочку" сделать фишкой наших проектов. Спасибо разработчику, что оставили нам такую возможность.
Видим что используется компонент bitrix:system.field.edit, к которому, конечно, нет документации и толком не понятно какой шаблон будет использоваться т.к. вместо него подставляется значение из массива с ключами USER_TYPE – USER_TYPE_ID.
Тут вопрос философии . Если к документации относится как набору вопрос для указания пути развития , то концепция её написания становится очевидна. Жаль конечно потерянное время когда - написано одно по факту другое. И немного обидно когда параноидальное недоверие к документации впитывается в начале карьеры. Но Роберт Басыров старается, очень стараются, просто это жутко сложно .
ПОИСКОВЫЙ МЕТОД один из активных методов обучения, заключающийся в том, что изложение учебного материала преподносится как проблема, требующая от обучаемых самостоятельного разрешения или «открытия», которое нужно сделать им самим. Поисковый метод обеспечивает вовлечение учащихся в процесс самостоятельного приобретения знаний, сбора и исследования информации (см. также Поисковая учебная деятельность).
Дышите ровно, ошибки других добавляют уверенности в своих силах.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».