Move cards on a board to the top or bottom of lists

added Category:Team Planning GitLab Free devopsplan featureenhancement groupproject management sectiondev typefeature labels

changed milestone to %15.3

cloned from #367472

added to epic &8350

changed title from Provide more fine grained controls for relative position adjustment within the issue list to Provide more fine grained controls for relative position adjustment within board lists

changed the description

added [deprecated] Accepting merge requests label

I think we can introduce a issue_boards_positions table:

      Column       |           Type           |
-------------------+--------------------------+
 id                | bigint                   |
 board_id          | bigint                   |
 board_list_id     | bigint                   |
 issue_id          | bigint                   |
 relative_position | bigint                   |
 created_at        | timestamp                |
 updated_at        | timestamp                |

There will be quite a few challenges to keep these positions up to date considering that our boards do not have any kind of hard links with the issues they display and basically run ad hoc queries to fetch the issues based on a set of filters. So we will need to update the positions when:

board settings change
board lists are added/removed/changed
issue is moved from one list to another
issue attributes change, e.g. label, iteration, milestone, assignee, etc

Also perhaps not all issues will have an entry in issue_boards_positions even if displayed on the lists in the board. Issues missing from issue_boards_positions would be displayed at the bottom of the lists.

I think we have something similar for epic boards. So perhaps we can borrow some code and ideas from that implementation.

cc @gitlab-org/plan-stage/backend-engineers

Why do we need to introduce a new table? I think the intent of this feature is to provide a way to update the existing relative_position value.

With a issue_boards_positions table it would be tough to keep it updated and sequential.

The biggest challenge here would be "Move to specific location" and figuring out what the current issue's position is. I think it will be possible to query this with PG window functions though.

@engwan because changing position on one board/list will affect position on all other boards/lists because we use a global position.

I'll let @gweaver weigh in if we are ok with that side effect, that has been there from the start. I just don't see how adding this extra functionality helps with the global relative position TBH.

Yeah, but that is already the behavior today.

I think the feature is just meant to be a shortcut or alternate way to change positions. So for example, instead of dragging an issue down 20 places, you can just click "Move to specific location" and then add 20 to the number.

If we want local issue board ordering that's #35663

I see! Definitely makes sense

@acroitor @engwan

I think the feature is just meant to be a shortcut or alternate way to change positions. So for example, instead of dragging an issue down 20 places, you can just click "Move to specific location" and then add 20 to the number.

Yes, that is my understanding of the proposal too.

Note that epic board list positioning is board specific. Depending if this extension should work for epic boards too (which I think would make sense), this difference should be taken into account.

The biggest challenge here would be "Move to specific location" and figuring out what the current issue's position is. I think it will be possible to query this with PG window functions though.

Currently when position is changed we pass move_before/move_after ids of items before/after which we want to place the issue, right? Maybe we could just extend API with passing also absolute position in the list and re-use Boards::Issues::ListService to get before/after issue ids from the absolute position? Boards::Issues::ListService should give us list of issues in the list, so we could just apply offset on this result query to get before/after issues for the absolute position, when we get before/after issue ids, we can just set these w/o needing to change repositioning code?

A concern related to this is that it adds additional query(ies) to already heave service (I remember I was hitting 100 query limit on the endpoint related to repositioning).

Yes, that's what I thought too about moving to a given position.

But in the designs above, there was also a number in the input box for position which I assumed to be the current position. I guess it's also fine to just leave this blank so we don't have to know the current issue's position in the list.

@engwan aha, good point. Leaving it blank would simplify things, also query to get list issues is already quite heavy so adding to this pile would be a concern as you pointed out.

Actually, I realize that the current position can actually be just a frontend thing.

When we load the first 20 issues of the list, we know the first one is "1", second is "2", etc.. When the user scrolls down to the second page, we just continue counting.

Note also that these positions are filter-dependent. Filters can also change the "position number" of an issue in the list. But I think that is fine and is the expected behavior. With a filtered list, I would expect that when a user moves issue to "position 3" it means at the third position of the list they currently see which includes filters.

Yeah I think this can be frontend only too. I think there still is a bit of complexity there so going to weigh as a 3. @cngo Can you please review this?

