[#122] Сниппету TicketComments Добавлен параметр &requiredFields для указания обязательных полей при комментировании. Теперь можно отключить требование заполнения name.
Василий, подскажи, а как отключить это требование. Если я выставляю &requiredFields=``, то получаю ошибку:
field: null
message: "Это поле обязательно."
Это потому, что в процессоре web/comment/create.class.php проверки на пустое значение нет.
Дальнейшие доработки ведут к изменению ядра Tickets. Костылями подпирать — путь тупиковый. Выход один — делать самостоятельное дополнение без привязки к Tickets, со своей админкой и т.п. А это уже совсем другая песня.
В данном случае, пользователю приходит письмо с сайта. Он может ответить на него и прислать дополнительные данные. А менеджер, который рулит почтой, вносит необходимые данные в заявку.
А делать еще и полноценный почтовый интерфейс, мне кажется, это лишнее.
Мы несколько раз в год ездим на разные базы отдыха уже несколько лет. Ни разу не общались по почте. Всегда только по телефону. Вот как я понимаю, процесс на своем многолетнем опыте.
Забронировал через сайт -> менеджер перезвонил -> мы подтвердили -> оплатили аванс -> приехали и на месте оплатили все.
Так работают большинство подмосковных пансионатов и баз отдыха.
А переписка это очень не надежно и долго. Не ответил клиент по почте и что думать? Все равно звонить надо.
2 сезона потянет (вернее две разных цены), а вот больше нет.
Например, берем 2 сезона по месяцам — июнь и июль.
У нас есть 2 цены — текущая и специальная. Текущая действует в июне, а спец. цена начинает действовать в июле. В августе опять начинает действовать текущая цена (третью цену определить нельзя). Тогда все посчитается правильно и на стыках и так. А если в августе нужна другая спец. цена, то надо ждать когда июнь кончится, тогда и определить цену августа. Только так.
Только вот платность любых мало-мальски полезных компонентов напрягает, наверное поэтому modx.com не делает платных репов, не хватает в последнее время альтруизма в разработчиках)
Ну не знаю, меня не напрягает. За хорошую вещь совсем не жалко заплатить — отблагодарить автора. Это еще и стимулирует автора поддерживать и развивать продукт. Вот например, в modx.com сколько уже мертвяков висит. Тот же HitsPage или modxTalks давно уже не поддерживаются. Тем более, что есть бесплатная альтернатива (более 600 дополнений на modx.com), а стоимость символическая — это тебе не 79 евро у modmore.com. У modstore.pro дороже 2 тыс. дополнений нет. Тем более, что дополнения покупаются как правило не для себя, а для заказчика и за деньги, за немалые причем :)
Я с минишопом пока не знаком. В планах разобраться и если получится, прикручу. А вот с остальным — это уже только в новом компоненте — с почасовым бронированием, сезонами, правами, интерфейсами для администраторов во фронтэнде.
В данном случае, если сезоны идут последовательно, то их можно указывать последовательно — новый сезон выставлять по окончании старого.
А Я.Метрика и Google Analytics так тоже могут?
А выводить количество текущих пользователей на сайте?
А вести аналитику по ресурсам?
Может я отстал и все это уже есть?
Я не заставляю никого его устанавливать. Пользуйтесь Я.Метрикой и Google Analytics, кто ж мешает.
Это потому, что в процессоре web/comment/create.class.php проверки на пустое значение нет.
Получаю
И за документацию отдельное спасибо.
А делать еще и полноценный почтовый интерфейс, мне кажется, это лишнее.
Забронировал через сайт -> менеджер перезвонил -> мы подтвердили -> оплатили аванс -> приехали и на месте оплатили все.
Так работают большинство подмосковных пансионатов и баз отдыха.
А переписка это очень не надежно и долго. Не ответил клиент по почте и что думать? Все равно звонить надо.
Ну если очень нужна именно переписка, то oneBooking не подойдет. Там только односторонняя связь для уведомления пользователя.
А авторов можно и вручную посчитать: 1, 2, 3, 4,...., 22.
Например, берем 2 сезона по месяцам — июнь и июль.
У нас есть 2 цены — текущая и специальная. Текущая действует в июне, а спец. цена начинает действовать в июле. В августе опять начинает действовать текущая цена (третью цену определить нельзя). Тогда все посчитается правильно и на стыках и так. А если в августе нужна другая спец. цена, то надо ждать когда июнь кончится, тогда и определить цену августа. Только так.
Ну не знаю, меня не напрягает. За хорошую вещь совсем не жалко заплатить — отблагодарить автора. Это еще и стимулирует автора поддерживать и развивать продукт. Вот например, в modx.com сколько уже мертвяков висит. Тот же HitsPage или modxTalks давно уже не поддерживаются. Тем более, что есть бесплатная альтернатива (более 600 дополнений на modx.com), а стоимость символическая — это тебе не 79 евро у modmore.com. У modstore.pro дороже 2 тыс. дополнений нет. Тем более, что дополнения покупаются как правило не для себя, а для заказчика и за деньги, за немалые причем :)
В данном случае, если сезоны идут последовательно, то их можно указывать последовательно — новый сезон выставлять по окончании старого.
А выводить количество текущих пользователей на сайте?
А вести аналитику по ресурсам?
Может я отстал и все это уже есть?
Я не заставляю никого его устанавливать. Пользуйтесь Я.Метрикой и Google Analytics, кто ж мешает.
Это просто шутка :)