Using the new user update automation

[Discourse]

Это руководство объясняет, как использовать новый триггер обновления пользователя в плагине Discourse Automation для создания постов при обновлении пользователями своих профилей.

Требуемый уровень пользователя: Администратор

Плагин Discourse Automation включает триггер для скрипта создания постов. Этот триггер позволяет автоматически создавать посты в указанной теме, когда пользователь обновляет свой профиль, при условии выполнения определенных условий.

Настройка автоматизации

1. Перейдите в example.discourse.com/admin/plugins/automation в вашем экземпляре Discourse.
2. Нажмите на «Новая автоматизация».
3. Выберите «Создать пост» в качестве скрипта.
4. Выберите «После обновления пользователя» в качестве триггера.

Параметры конфигурации

Пользовательские поля и поля профиля пользователя

Укажите, какие поля должны быть заполнены пользователем перед запуском скрипта после обновления профиля. Вы можете выбрать пользовательские поля, поля профиля или оба типа.

Примечание: Должно быть указано хотя бы одно из полей: «Пользовательские поля» или «Поля профиля пользователя». Автоматизация сработает только после того, как пользователь заполнит все указанные поля.

Один раз на пользователя

Включите эту опцию, чтобы ограничить автоматизацию срабатыванием только один раз для каждого пользователя. После того как автоматизация сработала для конкретного пользователя, она не сработает снова для этого пользователя при последующих обновлениях профиля.

Только новые пользователи

Включите эту опцию, чтобы ограничить автоматизацию срабатыванием только для пользователей, которые присоединились после включения автоматизации. Это полезно для рабочих процессов приветствия/введения, когда вы не хотите, чтобы существующие пользователи запускали автоматизацию.

Создатель

Вы можете выбрать, кто будет создавать пост:

• Конкретный пользователь
• Системный пользователь (по умолчанию, если создатель не указан)
• Пользователь, запустивший автоматизацию (т. е. пользователь, обновивший свой профиль)

Использование плейсхолдеров

Вы можете использовать плейсхолдеры в содержимом поста для включения информации из профиля пользователя. Доступны следующие встроенные плейсхолдеры:

• %%USERNAME%% — имя пользователя, обновившего свой профиль
• %%NAME%% — полное имя пользователя, обновившего свой профиль
• %%UPDATED_USER_USERNAME%% — то же, что и %%USERNAME%%
• %%UPDATED_USER_NAME%% — то же, что и %%NAME%%
• %%CREATOR_USERNAME%% — имя пользователя-создателя поста

Кроме того, любые поля профиля пользователя или пользовательские поля, указанные в конфигурации триггера, становятся доступными в качестве плейсхолдеров. Например, если указано поле профиля «location», становится доступным плейсхолдер %%LOCATION%%. Имена пользовательских полей преобразуются в верхний регистр, а пробелы заменяются на подчеркивания.

Вот пример:

Добро пожаловать в наше сообщество, @%%USERNAME%%!

Мы рады, что вы присоединились к нам из %%LOCATION%%.
Расскажите нам больше о вашем интересе к %%CUSTOM_FIELD_1%%!

Примечание: Плейсхолдеры должны быть написаны заглавными буквами и окружены %%. Любой плейсхолдер, который не требуется в полях «Пользовательские поля» или «Поля профиля пользователя» триггера, может не быть заменен, если пользователь не заполнил эту информацию.

Тестирование автоматизации

Вы можете протестировать автоматизацию, используя свой собственный профиль:

1. Настройте автоматизацию, как описано выше.
2. Обновите свой профиль пользователя, заполнив указанные в триггере поля.
3. Сохраните изменения профиля.
4. Проверьте указанную тему, чтобы убедиться, что автоматический пост был создан.

Помните, что действие запускается при сохранении профиля пользователем, но выполняется только при соответствии условиям триггера, которые вы установили.

Устранение неполадок

Если вы столкнулись с проблемами:

1. Убедитесь, что хотя бы одно из полей «Пользовательские поля» или «Поля профиля пользователя» настроено в триггере — оба не могут быть оставлены пустыми.
2. Перепроверьте, что имена полей в вашей конфигурации точно совпадают с пользовательскими полями или полями профиля, определенными в вашем экземпляре Discourse.
3. Убедитесь, что плейсхолдеры в содержимом вашего поста определены правильно и соответствуют ожидаемому формату (например, %%LOCATION%% для поля профиля «location»).
4. Если используется опция «Один раз на пользователя», имейте в виду, что автоматизация отслеживает пользователей, которые уже её запустили. Пользователь, который уже запустил автоматизацию, не запустит её снова.
5. Если используется опция «Только новые пользователи», убедитесь, что учетная запись пользователя была создана после включения автоматизации.

Дополнительные соображения

• Производительность: Если у вас большое количество пользователей с частыми обновлениями профиля, отслеживайте ресурсы системы, чтобы убедиться, что автоматизация не влияет на производительность.
• Права доступа пользователей: Убедитесь, что автоматизация использует учетную запись с достаточными привилегиями для создания постов в указанной теме.
• Закрытые/архивированные темы: Автоматизация не создаст посты в темах, которые закрыты или архивированы.

