Здравствуйте,
Повторяющиеся события являются отдельными событиями, однако при их создании не создаются отдельные темы.
Таким образом, если вы нажмете на одно из повторяющихся событий, чтобы принять в нем участие, то ваше участие будет отображаться во всех событиях.
Не должно ли создание повторяющегося события приводить к созданию отдельных событий/тем с той же базовой информацией, что и у первого события?
Это скорее запрос на новую функцию. Я вас понял: было бы здорово, если бы можно было выбрать конкретное событие в последовательности.
Есть ли какие-то успехи в этом вопросе?
Нам действительно необходимо создавать новую тему для каждого события, а не использовать одну тему события для управления множеством событий, отображаемых в календаре.
В данный момент единственным жизнеспособным обходным путём является ручное создание множества новых тем. Это, конечно, самым раздражающим образом заполняет ленту «Последние» (что как-то нужно смягчить), а также требует осторожности, чтобы не рассылать слишком много уведомлений. Я думаю, это подчёркивает некоторые из сложностей, связанных с реализацией этой функции.
Было бы приемлемо, если бы второстепенные события в теме имели другой внешний вид, например, контур, через eventBorderColor и eventBackgroundColor?
Вы имитируете наложение, комбинируя:
| Свойство | Первичное (подтвержденное) | Второстепенное / предварительное |
|---|---|---|
| eventBackgroundColor | сплошной цвет | другой / светлый |
| eventBorderColor | совпадает с заполнением | сильный контраст |
| стиль границы | сплошная | пунктирная |
| непрозрачность | 1 | 1 |
Это создает визуальную иерархию без необходимости реального наложения.
Милая идея, но я не думаю, что этого будет достаточно — каждое событие в серии действительно требует отдельного подтверждения участия, дополнительной информации и обсуждения.
RSVP будет заменён на опрос, поэтому все события в теме станут автономными. Все события будут посвящены одной и той же задаче: согласованию времени из множества вариантов.
Это не серия мероприятий и не то, что можно реализовать в Outlook.
Именно эта особенность заставляет такие учреждения, как мой университет, отказываться от защитных, но ложных серий в Outlook в пользу Discourse.
Возвращаюсь к этому вопросу после использования обновленного плагина в последние несколько месяцев; теперь, когда у нас появилось больше вариантов повторения событий, он работает довольно хорошо — особенно возможность задавать «N-й день месяца» и возможность RSVP как на отдельное событие, так и на всю серию.
Однако ключевая проблема остается: архивирование контента последнего события.
Сценарий использования: повторяющееся событие, к которому прикреплено довольно много постов и обсуждений. Сюда могут входить вложенные файлы и изображения. Самый очевидный пример — регулярное рабочее совещание.
В настоящее время этот хаос необходимо как-то упорядочивать вручную, поскольку функция повторения просто меняет дату события и сбрасывает RSVP. Ручные варианты действий:
К сожалению, ни один из этих вариантов не идеален.
Я хотел бы, чтобы функция повторения сохраняла текущую тему события в неизменном виде, но после его завершения плагин создавал новую тему для следующего события.
Это позволило бы сохранить удобную структуру и автоматически обеспечило бы сохранение подходящего архива прошедшего события, а также предоставило бы «чистую» тему для нового события.
Ценой за это (помимо повышенной сложности) станет то, что активное событие будет иметь новый URL. Я могу представить, что в некоторых случаях это может стать проблемой.
Привет! Это означает, что вам нужно будет ждать закрытия текущего события из серии повторяющихся событий, прежде чем вы сможете подписаться на следующее?
Большинство плагинов событий, с которыми я работал в Joomla, создают серию событий напрямую, в отличие от вашей идеи, которая предполагает создание отдельных тем/URL для каждого события. Я считаю, что такая модель правильная.
Также было бы удобно дать возможность запретить подписку за X дней до начала повторяющихся событий.
Что касается архивирования: разве события обычно не размещаются в собственной подкатегории или не имеют тегов, чтобы их можно было группировать и применять к ним автоматические действия?
Да, но это не отличается от текущей ситуации, когда вы можете ответить на приглашение либо на текущее событие, либо на всю серию.
Вы имеете в виду действие по клонированию события и перемещению ответов, или что-то подобное? Возможно, Workflows могут это сделать; я как раз собирался разобраться с этим.
По моему опыту работы с событиями, подтверждение участия во всей серии используется реже, чем возможность подписаться на конкретное событие, которое пройдёт позже в серии. Хотя оба варианта важны.
Да, однако в моей установке я не вижу ни одного рабочего процесса, который бы это выполнял.
Возможно, это отдельное предложение по функционалу, которое выходит за рамки темы событий, и я мог/должен был создать для этого отдельную тему.
Нам понадобится действие автоматического архивирования, которое запускается при определённых условиях; в данном случае это было бы, если «дата события или дата окончания (если она указана)» уже в прошлом или тема закрыта уже x дней, возможно, с настраиваемой задержкой перед выполнением действия, чтобы тема события оставалась видимой для комментирования людьми в течение нескольких дней после события.
Здесь уже есть определённый прогресс.
Триггер Event ended для Workflows уже был объединён в основной код:
https://github.com/discourse/discourse/pull/42634
Кроме того, в Workflows уже есть действие Topic, которое позволяет Get (получить) существующую тему и Create (создать) новую, а также есть узел Wait (ожидание). Таким образом, значительная часть предложенного процесса переноса уже может быть реализована в виде рабочего процесса, а не требовать создания отдельной функции архивирования, специфичной для событий.
Что-то вроде:
Event ended → Wait → Topic / Get → Topic / Create
потенциально могло бы создать новую тему, используя название, содержимое и категорию старой темы, при этом завершённая тема оставалась бы нетронутой в качестве архива.
Что ещё нужно проверить, так это то, какие именно части старой темы должны копироваться автоматически — например, теги, загруженные файлы, состояние повторения события, а также следует ли перемещать ответы или просто оставлять их на месте.
У меня также есть открытый PR, вводящий действие Event в Workflows:
https://github.com/discourse/discourse/pull/42932
Базовый PR добавляет Close event (закрыть событие) и Open event (открыть событие), а у меня есть следующий PR, наложенный поверх него, добавляющий Set attendance (установить посещаемость):
https://github.com/discourse/discourse/pull/43028
Действие структурировано так, чтобы в будущем можно было добавлять другие операции, специфичные для событий, в виде отдельных PR, если это будет уместно.
Хорошая работа, спасибо. Условия закрытия могут быть полезны, но не всегда полностью применимы к исходной ситуации.
Категория событий может стать очень объёмной, особенно при наличии повторяющихся событий, и было бы разумно предусмотреть способ автоматического архивирования/перемещения любого закрытого события (темы), закрытого более x дней назад, в категорию прошлых тем или в архив.
Но этот вопрос архивирования зависит от решения о том, должны ли повторяющиеся события становиться отдельными темами, связанными с основной темой события.
Я открыл PR, реализующий это как опциональный режим повторяющихся событий (recurring Event mode):
Он добавляет настройку сайта discourse_post_event_recurring_topic_mode с двумя вариантами:
reuse_topic — существующее поведение и значение по умолчаниюcreate_next_topic — сохранить топик завершившегося вхождения (occurrence) и создать новый топик для следующего вхожденияПри использовании create_next_topic, когда вхождение завершается, его топик сохраняется, а событие закрепляется за этим завершившимся вхождением, при этом повторение удаляется. Затем для следующего повторения создается последующий топик (successor Topic), сохраняющий исходный заголовок, тело сообщения, категорию, теги и автора, при этом даты события продвигаются вперед.
Автоматические тесты также покрывают семантику переноса ответов (RSVP rollover): статус присутствия going для повторяющихся событий переносится в последующий топик, тогда как разовые ответы остаются в топике завершившегося вхождения.
Процесс переноса также является транзакционным, поэтому, если создание последующего топика не удастся, вхождение останется в ожидающем состоянии (pending) и его можно будет повторить, а не оставить в частично завершенном состоянии.
Это конкретно реализует модель «создать следующий топик, когда текущее вхождение завершается». Он еще не генерирует отдельные топика для всех будущих вхождений заранее, что является альтернативной моделью, упомянутой выше @opcourdis.
Существующее поведение остается значением по умолчанию, поэтому для сайтов, которые хотят, чтобы топик завершившегося события служил архивом, это опция, которую нужно включать вручную (opt-in).
Спасибо, эта модель уже отлично работает для организаторов, которые теперь могут быть уверены, что им не придётся каждый раз создавать событие заново. Кроме того, она даёт гарантию того, что люди не будут подписываться на события заранее, поскольку организаторы всегда могут отменить мероприятие по определённым причинам.
Модель создания событий заранее, которую я предложил, также работает во многих случаях и дополнит вашу модель преемственности событий.
Кстати, по PR для режима преемственности событий:
1° Люди, которые подпишутся на новое событие, всё ли равно будут получать уведомление о том, что тема/событие является частью серии повторяющихся событий, как и в случае с исходным событием/темой?
2° Автоматическое приглашение первоначальных гостей на событие — это опция «отключить/включить»? Я говорю об этом, потому что будущее событие не обязательно является тем, которое вы всегда хотите продвигать гостям, ведь вы уже продвигали это событие и его серию им один раз через первое событие.
Да, в том смысле, что последующее событие сохраняет настройки повторения. Например, в GUI-тесте на дым (smoke test) исходное вхождение отображало Каждый четверг, а после перехода (rollover) последующая тема также отображала Каждый четверг, но с датой, перенесённой на следующую неделю.
То, чего не добавляет этот PR, — это отдельное отношение серии между темами, связывающее завершённую тему и её преемника. Завершённая тема становится одноразовым архивным вхождением, тогда как преемник несёт на себе функцию повторения. Явное отношение серии/родителя между этими темами может стать отдельным улучшением, если это окажется полезным.
Не каждый гость/участник автоматически переносится в новое событие.
Преемник наследует только тех людей, у которых был статус идут с включённым RSVP для повторяющегося события/серии. Тот, кто ответил идут только на конкретное вхождение, остаётся в завершённой теме и не добавляется в преемника.
Таким образом, в настоящее время существующий выбор ответить на RSVP серии фактически выступает в роли опции opt-in для переноса в будущие события-преемники, а не какой-либо отдельный настройка сайта, управляющая этим процессом.
Вау! Звучит просто потрясающе — и это именно то, что нужно.
Мне очень нравится, как это органично вписывается в существующий функционал.
Как нам правильно попросить проверить наш PR?
И было бы возможным/не слишком сложно упаковать это в виде плагина (на случай, если им пока не интересно это внедрять)?
Спасибо — рад, что это соответствует сценарию использования, который вы имели в виду.
Для ревью PR уже открыт и связан с этой темой. Не думаю, что у меня есть отдельный публичный способ запросить ревью, поэтому, вероятно, самым полезным будет, если люди, которые действительно будут этим пользоваться, добавят реакцию или короткий комментарий в PR, подтверждающие сценарий использования. Я бы не хотел постоянно беспокоить отдельных сотрудников.
Его можно было бы вынести в отдельный плагин, хотя это было бы не совсем тривиально. Реализация уже полностью находится внутри встроенного плагина events, но она изменяет существующий путь обработки перехода даты запланированного события на следующий день, а также добавляет сервис преемственной темы. Внешнему плагину пришлось бы подключаться к этой части events или переопределять её, что сделало бы его более хрупким при изменениях в основной кодовой базе.
Поэтому моя позиция такова: сначала посмотреть, будет ли принят PR в основной репозиторий. Если его не примут, или если он, похоже, будет оставаться неоткрытым долгое время, выделение в отдельный плагин могло бы стать возможным запасным вариантом.
Поставил реакцию и оставил комментарий! Не уверен, что это сильно поможет, но сделаю, что в моих силах.
Это вполне логично. Хотя всегда полезно иметь «план Б»!!
@Ethsim2 Мы посмотрим на ваш PR и базовую функциональность и скоро вернёмся с дальнейшими шагами!