Allow to manually reorder "normal" folders

[pabzm]

Protected folders like INBOX, Sent, etc. are staying at the top of the list.

Fixes #5003

TODO:

• Fix broken state after folder renaming
• Fix the styling (equalize white space around list elements through padding, avoid ID as selector)
• Figure out if the item was moved between protected folders, which is not allowed.
• Save only if the folder list is different than at start (Not worth the effort)
• In the receive callback, can we wait for the confirmation dialog without introducing async/await and Promises?

Screenshots:

---

---

---

[johndoh]

I like the idea of allowing users to reorder folders. I think having different drag behavior depending where on the

element you click is a bit clunky, it would be nice if both functions (change parent and change order) could be combined somehow. Putting the drag icon next to the subscription toggle could lead to fat finger problems, I suggest putting it at the start, something like this:

Out of scope for this PR but adding a similar drag icon the rule list in the managesieve plugin would also be nice, highlight to the users dragging is possible - so the implementation should be done is such a way the drag icon can be added to any list.

[alecpl]

On desktop we could use a drag+Shift button. There would be no need for an icon. Well, the icon could appear while dragging, or not. The drop target indicator would be different, i.e. to move folder we highlight the target folder (on hover), while to re-order a folder we highlight the border between folders.

That would not work on a touch device, though. But I wouldn't mind if that functionality was a desktop feature only.

Finally, maybe it would make sense to limit reordering to top-level folders only?

In any case it would be good to have it consistent across all places (i.e. Filters).

[pabzm]

I found a technical solution to combine both actions, reordering and moving into (and out of) subfolders. It will take some more working days to adapt it to Roundcube's code, though.

[pabzm]

The current state needs some more styling love, but maybe you can already have a look at the functionality, which works as far as I see. There's no sorting handle anymore since all dragging now allows to sort and move into and out of sub-folders.

[pabzm]

Locally the browser tests are green, so I assume those errors are a CI artefact. The "Static Analysis" failures are also unrelated.

[johndoh]

I like the combined drag action better. For me in dark mode an extra line appears between parent and child folders not just on the setting screen but on the mail and contacts screens as well. Using Firefox.

If the last folder in the list has a sub folder and you want to drag a top level folder to the bottom of the list its tricky.

When I drag a sub folder from one parent to another it saves but the UI does not update, have to refresh the page.

[Neustradamus]

@pabzm: Nice PR, good job!

Note: A feature must be here to have A->Z order OR manual choice.

[pabzm]

@johndoh Thank you for the feedback! I improved the styling in dark (and light) mode a little, and gave the list's a bit more space at their end to make it easier to drop elements there.

When I drag a sub folder from one parent to another it saves but the UI does not update, have to refresh the page.

I cannot reproduce that. Could you check for errors in the browser console or anything else that appears remarkable when that happens?

(I'll continue work on this in ~2 weeks.)

[pabzm]

@Neustradamus The default and fallback is alphabetical ordering as long as you don't start to order the folders manually.

[johndoh]

I think may be the list not updating problem only happens when a custom order is first applied.

program/js/app.js:8183
Uncaught ReferenceError: next_sibling is not defined

for me this fixes the issue:

diff --git a/program/js/app.js b/program/js/app.js
index 08a57a0db..930741e4c 100644
--- a/program/js/app.js
+++ b/program/js/app.js
@@ -8163,11 +8163,9 @@ function rcube_webmail() {
             delete ref.env.subscriptionrows[fname];
         });

-        if (this.env.folder_ordered_manually) {
-            // We need to store this information now, because it's not available anymore after removing the row from
-            // the DOM.
-            next_sibling = row.nextElementSibling;
-        }
+        // We need to store this information now, because it's not available anymore after removing the row from
+        // the DOM.
+        next_sibling = this.env.folder_ordered_manually ? row.nextElementSibling : null;

         // get row off the list
         row = $(row).detach();

[alecpl]

It does not seem to be finished. It has a lot of issues at this point.

[Neustradamus]

@pabzm: Can you look your PR?

It will be nice to have in Roundcube 1.7 final...

Thanks in advance.

[pabzm]

I fixed some more styling issues and handling quirks and added buttons to move a folder up and down the list (for people that can't or don't want to use drag-and-drop).

From my point of view this is now ripe for a proper review and hopefully merging, too.

[pabzm]

Here's a new screenshot with the mentioned buttons:

[pabzm]

It does not seem to be finished. It has a lot of issues at this point.

@alecpl Could you let me know which those are?

[pabzm]

I rebased on the latest of the "master" branch to try and get rid of the unrelated CI Coding Style errors

[pabzm]

Rebased onto the lastest of "master" to get rid of the CI errors

[alecpl]

I still don't like it, but I have two options to try:

1. Whenever you're above a folder display all drop areas at the same time, i.e. above, below and subfolder. This will probably create a jumping effect, so it will probably not work.
2. Don't display additional drop areas, highlight the folder only. When you drop a folder display a popup menu (like we do when you drop a mail or contact with Shift key) with three options: move above, move below, move below (as a subfolder).

[pabzm]

I will not pivot to a completely new behaviour with this.

If small changes would be required to make this merge-able I would put in a little more effort, but beyond that I won't spend more time on this. If you don't want to take it, I'll leave it open for someone else to adopt.

[alecpl]

I think it requires more than small changes. I have one more option to consider. Instead of drag-n-dropping a folder into any place we should consider a different approach.

It would be marking a folder as a special folder ("high priority folder" could work to, but might get confusing with mail priority). It would make any non-special folder to be put immediately after special folders, i.e. close enough to the top of the list. This way there's not much room for the feature to be abused, and it's much simpler, at the same time fulfilling 90% of cases. Imo, a main case users want is "I want this folder somewhere on top so it is easier to find", but I might be wrong.