[Seth_Godin]

Sorry to be a newbie, but can you give me some context? I’ve got automation turned on in my dashboard. But how to install, where to find this?

thanks

[JammyDodger]

You can find the Automation page at /admin/plugins/discourse-automation

It should be part of the secondary menu here: (forgive the phone screenshot )

From there you’d create a new automation and then I think this new trigger is for the Create Post script.

Once created and the ‘after user update’ trigger is selected, all the extra options then show up to match the screenshot in the OP.

[Seth_Godin]

thanks @JammyDodger

the screenshot of where creating a new automation is buried is really helpful, thank you.

I made it most of the way, then got this hard to parse error:

[JammyDodger]

I think that’s referring to the ‘user profile fields’ option. It seems that’s a required one as well.

Perhaps that should be either the custom field or the profile field should be required.

That one may be a question for @Juan_David_Martínez

[sam (Sam Saffron)]

I know the last thing you would expect from yours truly … is yet another AI reply Seth but Anthropic just released the new Anthropic Opus model and I decided to run it through the paces, the answer is fascinating and I think it is correct:

Talking to Opus about the issue AI

sam:

Given the commit:

commit 92814444966892eea7746209e949e6893a89b07c
REDACTED

I am trying to answer:

I made it most of the way, then got this hard to parse error:
Field user profile must be filled

Also give me a recap on this feature explaining various edge cases and possible gotchas with the commit in Discourse automation

claude_3_opus_bot:

Based on the error message “Field user profile must be filled”, it seems that the “user_profile” field in the automation trigger is required but was not properly filled or configured.

Let’s recap the feature and the commit:

This commit introduces a new feature in Discourse Automation that allows creating automated posts when a user updates their profile information. The main changes include:

1. Adding a new trigger called “user_updated” that fires when a user updates their profile.

2. Introducing new fields in the automation trigger:

   • “user_profile”: Allows specifying which user profile fields to monitor for changes.
   • “custom_fields”: Allows specifying which custom fields to monitor for changes.
   • “first_post_only”: Determines if the automation should only trigger for the user’s first post.
   • “automation_name”: Provides a unique name for the automation to prevent conflicts.

3. Implementing the necessary event handlers and scripts to handle the user update event and create the automated post.

Possible edge cases and gotchas:

1. Field validation: Ensure that all required fields, such as “user_profile” and “custom_fields”, are properly filled in the automation configuration. Missing required fields will prevent the automation from triggering.

2. Custom field names: Be careful when specifying custom field names in the “custom_fields” field. Make sure the names match exactly with the custom fields defined in Discourse. Any mismatch will result in the automation not triggering for those fields.

3. Placeholder usage: When using placeholders in the automated post content, ensure that the placeholders are correctly defined and match the expected format (e.g., %%CUSTOM_FIELD_1%%). Incorrect placeholder usage may lead to unexpected post content.

4. First post only: If the “first_post_only” field is set to true, the automation will only trigger for the user’s first post. Subsequent updates to the user’s profile will not trigger the automation.

5. Automation naming: Provide a unique and descriptive name for the “automation_name” field to avoid conflicts with other automations. Using the same name for multiple automations may lead to unexpected behavior.

6. Performance considerations: If there are a large number of users and frequent profile updates, the automation may impact system performance. Monitor the system resources and optimize the automation configuration if needed.

7. User permissions: Ensure that the automated posts are created with the appropriate user permissions. The automation should use a user account with sufficient privileges to create posts in the specified topic.

To resolve the “Field user profile must be filled” error, make sure that the “user_profile” field in the automation trigger is properly configured with the desired user profile fields to monitor. Double-check the field names and ensure they match the actual profile field names in Discourse.

Let me know if you have any further questions or if there’s anything else I can assist you with regarding this feature and commit.

sam:

Perhaps that should be either the custom field or the profile field should be required.

is this a bug?

claude_3_opus_bot:

You raise a valid point. Based on the current implementation, both the “custom_fields” and “user_profile” fields are marked as required in the automation trigger. However, it might be more flexible and user-friendly to require at least one of them, rather than both.

Requiring both fields could be considered a bug or an oversight in the design. It may limit the usability of the feature, as users might want to trigger the automation based on changes in either custom fields or profile fields, but not necessarily both.

To address this, you could modify the automation trigger to make “custom_fields” and “user_profile” optional fields, but add a validation to ensure that at least one of them is provided. This way, users can choose to trigger the automation based on changes in either custom fields, profile fields, or both, depending on their specific requirements.

Here’s an example of how you could modify the trigger definition to implement this change:

DiscourseAutomation::Triggerable.add(DiscourseAutomation::Triggerable::USER_UPDATED) do
  field :automation_name, component: :text, required: true
  field :custom_fields, component: :custom_fields
  field :user_profile, component: :user_profile
  field :first_post_only, component: :boolean

  validate do
    if custom_fields.blank? && user_profile.blank?
      errors.add(:base, "At least one of 'custom_fields' or 'user_profile' must be provided.")
    end
  end
