Functional overview
Following story #13641, "Solo items" are already displayed and mapped to their column.
At this stage, the goal is to have all the content of a taskboard displayed:
- On the left hand side the "backlog" columns (with stories for instance).
- The columns with their content (the tasks, bugs, etc).
Technical overview
REST routes
GET /taskboard_card/:id/children <= or better-suited name
This route returns a kind of BacklogItem representation + the column info (mapping) + the rank. Implementation should avoid reusing "backlog_items" REST route elements because it adresses different needs.
Front-end
On front end side, at this stage it's quite simple but there are some elements to take into account:
- The loading phase (spinner, skeletons)
- The errors during load
- Performances with many elements
- Large number of stories
- Large number of tasks
When there is an error at this stage, for example a 4XX or 5XX error while loading children, we will show a "danger" error modal (like kanban). It is not an "App erorr state" because we have already started showing things (Top-level cards).
Mappings
We will pass the cardwall column mappings information via the DOM and "data" attribute. We could do a REST route but it would result in an "empty app" showing nothing but a spinner. It's much faster to inject that information and leads to better UX (fewer spinners, faster display).
At this stage, we will only need to add "mapping information" for "low-level items such as "Tasks". The top-level items' mapping will already have been added in story #13641
Precisions on the mapping between a field and its cardwall column:
The field can be any select box field, with all bindings: custom values, bound to users, bound to user groups.
The field can even be a multi-select box.
One may also select multiple list values for a single column, for example when "status" is either "On going" or "Waiting", it goes in the "Ongoing" column. In this case, we will follow the existing behaviour and the cardwall will show cards that have either of those values in the column.
Context on the need for new REST routes
We need to have dedicated routes to display the cards in the right columns. We initially thought that /backlog_items & /milestones related routes might do the trick but we overlooked 1 key point:
In planning view (where milestone & backlog_items routes come from) the only status info that exists is related to the "status" semantic (ie. wheras the artifact is Open or Closed). But in Taskboard view we need the the precise information of the mapping related status. This mapping is defined in the configuration of the cardwall (for admins) and can be very lax. If we were to use the "backlog_items" routes, we would not know where to place the card in the taskboard columns.
For this reason we have to introduce new routes in the taskboard namespace so we can get the mapping information. The implementation should avoid duplication with backlog_items because it adresses different needs.
Abandoned ideas
We thought about adding some kind of query or parameter to the "backlog items" routes, but it's very far from easy to understand for API users. We chose to go with new routes instead.