Would love some input from the community on something I’m stuck on
Objective: let a user re-order a list of Collections inside a Custom Collection.
I have a Custom Collection, with source Sections inside a Plans - working table - this Sections is a Relation that links the Plan ID for the Plans - working table to Sections>Plan ID (matching multiple).
This Custom Collection has Collections inside it. Each Collection has a source Sections_Moves which is a Relation that links Move ID array (an array) to Moves>Row ID (matching multiple).
I want a user to be able to click those up and down arrows per Collection, and it moves the Collection up / down as needed.
If a Collection is already at the top i.e. the first item, then clicking ‘up’ doesn’t do anything (or the button is hidden entirely)
If a Collection is at the bottom i.e. the last item, then clicking ‘down’ doesn’t do anything (or the button is hidden entirely)
What I’ve tried:
Having a numeric ‘Order’ column in the Sections table, and then using a combination of relations & look-ups to change the order of the item, the previous item and the next item all at the same time e.g. if Collection B is to go from order 2 to 3, then Collection C goes from 3 to 2, and Collection A stays as-is (and the other way around if Collection B is to go from 2 to 1).
Screenshots of the table below, in case it’s helpful:
Gotta ask…is the use of user specific columns for Section Name and Order intentional? Meaning each user can organize sections differently?
As for your issue, I think you are on the right track. There isn’t a great way to handle custom and dynamic sorting without some trickery, unless you use a kanban, which allows you to drag and drop, but I’m guessing that might not work for you.
I’d be interested in seeing more of your setup regarding your relations and button actions. Seems like you are close, but I’d like to get a better understanding of why you end up with two items that have the same order number. If you wanted to move an item down for example, you would have a single relation to the next item. Then your button action should be setting the order number of the item inside the relation to the item number of the current item. Then follow that with a second action that sets the order number of the current item to the next order number. Maybe with an increment action or a math column that takes order number from the related item that was just changed, and adds 1.
Haha good question - for context, this is for a fitness app I’m prototyping. So ultimately every user will have their own Sections of ‘Moves’ (i.e. exercises), and can’t see Sections from other users. So I figured Section Name should be user-specific. However, on reflection, I guess Order doesn’t need to be (and also a ‘Temp Order’ column I have)?
Here’s my current button action set-up (incoming image flood!):
My collection is pretty simple. You have a column with the order number as a basic column. So you need to initially set a value to it. You can automate that part with other workflow if needed. But for the example, I will show how I made the rearrangement possible!
In the buttons block, set two buttons with two different workflows. You can actually use only one workflow and a condition to go up or down, but I thought that it was simpler to make two workflows.
@rathbala I finally had a quick minute to look at your screenshots. I think the problem might have been that you were updating the related row last in your action flow. I’m suspecting that when you changed the order number for the current item, the relation recalculated so it was pointing back to itself in some cases, so there was no longer a related path to the row you wanted to update. Instead, you just ended up setting the order number for the current item, through the relation, to the same number it was all set to in the previous action. The related item you wanted to change never got changed. I think if you had swapped the last two actions in your action flow, it would have worked because you would be updating the related row before updating the current item.
In either case, @MaximeBaker’s solution works just as well. Just wanted to explain what might have been happening to you before.