⚠️ While it works visually, the sorting order is not persistent; #6002 (comment) still seems valid in the sense that, even when the race-condition gives enough luck to go through the "right" function,

After arranging list of one boards, browsing to another board and then come back to the previously used board, reverts the order of lists to the order of creating them.

Maybe another issue should be opened, if I understood correctly so far.

I think that this second commit mitigates the issue of sorting saving for the same reason: the stop() method associated with sortable components was defined twice, with the same timeout, but one of the method did not have the save logic.

I tried not to touch the code too much (and sorry about my IDE and spacing/tabs, haven't checked this time), but I have a few remarks/things about I'm not sure:

• initSortable is never called yet contains recent code (for the future?) but I used a function to deduplicate the saving code;
• I have no idea what listGroups are, so I let the whole code at the bottom of the file even if some parts felt duplicated to me;
• I had to add updatedAt (and modifiedAt for a reason I couldn't find in client code) in authorized fields of the list's model to avoid console warnings.

Still on my example old Wekan instance, running with those patches, persistent sorting of lists now works and I hadn't seen other impacts yet, but, as I said, I am kind of in the dark.