Feature request: if-this-then-that-style support (i.e. recurring cards)
Brought to you by:
wekan
Menu
▾
▴
#1160 Feature request: if-this-then-that-style support (i.e. recurring cards)
closed
nobody
2026-06-14
2017-08-06
Anonymous
No
Originally created by: killua-eu
Being able to set rules initiating a specific action (i.e. move a card) in case that something else happens (i.e. if card is past due date) would make Wekan very suitable for several professional use-cases. Implementing this would top existing possibilities that, only Odoo partially covers (and which aren't really present in Trello). Typical use cases:
Recreate a card yearly on 1st June: i.e. company ABC needs to perform periodic maintainance on a machine to adhere to standards.
Send mail if card is moved: i.e. if the above card is recreated, and the safety manger of ABC moves it from TODO to DOING, send automatic maintenance request to company XYZ and a copy to the safety manager.
Create a card if some other card past due date: lets assume the recreated card isn't moved to "DONE" within 15 days. There's a problem that needs to be elevated higher up the food chain. So the rule might create a new card on ABC's production directors' board to figure out what's happening.
... usecases such as this can be quite many as you can surely imagine and could act upon external events (i.e. according to ABC's bank API, the company received $10.000.000 or more --> create a card: "party hard").
There are some ways to approach this issue:
- implement a subset of features directly into Wekan
- bind wekan with another opensource tool (https://github.com/huginn/huginn comes to my mind) and make these two play together smoother then butter (i.e. create rules from within wekan)
Using the 2nd approach make's things a bit more complex and limited by huginn (or similar), but would also help resolve integration tickets such as [#1100] . In case someone would pick this up, I'm willing to build a VPS and offer it to the wekan team on which huginn (or anything else) would be preconfigured in case that would be needed/welcomed.
Originally posted by: ocdtrekkie
Your number (2) approach would basically be to ensure everything you want to be able to do in Wekan can be done via the API. Then all you need is people to write plugins for things like Huginn to do them. That's probably a smarter approach than overloading Wekan with all the sorts of functionality an IFTTT-like program would have.
Originally posted by: killua-eu
I concur, even though I'm not generally extremely happy with the state of Huginn and its dependency on Ruby. Though I do believe that a to make this really useful, a minimal subset of wekan rules for huginn should be maintained by the wekan dev community. This would provide a selected subset of interesting features wekan is currently missing out-of-the-box (thinking of an administrative option "use huginn" tha would require hugin to be a runtime dep) and at the same time a working example that people can hack to their needs and possibly even share back with everyone, building a specific ecosystem i really didnt see anywhere else.
Originally posted by: killua-eu
Added a bounty on this issue. Please see https://www.bountysource.com/teams/wekan/issues
Originally posted by: xet7
One alternative to Huginn is Flogo:
https://twit.tv/shows/floss-weekly/episodes/455
http://www.flogo.io
https://github.com/TIBCOSoftware/flogo
Originally posted by: jttttttttt
I have just used Butler for Trello and it makes Trello super versatile with lots of automations. If there is anything that can achieve similar functionality within Wekan, I'd throw some bounty into that:
https://trello.com/b/2dLsEE9t/butler-for-trello
Once you decided which way to achieve is the best one (Huginn, Flogo, DRAKON, ...), please let me know so I can put my bounty in for that!
Originally posted by: xet7
@jttttttttt
I will test both Huginn and Flogo, and then use the one that is better. Implementation starts after you have added your bounty to this issue:
https://www.bountysource.com/issues/47991500-feature-request-if-this-then-that-style-support-i-e-recurring-cards
Originally posted by: killua-eu
Flogo sounds really interesting - will look into it too.
Originally posted by: jttttttttt
Hi guys, I just added some bounty to this issue.
@xet7 Have you made a decision yet if you want to use Huginn or Flogo?
Originally posted by: xet7
@jttttttttt
Not yet, I need to do some tests.
Originally posted by: xet7
I'm starting to work on this feature soon.
Originally posted by: jttttttttt
@xet7 How's it coming along? Got a rough ETA?
Originally posted by: xet7
@jttttttttt
I wish ETA could be about 2-4 weeks, but I'm not so good with estimates.
Originally posted by: xet7
@jttttttttt
This is important feature that I need for other customer also, so this will get done anyway.
Originally posted by: Digital-Thor
For visualization purposes, I coded some front-end changes to show how the Automation solution might be implemented. As an example of tracking Card Due Dates, I used a board that tracks aging account-receivables. It shows a new Automation swimlane and an
Add Automationbutton.Clicking the
Add Automationbutton would bring up a Butler-style Trigger-Actions wizard as shown below. Some of the details are unique to our application so ignore the details such as the wording change of "Card" to "Case", the actual actions in the Does column. The general concept would be that the automation would run when cards hit the date configured in the List heading.A general solution would probably only include sending emails. A more advanced approach could enable HTTP calls to be configured elsewhere and listed as actions in the Does column.
Originally posted by: killua-eu
@xet7 , what is your preferred implementation then? flogo / huggin / something else? just curious as I'll need something similar in an other project. Thanks
Originally posted by: xet7
@killua-eu
Flogo, because it can make small binary with Go. Huginn uses too much RAM with Ruby etc.
I'm in progress of fixing REST API on Standalone Wekan and Sandstorm Wekan and adding more to REST API, before I can work on this IFTTT.
@Digital-Thor
Your UI for automation is good starting point. I would add that:
All of that automation tasks, like sending emails, scheduled events, etc will happen in automation client, that is programmed with Flogo and Go. It uses REST API get data from Wekan, and send results back. This way it can automate both Standalone Wekan (Docker, Snap) and Sandstorm Wekan. There is Sandstorm issue about Create API for apps to schedule background tasks, but it remains to be seen when it'll be implemented. At Sandstorm Wekan grains start and stop as needed, so reacting to scheduled events at exact time is not possible, grain could be stopped when that event would happen.
That Go-based automation client can also be included inside docker/snap/sandstorm etc if that would benefical for some reason, that just need some startup script that starts both Wekan and automation client.
Current automation already in Wekan is for example copying checklist template to multiple cards with JSON config as destination cards. I do like this approach very much.
There has been some problems with setting up email, partly related to email features Meteor framework has. If this email functionality is migrated to Go automation client, it makes supporting various email systems easier.
Originally posted by: Digital-Thor
Lots to think about.
Yes, I think it might be good to enable some user-configuration of the board's vocabulary (which wouldn't need to be translated). For instance "case" works for the example I gave, but someone may just want to call it "invoice". Or who knows what someone might be tracking. What about if someone set up a board to track vehicles, it might be easier for them to think about cards as "vehicles".
Butler uses a vertical column for automation along with a 'Butler' user. I hadn't seen their approach when I coded my mock up and horizontal automation, configurable by column, made more sense to me. Nevertheless, since then, I received some further feedback that compound triggers may be needed. For instance, the value of the invoice and the time it's overdue may require different actions to be triggered. So perhaps the triggers should be configured at a board level rather than the (vertical) list, but permit triggers based on variables within the card, system time, or...
Originally posted by: xet7
Ok, that could change design to be this way:
Swimlane settings:
About 'Butler' user: Currently only admin has access to Wekan REST API, so actions are made as the REST API logged in user. It could be also later possible to use REST API as normal user.
I don't know is it useful to build all the automation workflow UI to Wekan UI directly, because when Wekan is running inside Docker/Snap/Sandstorm, Wekan most likely does not have direct access to hardware.
Flogo has this kind of workflow designer, I opened example workflow in Flogo's Docker container web interface:
I'm thinking that just making Wekan to have as good REST API as possible, having access to everything in Wekan REST API, and using Flogo to implement all workflows would be good starting point.
This is still at brainstorming / ideas level, feedback welcome.
Originally posted by: xet7
It's also not necessary that Flogo automation would need to poll constantly what is currently at board. Wekan stats features have Winston logger, so all activity at boards could go to Flogo app as input, and it would react to those events that have some actions in them.
https://github.com/wekan/wekan/wiki/Features#stats
When starting flogo app, it could read from Wekan using REST API, is there any due date and automation related info in Wekan, and store it to flogo app's own database. That way flogo could do those actions, like accessing other apps with REST API, when Sandstorm Wekan grain is not running.
Originally posted by: xet7
One problem in using external tool like Flogo is usability, translations, switching between different tools, and the need for data transfer between Wekan and other tool, so it would add additional complexity.
It seems that Flogo is available only in English.
For standalone Wekan, mostly what's missing is having scheduled background tasks. This can be added in standalone Wekan, probably using some Meteor or npm package.
When running at Sandstorm, some scheduled background tasks API could be in Sandstorm itself, and it could start Wekan grain when needed.
Originally posted by: xet7
When running flogo, I got this message to console:
So it seems that there probably is already possibility to do translation.
Probably I just should try to implement some use case and see how it goes with Flogo and Wekan REST API.
Originally posted by: Digital-Thor
Flugo has a nice GUI. I'm going through their docs now. I guess the downside is that not all Wekan JS developers can jump into the GO codebase. Would the proposed integration only work in Sandstorm?
I've been using Node-Red for home automation and have been very impressed with it. I notice that it has a rules engine. It also has over 2000 integrations (flows) and is a project of the JS Foundation.
There's also the Drools rules engine which works with KIE BPM and supported by Red Hat.
Then there are quite a few others, including:
Regarding the issue about custom terms, I meant that perhaps we could have a board-level setting (not swimlane-level setting) for the term to use instead of "card". For my demo, I changed all appearances of "card" in
en.i18n.jsto "case". Not an urgent feature request, just a side thought. I will move that to the feature request area.Originally posted by: killua-eu
Hmm, is the UI part opensourced in flogo?
Originally posted by: xet7
@killua-eu
UI is node.js project inside docker, and the repo for it is not public.
EULA is this 250 page PDF file, it includes licenses of all included software:
http://www.flogo.io/flogo-docker_eula.pdf
Originally posted by: d3dbit
Hello all,
What about this feature request (if-this-then-that)? Do you have some updates?
Has anybody implemented the flogo option?
I am very interested in this feature for automating some processes.
Thanks.