@donaldcook Adding the dropdown and using existing mutations shouldn't be too bad but with possibly complex logic I'd weigh it a 3 as well

I think the feature is just meant to be a shortcut or alternate way to change positions. So for example, instead of dragging an issue down 20 places, you can just click "Move to specific location" and then add 20 to the number.

Closing the loop here -- this is the correct interpretation of what we're trying to solve here. It's a UI-based helper function for quickly moving cards around a board without relying on DnD.

I think it will make sense to explore Local ordering on Issue Boards (#35663) when we start seriously planning for Improved Data Filtering and Visualization (&5516).

mentioned in issue #367472

added UX frontend labels

set weight to 3

/cc @nickleonard

FYI If "move to specific position" adds complexity, "Move to top" / "Move to bottom" are the priority; "Move to specific position" makes sense alongside these but we'd deliver value even without it in the initial iteration.

@nickleonard @gweaver I think it is safe to assume that in case the issue is already the first in the list , we should not show the option to Move to the start of list and in case it is already the last , Move to the end of list should not be visible ?

Also , in case the user enters a position that is not valid , for eg : 100 when the number of items in the list is only 2, should an error be shown to the user or an implicit logic be applied and move to the correct position ?

we should not show the option to Move to the start of list and in case it is already the last , Move to the end of list should not be visible ?

@deepika.guliani Thanks for the ping! We can either not show them or show the not relevant option as disabled. Up to @nickleonard!

Also , in case the user enters a position that is not valid , for eg : 100 when the number of items in the list is only 2, should an error be shown to the user or an implicit logic be applied and move to the correct position ?

Also up to Nick

we should not show the option to Move to the start of list and in case it is already the last , Move to the end of list should not be visible ?

@deepika.guliani I would simply always show it — the complexity of filtered views means it may be hard for users to recognize when something is top of this list or top of the overall list, so always allowing someone to explicitly move it to the top (even if the outcome is moving from 1 to 1) feels like it will be more clear than not showing that option.

Something to consider — if it's at all possible to track data on whether people use "move" actions from filtered or unfiltered views, I could see that informing later decisions around this functionality.

Also , in case the user enters a position that is not valid , for eg : 100 when the number of items in the list is only 2, should an error be shown to the user or an implicit logic be applied and move to the correct position

Implicit logic would be my recommendation, i.e. if value > list.length, move to last position. We should restrict this input to only integer numbers, setting a min of 1. This field should always be pre-populated with the current position so you can always "Save" in a valid state.

@gweaver @deepika.guliani Is the list position today base-0 or base-1? I'd definitely prefer to show a base-1 order for users, but are there places such as the API where a different value would be returned (i.e. we show "Position: 1" and API returns position: 0)? I still think that might be fine, but worth understanding the impact first.

@nickleonard to answer your question - the list is base-0.

@engwan Hey So I have a few clarifications ( which have rather been thought of mainly ) considering the current mutation only supports not index based moving but moveAfterId and moveBeforeId

When we Move to start of list we do know the first id of the list loaded then we can calculate
When we Move to the end of list and the number of items in list is <=10 --> simple we have everything
When we Move to the end of list and number of items in list is >=10 and everything is loaded --> simple we have everything
When we Move to the end of list and number of items in list is >=10 and all items are not loaded --> do we move after 10th item since more are not loaded ?
Move to a specific position when for eg that position is not loaded - similar use case - how to handle that ?

Maybe there is a way I am missing but I was wondering what would be the best way to make to purely frontend.

Should we be making the implicit call of loading all items in the board till the position or just all by default ?

This can't be purely frontend due to the reason you outlined above.

We will need a mutation argument to move to a certain position in the list.

The frontend thing I mentioned in #367473 (comment 1029026164) is only for displaying the issue's current position in the list. For issues that are visible in the list, the frontend knows the current position to show in the text box.

Sure @engwan , Added the backend label as well.

@engwan Do you know if there is a way to get the last item or last page with cursor-based pagination? Trying to determine if there is a way to implement Move to the start and Move to the end without backend work.

To get the last item, we can reverse the order and get the first item. But for our current "issues in board list" query, I don't think we have the option of specifying the order because it is always ordered by relative position (or closed date if it's the closed list).

So I think we'll need backend work here.