GSoC 2018 Ideas: IFTTT plugin

Thats why collective.taskqueue is a good implementation as it provides built in default which requires no additional server. It can just create a seperate thread in the same instance to make the call outside of the the request thread. is also good as it requires nothing but ZEO.

What we really need is

  1. An api in plone core that lets us run a task asynchronously regardless of how plone is installed. ie doesn't require an extra service or ZEO. (obviously this means tasks are not serialised to a single queue).
  2. Plugins that allow adding redis, celery or to this so you can serialise these async requests and get HA on the queue.

I'd love to see this come out of this GSOC, not just IFTTT integration.

1 Like

I just cannot stop myself from jumping in here @zopyx. Artificial? As compared to what? Not a common need? For whom? Things that matter? To whom?

I see a conversation here involving ten or so folks, many of whom have customers they serve. Presumably they are participating in the discussion because this idea serves a need they feel is in fact real and common enough to want to do something about. The things that matter are the things we as a community decide matter.

If you are uninterested in this topic then do not participate in the discussion. If you have other priorities for development that you feel are more real, common, or important, then by all means start your own discussions and see if you can get some agreement from other folks. Or continue developing your solutions to your problems.

Do not presume to speak for the community.

Rant finished. The rest of you, please do continue discussing this interesting idea. I'm enjoying seeing where a collaborative discussion leads.

1 Like

Disagree. I'm participating and I and my customers have no need for this. Participation is much more likely due to many reasons

  1. technically interesting
  2. someone said something you disagreed with or you felt the need to correct them
  3. they realise GSOC is not about getting things we need
  4. they think it might be a good veichle to get something we do need (ie async task api) into the plone core.
  5. they had some useful information to add
  6. its simple to understand
  7. any number of other reasons.

I personally think that IFTTT (or an api that allows similar integrations e.g. a content rule action that allows any RESTapi to be called) is low down on the list of priorities for plone but it could prove to useful in the future and if some wants to do if GSOC and doesn't want to do anything else then why not. But it doesn't indicate it's important customers.

One important aspect of Plone is that it is often used to tie together different systems into an integrated platform. Having the ability to tie it via web hooks or other user friendly mechanism would enhance that. So while it’s not a burning issue it could be an important improvement that reinforces a strength of Plone.

Sad, to see this project is not even in the idealist for GSoC. Is this not on the priority list? @tkimnguyen

What is on the project ideas page... are just ideas, not a fixed set, and "Your Own Idea" is one of those :slight_smile:

We also say "Read our GSoC ideas list and pick one you’re interested in, or come up with your own idea." on Information for Interested GSoC Students

If you like this idea or you have another idea, please suggest it and we will see if it gets a good enough discussion going and ends up having some concrete implementation thoughts.

This is the beauty (and the pain) of open source... things are open to discussion, including what becomes a priority. We love ideas! We also love people who make ideas happen. :slight_smile:


You’re right, it’s better to pick a project the community cares about, but the problem we have is that there are a few people who are vocal here and they don’t necessarily represent the views of the wider community.

HOWEVER, just because a project or feature doesn’t feel important to the larger group doesn’t mean it isn’t important… it may not be initially important but it can grow in importance. Conversely, a feature that seemed important at the time may end up not being all that useful or commonly used.

I think Plone has to continue getting new features that please content editors and site managers. This means some of the UI improvements we put into CastleCMS should be backported to Plone. It means that we need more innovations in making Plone easier to use to edit and organize content. If we can include new features that integrate analytics and hot spot measurement and other “advanced” user tracking features then we can sell Plone into more sophisticated advertising/marketing/branding projects.

I think the underlying technology is good and stable, as long as the Python 3 work being done is finished in time. It’s hard to sell underlying technology, so new “behind the scenes” features are a low priority, especially since many of us are able to scale Plone quite nicely as it is.


well said.

Define what the community is.

The core devs?
The integrators?

The much, much bigger amount of countless developers in companies and organizations that are often not in touch with the „community“?

The sheer amount of Plone users that usually care about getting their job done?

The group of persons interested in Plone?

What you define as community is only a small fraction of the overall number of persons affected by Plone and design decisions made by the communityt

All of the above, @zopyx. You have a habit of jumping into discussions and issuing proclamations such as

such a functionality is really artificial and not of common need

My point is that you don't speak for everyone. If you were to rephrase that as "This isn't something I need or want, nor do my users", that would be an entirely valid point and one worth making. Claiming that an idea is "artificial functionality" as if it were an objective, irrefutable truth is neither.

