•  
     
    story #13626 Drag and drop cards
Summary
Empty
Drag and drop cards
Empty

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).

Empty
Empty
Status
Done
Development
Empty
Empty
Details
#13626
Manuel Vacelet (vaceletm)
2019-12-04 13:44
2019-07-11 16:00
14253

References

List of items referenced by or referencing this item.

Follow-ups

  • User avatar
    gerrit #17004 integrated into Tuleap 11.8.99.223
  • User avatar
    gerrit #17000 integrated into Tuleap 11.8.99.222
  • User avatar
    Real-time update was split and is now story #14251 have Real-time update

    • Acceptance criteria
  • User avatar
    • Status changed from On going to Done
  • User avatar
    gerrit #16977 integrated into Tuleap 11.8.99.190
  • User avatar
    gerrit #16947 integrated into Tuleap 11.8.99.178
  • User avatar
    gerrit #16958 integrated into Tuleap 11.8.99.177
  • User avatar
    gerrit #16943 integrated into Tuleap 11.8.99.174
  • User avatar
    gerrit #16936 integrated into Tuleap 11.8.99.161
  • User avatar
    gerrit #16930 integrated into Tuleap 11.8.99.157
  • User avatar
    gerrit #16925 integrated into Tuleap 11.8.99.148
  • User avatar
    gerrit #16907 integrated into Tuleap 11.8.99.142
  • User avatar
    gerrit #16912 integrated into Tuleap 11.8.99.138
  • User avatar
    gerrit #16915 integrated into Tuleap 11.8.99.137.
  • User avatar
    gerrit #16913 integrated into Tuleap 11.8.99.132
  • User avatar
    gerrit #16777 integrated into Tuleap 11.8.99.128
  • User avatar
    gerrit #16905 integrated into Tuleap 11.8.99.124
  • User avatar
    gerrit #16871 integrated into Tuleap 11.8.99.111
  • User avatar
    gerrit #16881 integrated into Tuleap 11.8.99.104
  • User avatar
    gerrit #16864 integrated into Tuleap 11.8.99.102
  • User avatar
    gerrit #16859 integrated into Tuleap 11.8.99.82
  • User avatar
    gerrit #16628 integrated into Tuleap 11.8.99.78
  • User avatar
    gerrit #16818 integrated into Tuleap 11.8.99.65
  • User avatar
    gerrit #16695 integrated into Tuleap 11.8.99.38
  • User avatar
    updated ACs. The "change of swimlane" part of this story has been moved to story #14149.
    Permission on artifact field governs who can "see" the artifact, not who can update it. I have therefore removed all "can_update" mentions for drag and drop, those checks don't need to be made.
    I have also explained the choice of lib for dragula.

    • Acceptance criteria
  • User avatar
    gerrit #16680 integrated into Tuleap 11.7.99.129
  • User avatar
    gerrit #16654 integrated into Tuleap 11.7.99.127
  • User avatar
    gerrit #16625 integrated into Tuleap 11.7.99.97
  • User avatar
    gerrit #16606 integrated into Tuleap 11.7.99.83
  • User avatar
    gerrit #16604 integrated into Tuleap 11.7.99.80
  • User avatar
    gerrit #16549 integrated into Tuleap 11.7.99.71
  • User avatar
    gerrit #16577 integrated into Tuleap 11.7.99.51
  • User avatar
    gerrit #16570 integrated into Tuleap 11.7.99.44
  • User avatar
    gerrit #16545 integrated into Tuleap 11.7.99.34
  • User avatar
    • Acceptance criteria
  • User avatar
    Update ACs after split and estimation

    • Acceptance criteria
    • Status changed from To be done to On going
  • User avatar
  • User avatar
    Updated ACs. The realtime part of this story is split and will be done at a later time.

    • I want to
      -drag'n drop cards on cardwall 
      +Drag and drop cards 
    • Acceptance criteria
  • User avatar
    Add my notes following the estimation. Mainly, the realtime event mechanism is considered as already done in story #13629

    • Acceptance criteria
    • Technical informations
  • User avatar
    • Acceptance criteria
  • User avatar
    Added technical precisions from my notes.

    • Technical informations
  • User avatar
    • Acceptance criteria
  • User avatar
    • Acceptance criteria
  • User avatar
    • Acceptance criteria