Have useful group order in ACL selector

[LukasKalbertodt]

Also something Olaf brought up today: if you have one group per course, then it makes sense to first show groups/courses that are more recent, for example.

But we already discussed that this is low priority, especially because it's kind of hard to implement. Also, users can always search through the groups, so the UX should already be quite good.

[oas777]

WTF?

[LukasKalbertodt]

Yep, exactly my thoughts :D will delete that and report the account, just wanted to have a look at it first. It actually forked this project and suggests a specific code patch (which absolutely does not work btw).

AI is amazing, bullshit as a service.

[oas777]

Reminds me of the ads in old school forums: "You want to fix the brake for you 1983 Cannondale ST500? Try temu.com for a solution!"

[LukasKalbertodt]

For reference, to understand our now hidden comments: there was an automated spam comment here before:

[mpmuc84]

We came across this issue recently, as we have several (~20) known groups representing university faculties and a few predefined additional groups. Currently, there does not appear to be any sorting going on (I might be wrong about that!), at least we could not see where the order of the list comes from (not the primary role, not any of the labels). The dropdown menu shows the list in the order of the API response, as far as I can see.

Barring a user-controlled option to sort the list: Would it be possible to either set some default sorting for the dropdown or the API response, so that users may have a better way of navigating the list (without having to type to search)?

Granted, a list of 20+ organizational groups is nothing compared to a list of courses (possibly spanning multiple semesters), but the current display of a list completely without any ordering and having to rely on users searching via text input looks not ideal, at least to me.

[LukasKalbertodt]

True, these groups are currently not ordered at all, we just load them from the DB and keep whatever order the DB passes them to us. That's certainly not ideal.

We could just sort them by label, but that's often also not ideal as some groups will be used much more often (e.g. "Everyone", ROLE_ANONYMOUS). In the table showing the already selected groups, we sort by "size", i.e. a group that contains another group is always listed before that other group. This implies ROLE_ANONYMOUS being listed first, followed by ROLE_USER, and then the rest. We can do it like that for the group selector as well. And all groups without "contains" relationship are just sorted by name in their bucket. Would that be a useful solution?

[mpmuc84]

This does indeed sound like a helpful solution. I definitely see the advantage of having "larger" or more frequently used groups at the top of the list. Sorting the rest by role name makes sense to me as well, and this way we could achieve some sort of consistency.

Let me know if you need more input from our side.

[LukasKalbertodt]

@mpmuc84 Could you send me your groups.json with those 20 groups? (stripped of sensitive information, if necessary). That would allow me to better judge how useful an ordering by implies relations is. Because I fear that it will confuse users, as that relationship is not immediately obvious. For example:

This is the dropdown with the following groups (where ROLE_ANONYMOUS is already selected/in the ACL):

ROLE_ANONYMOUS <- ROLE_USER <- ROLE_STUDENT
                            <- ROLE_STAFF <- ROLE_LECTURER
                                          <- ROLE_VIP_STAFF

With <- showing the implies relationship. Tobira cannot know whether "students" or "staff" is a bigger group. Tobira can only compare groups where one (potentially indirectly) implies the other. Therefore, students is at the bottom of the drop down.

Alternatives:

• Just alphabetic
• Alphabetic, but put ROLE_ANONYMOUS and ROLE_USER at the top (i.e. only two exceptions)
  • Note: if your groups don't use the implies relationship at all, i.e. all groups are just one level below ROLE_USER, then this is the same as the first idea described above.
• Just use the order in groups.json. Would give full control to admins, which can be a blessing and a curse :D

Thoughts?

[mpmuc84]

I just sent you the groups.json directly.

Personally, I would welcome the option to define the order in groups.json, as it would give the option to potentially prioritize certain groups. But this is just my preference.

I could very much see the list being sorted alphabetically. However, in my opinion this should respect the currently selected language, as group labels may sort differently in different languages (e.g. Katholisch-Theologische Fakultät vs. Faculty of Catholic Theology or Dozierende vs. Lecturers).