CRUD for taskers

[northox]

Provide a way to manage taskers.

• Create new tasker
• Read taskers
• Update tasker
• Delete tasker

[jmettraux]

(do we need CRUD for webhooks?)

[northox]

For webhooks I currently don't see the need as is mostly a set and forget from my perspective.It seems like configuration done at setup, e.g. when I create the link between my app and Flack/Flor just as the authentication token.

[jmettraux]

Playing the "advocatus diaboli", but aren't taskers also "configuration done at setup"? You'd simply reconfigure then restart to add/remove taskers?

[northox]

In our use case we are expecting the taskers to be managed by our application (just as the workflows) but I wasn't considering whether it needs a restart or not. The thing is, at some point we're expecting clients to access an Internet-web-based catalog of workflows which comes with their dependencies, e.g. the tackers. Isn't it simply a matter of adding a directory in the right domain directory structure, the config file and the actual script or does it need to be loaded on startup?

Regarding the other question, are you suggesting the webhook could be configured by the service himself, e.g. dynamically post-authentication?

[jmettraux]

Hey, that's a grand idea. Let me walk through your idea from my current standpoint.

I have this configuration structure. I don't use var/ it's all pretty static:

flor/
├── etc
│   ├── conf.json
│   └── variables
│       └── team_asia
│           └── ta.json # the start variables for the flow "ta" in domain "team_asia"
├── lib
│   ├── flows
│   │   └── team_asia # various flow definitions for the domain "team_asia"
│   │       ├── awm
│   │       │   └── awm_activation.flo
│   │       ├── dac
│   │       │   └── onboarding.flo
│   │       ├── pas
│   │       │   ├── csn
│   │       │   │   └── subscription.flo
│   │       │   └── onboarding.flo
│   │       └── ta
│   │           └── travel_approval.flo
│   └── taskers
│       └── team_asia # various taskers for the domain "team_asia"
│           ├── awm
│           │   ├── create_mandate.json
│           │   ├── email.json
│           │   ├── ops.json
│           │   ├── pfs.json
│           │   └── update_mandate.json
│           ├── dac
│           │   └── create_mandate.json
│           ├── pas
│           │   ├── create_mandate.json
│           │   └── csn.json
│           └── ta
│               ├── notify.json
│               ├── open_form.json
│               └── update_form.json
├── usr
└── var

Following your idea, I could repackage the "ta" process (flow + taskers) as a subdir:

├── usr
│   └── team_asia.ta
│       ├── etc
│       │   └── variables
│       │       └── ta.json
│       └── lib
│           ├── flows
│           │   └── travel_approval.flo
│           └── taskers
│               ├── notify.json
│               ├── open_form.json
│               └── update_form.json

We could even package team_asia.ta/ into a team_asia.ta.zip and place it in usr/ for auto extraction by the flor loader (the service that looks up thing in those configuration trees).

That all clicks into place or am I misunderstanding?

[jmettraux]

Regarding the other question, are you suggesting the webhook could be configured by the service himself, e.g. dynamically post-authentication?

Currently, there is only one webhook, the post 'messages' one, so anything could stand behind it. As soon (and as long) as there is a (task) node expecting an answer (a receive message), we have a webhook...

Now, the post 'messages' expect full-fledged flor JSON messages it might be too much for the "real" taskers.

How about some "https://example.com/flack/webhooks/:id" endpoint? One that you can GET or POST or PUT to and that correlates and translates incoming requests into flor 'receive' messages, so that the "real" taskers, across the gulf of the web, don't have to work hard to produce complete JSON flor messages.

For example, a tasker would be given a simple "https://example.com/flack/webhooks/1234" endpoint and GET it to signify its work is done, or it could POST (with a JSON payload) there when it's done. We could go with "https://example.com/flack/webhooks/{exid}/{nid}" unless it's too "transparent".

[northox]

That make perfect sense. I'll describe our needs in greater details in #3.