Using the new user update automation

[Discourse]

This guide explains how to use the new user update trigger in the Discourse Automation plugin to create posts when users update their profiles.

Required user level: Administrator

The Discourse Automation plugin includes a trigger for the Create Posts script. This trigger allows you to automatically create posts in a specified topic when a user updates their profile, provided certain conditions are met.

Setting up the automation

1. Navigate to example.discourse.com/admin/plugins/automation in your Discourse instance.
2. Click on “New automation”.
3. Select “Create post” as the script.
4. Choose “After user update” as the trigger.

Configuration options

User custom fields and User profile fields

Specify which fields need to be filled by the user before the script runs after a profile update. You can choose either custom fields, profile fields, or both.

Note: At least one of “User custom fields” or “User profile fields” must be specified. The automation will only trigger once the user has filled in all of the specified fields.

Once per user

Enable this option to limit the automation to triggering only once per user. After the automation has fired for a given user, it will not fire again for that user on subsequent profile updates.

New users only

Enable this option to restrict the automation to only fire for users who joined after the automation was enabled. This is useful for welcome/introduction post workflows where you don’t want existing users to trigger the automation.

Creator

You can choose to have the post created by:

• A specific user
• The system user (default if no creator is specified)
• The user who triggered the automation (i.e., the user who updated their profile)

Using placeholders

You can use placeholders in your post content to include information from the user’s profile. The following built-in placeholders are available:

• %%USERNAME%% — the username of the user who updated their profile
• %%NAME%% — the full name of the user who updated their profile
• %%UPDATED_USER_USERNAME%% — same as %%USERNAME%%
• %%UPDATED_USER_NAME%% — same as %%NAME%%
• %%CREATOR_USERNAME%% — the username of the post creator

In addition, any user profile fields or user custom fields you specify in the trigger configuration become available as placeholders. For example, if the user profile field “location” is specified, %%LOCATION%% becomes available. Custom field names are converted to uppercase with spaces replaced by underscores.

Here’s an example:

Welcome to our community, @%%USERNAME%%!

We're excited to have you join us from %%LOCATION%%. 
Tell us more about your interest in %%CUSTOM_FIELD_1%%!

Note: Placeholders must be in all caps and surrounded by %%. Any placeholder that isn’t required in the trigger’s “User custom fields” or “User profile fields” may not be replaced if the user hasn’t filled in that information.

Testing the automation

You can test the automation using your own profile:

1. Set up the automation as described above.
2. Update your user profile, filling in the fields you specified in the trigger.
3. Save your profile changes.
4. Check the designated topic to see if the automated post was created.

Remember that the action is triggered when the user saves their profile, but only runs according to the trigger conditions you’ve set.

Troubleshooting

If you encounter issues:

1. Ensure that at least one of “User custom fields” or “User profile fields” is configured in the trigger — both cannot be left blank.
2. Double-check that the field names in your configuration match exactly with the custom fields or profile fields defined in your Discourse instance.
3. Verify that the placeholders in your post content are correctly defined and match the expected format (e.g., %%LOCATION%% for the “location” profile field).
4. If using “Once per user”, note that the automation tracks which users have already triggered it. A user who has already triggered the automation will not trigger it again.
5. If using “New users only”, ensure the user account was created after the automation was enabled.

Additional considerations

• Performance: If you have a large number of users with frequent profile updates, monitor system resources to ensure the automation doesn’t impact performance.
• User permissions: Ensure that the automation uses an account with sufficient privileges to create posts in the specified topic.
• Closed/archived topics: The automation will not create posts in topics that are closed or archived.

Last edited by @hugh 2024-07-26T02:13:12Z

Last checked by @hugh 2024-07-26T02:13:19Z

Check document

Perform check on document:

[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.