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.
Disagree. I'm participating and I and my customers have no need for this. Participation is much more likely due to many reasons
technically interesting
someone said something you disagreed with or you felt the need to correct them
they realise GSOC is not about getting things we need
they think it might be a good veichle to get something we do need (ie async task api) into the plone core.
they had some useful information to add
its simple to understand
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.
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.
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.
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 plone.app.contentrules (default conditions and actions). This projectâs goals could be multiple pull requests for plone.app.contentrules.
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.
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.
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)
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?
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.