Hello everyone, this project still looks good to me. Though Plone have content rules to accomplish use-cases(provided by IFTTT) with additionally written scripts. But I believe the soul spirit behind this idea is to build a generalized mechanism which lets people add more plugins with a little programming and ease to use UX.

I've been using a few IFTTT applets(like - add youtube liked video to my Spotify playlist) for quite a time. The way they work is, it triggers youtube APIs after every certain interval of time(atleast I've not seen, which triggers continuously) and than request spotify plalylist with provided data. With Plone we can have similar applets, which triggers a Plone site for activity check and then later make an action on another system (Plone/social_sphere/etc). Again the other side of is still valid, as Asko suggested

But in that case, it can miss action with systems outside Plone sphere(such as tweets, posting on slacks). Nevertheless, we can still achieve Asko's suggested functionality by an applet which simply navigates particular triggers onto (/other) Plone sites as actions.

Now adding async specifically to it, doesn't make much sense as I believe it should rather be added to whole Plone itself.
So leveraging Dylan's statement, it could(or should) be a separate project.

I have not played much with content rules, so with the limited knowledge of mine, I believe in this project, we primarily have to add flexibility in Plone environment to entertain requests from webhooks along with authentication. At present, the agent(Webhook) is IFTTT while in future, there can be XYZ_plugin or gitter or TIFFT(This if-and-only-if That)!!

And for sure, adding this flexibility is not an easy task as already suggested by Sally.

Another major challenge is to check security measures, less sensitive contents should successfully accomplish this?

But if once it's achieved there can be numerous use-cases out of it!! One of which suggested by Kim

Now, of course, rolling out a few(prioritized) IFTTT applets which could be added to GSoC scope. And later could be used as tutorial example for other actors to roll out other needy ones, which is the soul spirit of IFTTT(that anyone can built there own applets based on their requirements on supported platforms).

And if commnuity accepts this proposal, I'm more than happy to make it shine this summer!!

If you are really interested, you should submit your first application draft ASAP.

I agree with ignoring async issues for now. Tasks are already queued at IFTTT’s end.

The main related packages are plone.contentrules (framework) and (default conditions and actions). This project’s goals could be multiple pull requests for

See and

The most difficult part could be authentication, because Plone does not ship with oauth2 support by default (and I’m not sure which addon is be the best option for that).

In addition to IFTTT it would be good to think if the same ideas & tech could be used to integrate Plone with other similar services like MSFlow.


Great, I'm onto it now.

yes, that sounds good. But to leverage, it is there anything I missed in my last post?

yes, I'll get a gist of content rules very soon.

yes, implementing this is also disturbing me. Not sure if this would bring misfortune to this idea :confused:

yes, I'm thinking in same direction. IFTTT applets would simply be a middle-out to levarage the idea!!

You should launch yourself a Plone docker container and play a bit with the default content rules (they are enabled from site setup) to get good idea what’s already possible within Plone.

1 Like

plone.restapi includes JWT support support with REST API for creating tokens. That should work to get you started (with manually created tokens).

1 Like

I have submitted a draft on summerofcode website. I kindly request the community to review.

Although it's probably good to keep talking about IFTTT, because the original idea was written for that, technically this idea seems to be about "implementing webhooks" (receiving and triggering) for Plone content rules.

It seems, it could be good to summarize the possible implementable features here:

  • a new Plone contentrule action to call a webhook URL (like IFTTT) with configurable payload

  • a new Plone contentrule triggering event for triggering content rule from external webhook call (like from IFTTT); this is not trivial, because it requires requires a context aware view to accept webhook call, trigger Plone internal event from that, and register that event as Plone contentrules triggering event

  • some new Plone contentrule actions to do something with the payload received from webhook call (the default Plonen content rule actions cannot do anything with the webhook call payload), e.g. an action to create a new content type instance from webhook data using some configurable mapping (and creation of that type may lead to other content rules on Plone instance to allow chaining of rules)

  • figure out authentication for incoming webhook calls; JWT (provided in plone.restapi) would probably be the easiest option, but it would require user interface for creating and invalidating JWT tokens (I assume Oauth2 based solution would be too complex)

1 Like

and picking 3 examples to integrate with as models (probably implemented in a seperate plugin) IFTTT being one. Zapier might be another (it is python based after all). Maybe salesforce?

1 Like

These could probably be done already also with just Plone REST API calls depending on the flexibility of used flow / low code platform. (I don't know if IFTTT allows enough configuration for that.)

I don't have a strong opinion on that. Simple HTTP POST endpoint for triggering a specific content rule instance on some context might be easier to understand than abstracting this part behind REST API.

Plone Foundation Code of Conduct