Story 10 : Content Trigger : 13 Points

[skleinfeldt]

47 As an admin I can add an IFTTT "Content Trigger" to any folder on my site that will send a trigger to IFTTT when content at or below the current path is published. This will allow me to create IFTTT applets to, for example, email, tweet, or Facebook post about the content.

I can configure

• The IFTTT event name
• The content types to restrict to
• The workflow transitions to restrict to

The trigger will include 3 payloads for the content item

• Title
• URL (for files/images, to view)
• Description

This story provides the user with a simple form to create an IFTTT trigger. Under the hood the code will created a content rule to do the work, but the user does not know that and doesn't care.

For this story, the feature will be added to the Actions menu ("Add IFTTT Content Trigger" or some such). We will address the question of a better UI for all the IFTTT features in a future story (or stories).

Tasks:

• [x] Play with making content rules
• [x] Custom permission: collective.ifttt: Can add content trigger
• [x] Assign permission to role Site Administrator by default (rolemap.xml)
• [x] Register an actions menu item ./profiles/default/actions.xml restricted with role and to be visible only on folders (check “available_expr” examples in Plone actions.xml)
• [x] create upgrade step
• [x] Action is a link to browser view with a form with options (schema and "Add" button)
• [x] Option to restrict certain content types (types from plone.app.vocabularies)
• [x] Option to restrict certain workflow transitions (transitions from plone.app.vocabularies)
• [x] Add new rule
• [x] Add trigger conditions to rule
• [x] Configure action to rule
• [x] Add this new content rule to the folder (at and below the current path)
• [x] Give notification to user
• [x] Write tests
• [x] Write documentation

[skleinfeldt]

See https://www.makeuseof.com/tag/ifttt-connect-anything-maker-channel/ for an example of what the IFTTT trigger HTTP requests look like.

This will rely on Plone's content rules machinery for implementation, but the user interface will be way, way simpler.

This story is restricted to implementing the simplest possible initial version of the "Content Trigger". It should be tailored to a particular set of IFTTT applet use cases (tweet/post/email about newly published content) and be very easy for site admins to set up. Subsequent stories will

• Add other types of triggers for other IFTTT use cases (for example one with a date payload for applets that add events to calendars, another with a user payload for applets that pipe site editing info to Slack or spreadsheets)
• Extend the Content Trigger or create new triggers for content additions, deletions, and other types of changes (not sure what the IFTTT use cases are for these)
• Add the ability to edit and delete existing triggers

This feature can simply be added to the normal Actions menu ("Add IFTTT Content Trigger") as a first pass, but given that there will eventually be more IFTTT triggers plus functionality to edit and delete existing triggers, we should think ahead about the eventual UI for presenting all IFTTT features to admins. For example we could make a new entry on the edit bar called "IFTTT" which could work similar to the way "Add new" works - clicking "IFTTT" gives you the list of available triggers, clicking one gives you a form with Save/Cancel. Providing a UI for the ability to see the list of triggers that have already been added and allowing them to be edited or deleted, will require more thought that should probably be postponed to a later story when we have a few triggers working.

=> We discussed and agreed it makes sense to defer creation of a new IFTTT UI to another story - both to keep this story simple and because we don't know the right solution yet. We may want to create more features first so we have a clearer idea what we're making a UI for.

Note that content rules can only be applied to folders AFAIK, and we will follow that restriction here. There might be use cases for setting a trigger on a particular content item, so we should not do anything to eliminate that possibility. (Or if that would be impossibly difficult we can just not support it.)

[skleinfeldt]

Asko's technical notes from planning meeting (revised):

• Custom permission: collective.ifttt: Can add content trigger
• Assign permission to role Site Administrator by default (rolemap.xml)
• Register an actions menu item ./profiles/default/actions.xml restricted with role and to be visible only on folders (check “available_expr” examples in Plone actions.xml)
• Action is a link to browser view with form with options (schema and "Add" button)
  • The IFTTT event name
  • The content types to restrict to (types from plone.app.vocabularies vocabulary ReallyUserFriendlyTypes) (this is content rule condition)
  • The workflow change to trigger the event (transition from plone.app.vocabularies) (this is content rule condition)
  • The content rule trigger condition is a workflow transition
• Form submission ensures that content rules are enabled, a new content rule (with context derived name) is configured and applied to the context, and a notification is displayed to user (the Magic, requires Python code)

[datakurre]

@Shriyanshagro These look up to date for creating schema based forms:

https://docs.plone.org/develop/addons/schema-driven-forms/creating-a-simple-form/creating-a-schema.html

https://docs.plone.org/develop/addons/schema-driven-forms/creating-a-simple-form/creating-the-form-view.html

With, of course, an exception

OrderFormAdapter implemented and registered in that guide is not required if the form class (OrderForm) had class attribute ignoreContext = True.

[skleinfeldt]

@Shriyanshagro @datakurre did you have any discussion of the task list or approach? I thought the idea was to do research, task breakdown, discussion this week and implement next week?

[Shriyanshagro]

@skleinfeldt @datakurre As you can see in the tasks list, this story is already broken down into individual tasks. Now among those tasks, there are two of them which requires research as I have never dealt with them:

1. Registering new Action Add IFTTT Content Trigger. Which I have already implemented during the ongoing research for it in #47
   2. Dynamic Creation and configuration of the new content rule. For which I have recently started this topic on the community forum to get some insights.

[Shriyanshagro]

@datakurre @skleinfeldt For the following two tasks:

• Option to restrict certain content types
• Option to configure workflow state for trigger

There are two possibilities on UI:

• Checkbox option: Where user can check the options which they want to exclude
• Drag and Drop option: Where they can drag certain options from left box to right box, something like this -

Which is suitable here?

[Shriyanshagro]

@skleinfeldt @datakurre Queries regarding trigger:

• What should be the title and description of the added content rule? I don't follow up with "context derived name".
• What all options should be checked while adding the rule? Below is the screenshot for options:
• Should workflow state always be published for the trigger? (this is first trigger condition)
  • As there may be multiple workflow transitions associated with published state.

[datakurre]

For content type widget, Plone 5 uses Select2 elsewhere. That is available for schema widget directive as plone.app.z3cform.widget.SelectFieldWidget.

Title should be something that both describes and distincts rukes created from that action menu item. Forget ”context derived name”. That was a bad idea.

Those default options should be good.

[skleinfeldt]

@Shriyanshagro The user should be able to choose the set of workflow states that are the trigger condition, just like they can choose a set of content types.

Probably "Stop executing rules" and "Cascading rule" should be checked, but I'm not sure.

[Shriyanshagro]

@skleinfeldt I have made a few tweaks in the documentation, which I noticed while writing documentation for story 11 and story 12. Can you kindly re-check it at Basically, I added a new section named Default Settings to it.

[skleinfeldt]

@Shriyanshagro That section seems like a good idea, but under Conditions those aren't defaults in this case, the workflow state (2.) is what you just configured.

[skleinfeldt]

@Shriyanshagro I think the thing to do is to put this extra info in the "Behind the Scenes" section. So

• Get rid of the "Default Settings" heading and the sentence that follows it.
• Rename "Conditions" heading to "Content Rule Conditions".
• Do the same thing for stories 11 and 12.

(You could just do this on master so I can see it right away, I don't think it needs a PR.)

[skleinfeldt]

@tkimnguyen Please test and close if satisfied.

[skleinfeldt]

Closing for the team.