Proper workflow: States, Transitions, etc

Ideas & Features
1

Workflow should consist of States and Transitions.
States have Transitions. Transitions have Guards (conditions and permissions) and target States.
Transitions can be triggered via a user action (e.g. button) if they have the required permission, or automatically if the condition formula is true.
A Role has Permissions on an entity based on the State of the entity.
Groups can have roles.
Users can have roles, and they can belong to groups (inheriting the roles of the group).

5 Likes
2

Since we already have some good support on this one from @Chr1sG and @Matt_Blais, and I imagine @rothnic as a dev-focused user in here, I wanted to point out a good post I have often dreamt about becoming reality - this is an older one as a veteran in here I recall from a good while ago:

@mdubakov is showing some real chops when it comes to understanding what it takes to make a powerful board with all you are requesting @jean1 and more. If youā€™re familiar with TargetProcess, that is one of the best boards/workflow solutions out there.

Letā€™s hope by supporting this we can move the prioritization of development of more capability in boards!

1 Like
3

Nice, Iā€™m glad thereā€™s support for this way of thinking :slight_smile:
I just know the TargetProcess name, Iā€™m not familiar with how it works.

Iā€™d like to stress that Iā€™m not thinking about boards in particular though. These are primitives that are fundamental to the content system.

  • Workflow is not tied to boards, all entity access is determined by workflow state.
  • Entities are in multiple Workflows. The default workflow could have e.g. PublicToWorkspace and Private states, where the PublicToWorkspace state grants the CanView permission to the WorkspaceMember role, and the CanDelete permission to the Owner role. (All entities are in this workflow by default.)
  • Permissions are just an extensible list of names. They are checked for upon any entity access, and by formulas e.g. guard conditions.
  • A State grants permissions to roles. The permissions that a user has on an entity is determined by their role.
  • Users or groups can have roles.
  • Users or groups can belong to groups.
  • Roles can be computed (e.g. a user gets the Owner role on entities that they created).
  • A Workflow is a set of States with Transitions between them.

I donā€™t know if these correspond to the kind of state that shows up on a Kanban board, though it is a logical way to show it. E.g. say we have an App for collaborating on articles, and another for translating articles. The WritingApp has PublicationWorkflow with states Draft, InReview, and Complete. The TranslationApp has TranslationWorkflow with states PendingTranslation and Translated.
The TranslationApp should define a Translatable extension (or interface, or marker ā€¦). Any other app could then add this extension to types, e.g. to the Article type (or to a BlogPost type, etc).
The PendingTranslation state could either be entered via user action, or via a guard condition (if PublicationWorkflow->Complete: TranslationWorkflow->PendingTranslation). And items pending translation could then show up in the ā€œPending translationā€ column of a board.

Iā€™m aware that really none of the current popular platforms have anything like this complete and flexible a workflow/security model. I think it doesnā€™t have to be intrusive though, and it unlocks whole application domains.

2 Likes
4

Iā€™ve actually been chatting with Anton about my needs for permission-driven workflow/states, and he indicated that work on it would be dependent on demand (as is to be expected) so Iā€™m hugely relieved to hear enthusiasm here from others.
Having said that, I also know, from some of the posts that Michael has made, that the community discussions are only a small fraction of the sources that go into deciding priorities. I guess weā€™ve got to hope that there are also people asking for this through other feedback channels.

2 Likes
5

I think Jira Next-gen projects (now renamed to ā€˜team-managedā€™ projects) have nearly exactly what you were originally asking for:

image
image1920Ɨ943 76.9 KB

2 Likes
6

It looks like Jira supports fairly sophisticated workflows, but does it enforce permissions according to role (and thereby to users/groups)?
I donā€™t have a great deal of experience with Jira and I donā€™t want to sign up just to answer this :wink:

7

Yes, that is one of the rules you can apply:

image
image771Ɨ678 38.5 KB

image
image765Ɨ594 24 KB

2 Likes
8

There are a few basics in Jira, like workflows, and conversion of Entity I talked about here that I really hope Fibery can come close to duplicating. Right now though, both the workflow extension, and converting between types, is a long way from what Jira has. And these are two huge pieces needed for running world-class software development in Fibery.

Thanks!

1 Like
9
2 Likes
10

Workflow states should have multiple checkpoints, to monitor progress. for example bake cake state would have order ingredients , bake cake. deliver cake would have book collection, collected, delivered. but the ability to monitor progress in a non linear way would be very useful. e.g. you could book collection when you put it in the oven. In my use case there are tens of non linear progression checkpoints so the current implementation of state is far too simple to be useful.

11

That sounds like tasks with dependencies, right?
The tasks (order ingredients, bake, deliver) would each have a state (pending, in progress, completed) and then you would want to implement dependencies, e.g. so that bake could not enter the ā€˜in progressā€™ state if order ingredients was not ā€˜completedā€™.
Is that what you mean?
To what extent are the tasks and their dependencies repeatable (i.e. weā€™re always baking cakes) versus more ad hoc (i.e. this week weā€™re baking a cake, next week weā€™re servicing the car)?