Settings | Team - Create Issue Statuses

[KostyaEver]

1. For each Task Status, we need to define how it "maps" to our "Standard Task Status Types". i.e. task status record should have "StandardTaskStatusType" field that can be one of the below values :

   • Backlog
   • TODO
   • In Progress
   • Ready for Review
   • In Review
   • Blocked
   • Done
   • Completed
   • Custom Each of those types above itself have associated 3 boolean fields (hardcoded!):
     • isTodo
     • isInProgress
     • isDone

   Specifically:

   • Backlog (isTodo = true, isInProgress = false, isDone = false)
   • TODO (isTodo = true, isInProgress = false, isDone = false)
   • In Progress (isTodo = false, isInProgress = true, isDone = false)
   • Ready for Review (isTodo = false, isInProgress = true, isDone = false)
   • In Review (isTodo = false, isInProgress = true, isDone = false)
   • Blocked (isTodo = false, isInProgress = true, isDone = false)
   • Done (isTodo = false, isInProgress = false, isDone = true)
   • Completed (isTodo = false, isInProgress = false, isDone = true)
   • Custom (isTodo = false, isInProgress = false, isDone = false)
   2. Each Task Status itself also have those 3 fields (isTodo, isInProgress, isDone). For example, we can create Task Status called "Released to Production" which "map" to our Standard Status "Done" (when user create it!). In this case, when such status is created, the fields values for isTodo, isInProgress and isDone are copied from the StandardTaskStatusType record into Task Status record during creation of such status. However, if I create another task status say "Deployed to STAGE", and set Type as "Custom", I can define those 3 fields in the Status itself and that way "override" standard values.
   3. Above mean that essentially those "Standard Task Status Types" are more like "templates" that user can use and override those whatever way they want - give different status name, set different status fields values (isTodo, isInProgress, isDone) and so on
   4. Above also mean that we ALWAYS will store how any status is MAPPED to our "Standard" statuses that were created, however we actually will just use those values that defined on each Status itself without need to ever check how that was mapped to standard types!
   5. In our code, we ONLY should really use those 3 boolean fields to understand how to work with each status in any workflows, e.g. if we want to complete some task, we look for status with "isDone" = true and we know that this is final status in workflow!
   6. We also can use so called "order" of Status (another field) because all statuses will be ordered and we sometimes want to know what is NEXT status after previous status. For example, if first status is TODO, what is next status that is have isInProgress = true (can be MANY such in progress and we want to use first of those!)

Essentially to summarize:

• standard status types are just really some predefined templates that we provide to people who creating new project and want to select some preexisting statuses where we already well defined everything. We actually should SEED every new tenant with such statuses that are identical to some of those standard statuses types!
• we adding 4 new fields: order, isTodo, isInProgress, isDone to STATUSES itself (and also to Standard Status Types of course) to know what each status mean / how it should be working in workflows.

[evereq]

@KostyaEver I think still "Initial" and "Final" are very useful, even with Attributes.

Also, think idea of those "Attributes" is good, but let's just call it "Standard Status". I.e. we will have a predefined list of Standard statuses and people can map custom statuses to our Standard statuses that are "hardcoded" to the list below (or whatever we already have in use in Gauzy, not sure):

• Backlog
• TODO
• In Progress
• Ready for Review
• In Review
• Blocked
• Done
• Custom

So when new status is created, user should select "Standard Status" in dropdown and when we seed task statuses initially we map that so that when user create new team / org / tenant, it's already good to use.

Regarding "Restrict Status 'In Progress' per one task per one assignee (Assignee can not have more than one task with status 'In Progress' in the whole project)" - that is SETTING, it's NOT a requirement for any project / team! I see periodically you making this mistake as to write something like that, but not indicate that it's an optional setting! Please ALWAYS add information if some requirement is optional and can be set for Team / Project (or even for each Member) Settings etc.

Please adjust task description to what I described above, including picture to not confuse developers.

[KostyaEver]

@evereq here I just mentioned point two, we have a separate task that I created 1 year ago for it https://github.com/ever-co/ever-teams/issues/883 so user can select if want enforce or not.

[KostyaEver]

About 'Standart Status' - let's talk a bit.

Let's think that the selected team has task automation ON, and we need to distinguish Passive tasks unstarted (TODO), active that are in progress in (Development, Review, Blocked, Paused) and completed (Ready for Review, Done, Completed) whatever you call it.

so user create status 'Start' that is equivalent of (TODO, Planned etc) we ser 'Standart Status' then we create 'Developing' (like in progress and so on) and set 'Standart Status' then we create 'Delivered' (Done, Completed) and set 'Standart Status'

How engineer should make triggers for statuses? (they have different names, and have the same attribute 'Standart Status')

My point of attributes was that once we set it, the system knows exactly what to do without relying on provided status name @evereq

[KostyaEver]

Unfortunately, it was implemented with mistakes

When a user creates a new Status, should be able to see the Additional dropdown 'Select type' (TODO, In progress, Done) (The screen that was before in the description showed it clearly)

• input 'Name'
• [NEW] dropdown 'Type' (TODO, in progress, Done)
• dropdown 'icons'
• dropdown 'color'
• [NEW] button 'Sort'

Now, looks like you use the same input for icons for this purpose which is totally wrong. You can see the example Only in EDIT mode.

I would reduce size of 'Name' input and added right after 'Type' dropdown then 'icon' and 'color' - simple

Also 'color' should have should NOT display that strange name, better to display word 'color' instead

Additional I think the button 'Sort' should be aligned in different way when user EDITs one of the Statuses

@GloireMutaliko21

cc: @evereq

[Cedric921]

This feature is implemented, but not available now in prod now We have on Task Statuses:

• Dropdown for 'Name'
• [NEW] dropdown for 'Type'
• Dropdown for 'icons'
• Dropdown for 'color'
• [NEW] button 'Sort' (Should be aligned)

But, you are right, Sort Button should be aligned in different way

Uploading Screen Recording 2024-08-16 at 10.56.42.mov…

@KostyaEver / @evereq / @GloireMutaliko21