Functional overview

The drag and drop enabling to change swimlane has been split into a different story at story #14149.

Drag'n drop on taskboard is quite a beast as it allows:

• Drag'n drop to change status (as in cardwall v1)
• Drag'n drop to change priority amongst cards
• and... the combination of the 2 as one can change status and place a card precisely in the new column.

Limits (in the first implementation, if the need arise it will be done afterward):

• There is no multiselect of elements (cannot drag'n drop multiple tasks at once).

Technical overview

This story assumes that the management of the mapping between columns and actual status of backlog_items is already done and is part of the VueJS app.

Backend of drop

As we cannot predict the way cards will be moved, we must introduce a new REST route that corresponds to "this card was placed in that cell" semantic. The move in this cell could be one of the 3 drag and drops described in functional overview or a combination. But it's the backend that will detect it and proceed with the corresponding actions.

/*
 * swimlane_id = The new parent swimlane's artifact id. The swimlane we are dropping into
 * column_id = The column I'm dropping into
 */
PATCH /taskboard_cells/{swimlane_id}/column/{column_id}
{
    add: <card_id>,                    // The artifact id of the card we are dropping
    order: {
      ids: [<card_id>],                // This maintains compatibility with existing "reordering" payloads (AgileDashboard REST routes)
      direction: "before",             // "before" | "after"
      compared_to: <card_id>
    }
}

In order to know whether swimlanes can be "dropped into" or whether cards can be "dragged", we will need to add some information to the "trackers" representations passed in DOM: 

/* The names may change */
can_update_mapped_field: true | false // Does current user have "update" permission on the taskboard mapped field for this tracker

When can_update_mapped_field is false, for all cards of this tracker, current user will not be able to drop them in any column (no change of "status").

Frontend of drop

Dynamic rules (from the workflow or field dependencies) are only managed as "backend errors". It means that there will be no visual indicator that a drop cannot be done due to a field dependency or worklow but if someone tries to do it anyway, they will get an error from the backend.

A card may not be dropped if there is no associated mapping for this column and the dragged item's "mapping field". It means that if I try to drop into this column, the backend won't know what value to assign, so it can't be dropped here.

We have spiked https://github.com/bevacqua/dragula and https://github.com/SortableJS/Vue.Draggable. We have chosen dragula because it does not try to "be smart" and update the model. It's easier to update the model ourselves than fix the errors the libs are doing.

Design warnings

• A mock-up or skeleton for dropped card (something to display while the vueapp is fetching the content of the card)
  • => No need of card skeleton here. The "before drag", dragged and dropped card states will be the same. On dropped, the card will be on "updating" state then "updated" state, as we do in planning view. Pease check the live mockup and click on "Edit card" (bottom left) to simulate theses states.

Precisions on the mapping between a field and its cardwall column:
The field can be a multi-selectbox. And an admin may 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. For Drag and drop, this means that when I drop a card in the "Ongoing" column, it will assign the "status" field to "On going" for this card, because it's the first (by value id order).