end

In this modified version:

• The required: true option is removed from the “custom_fields” and “user_profile” fields, making them optional.
• A custom validation block is added using the validate method.
• Inside the validation block, it checks if both “custom_fields” and “user_profile” are blank.
• If both fields are blank, it adds an error to the base errors, indicating that at least one of them must be provided.

With this modification, users will be required to fill in at least one of the “custom_fields” or “user_profile” fields when configuring the automation trigger. They can choose to provide both fields if needed, but it won’t be mandatory.

This change improves the flexibility and usability of the feature, allowing users to trigger the automation based on their specific requirements while still maintaining the necessary validations.

Consider updating the implementation and documentation accordingly to reflect this change and provide clear instructions to users on how to configure the automation trigger properly.

sam:

does the rest of the code already handle this?

claude_3_opus_bot:

Apologies for the confusion. Let me take a closer look at the existing code to check if it already handles the case where either “custom_fields” or “user_profile” is provided.

Upon reviewing the code more carefully, I can see that the DiscourseAutomation::EventHandlers.handle_user_updated method already handles the case where either “custom_fields” or “user_profile” is provided. Here’s the relevant part of the code:

def self.handle_user_updated(user)
  # ...

  required_custom_fields = automation.trigger_field("custom_fields")
  user_data = {}

  # ...

  if required_custom_fields["value"]
    if required_custom_fields["value"].any? { |field| user_custom_fields_data[field].blank? }
      next
    end
    user_data[:custom_fields] = user_custom_fields_data
  end

  required_user_profile_fields = automation.trigger_field("user_profile")
  user_profile_data = UserProfile.find(user.id).attributes
  if required_user_profile_fields["value"]
    if required_user_profile_fields["value"].any? { |field| user_profile_data[field].blank? }
      next
    end
    user_data[:profile_data] = user_profile_data
  end

  # ...
end

In this code:

• It retrieves the “custom_fields” and “user_profile” values from the automation trigger fields.
• If “custom_fields” is provided and has values, it checks if any of the specified custom fields are blank for the user. If any custom field is blank, it skips the automation trigger using next.
• Similarly, if “user_profile” is provided and has values, it checks if any of the specified profile fields are blank for the user. If any profile field is blank, it skips the automation trigger using next.
• If the required custom fields and profile fields are present and have valid values, it adds them to the user_data hash.

This means that the existing code already handles the case where either “custom_fields” or “user_profile” is provided. If one of them is not provided or has blank values, the automation trigger will be skipped.

Therefore, based on the current implementation, it seems that there is no need to modify the code to handle the case where either “custom_fields” or “user_profile” is provided. The existing code already takes care of it.

I apologize for my previous response and any confusion caused. Thank you for prompting me to review the code more thoroughly.

So the good news is that it is looking like a trivial change to the automation plugin to allow “either/or” and Opus even wrote the code for us!

I will prioritize it so somebody makes the change this week and we will let you know once done!

[sam (Sam Saffron)]

What a roller coaster @Seth_Godin I was so excited about my super shiny language model helping here, but sadly it hallucinated a bunch of stuff.

On the upside the hallucinations were not terrible conceptually so I added a concept of validation to the code.

I have my changes here:

FEATURE: allow either custom_fields or user_fields in trigger

But I have 2 open questions here which will help out a bit.

1. How would you like the introductory post to look?

2. When would you like the introductory post to be made?

(1) has a few options:

• Intro post comes from @intro-bot or similar. Eg:

  I would love to welcome @amazing-user from France to the forum!

• Intro post is posted on behalf of the user. Eg: @sam joins forum, fills stuff up and..

  @sam posts: > Hello, my name is Sam and I am from Australia!

(2) also comes with a few options:

• Wait on ALL the fields to be saved, prior to posting the intro (eg: no bio, no intro)
• As soon as ANY of fields are added, post it.

Which also opens the door to… what do we do if a field is missing.

---

This will give us enough data to work in the rest of the changes we need to make this delightful for you and your community.

My recommendations:

1. Intro comes from “intro_bot”
2. Intro only posts when everything is filled

[Seth_Godin]

hardly a roller coaster in the scheme of roller coasters. I’m actually amazed at what it can do.

I’m inclined to ALWAYS take your recommendations, but it feels to me like an intro from the person themselves has the advantage that any replies go to the person, not the bot, thus welcoming folks in, which is the goal.

and yes, only when filled

I installed it a few days ago in purple.space but I’m not sure it’s been triggered yet…

in your hands @sam

thanks

[sam (Sam Saffron)]

Seth, acknowledged.

Going to need a few days to sort out how to pull this off. There is a rather tricky UI problem here I need to discuss with the team:

“Creator” now allows you to have any specific user, but we want a special option for:

Creator: [User who triggered the automation]

I am just not sure how to wire this into the UI so I need to talk some people.

Additionally we need to be careful to label the UI properly and implement correctly

“will trigger only if the user has filled this profile data”, needs to change to
“will trigger only if the user has filled out all these profile fields”

Sorry we handed this off so unfinished, we will get this all 100% sorted and properly documented.