Updating the list of users in a workgroup has two bugs
Closed this issue · 11 comments
When going to the 'show' page of a workgroup, as admin, we have the ability to change the list of users that are members.
This shows up as two big array of checkboxes when we click 'edit' in the Members section. See screenshot. This then shows up a new form with several large tables of checkboxes:
A) a table with all users and a checkbox for them
B) a table called "Quick select based on other projects' which lists other projects
C) a table called "Quick select based on site projects"
This issues is about table A and B. Table C doesn't seem to have any bugs.
- the users already members of the project don't have their checkboxes pre-selected in table A
- table B is supposed to help select users by clicking on a checkbox of another project, and all users of that project will get selected in the users tables. This works, however, it's not supposed to work in reverse. When the admin selects a user in table A, some of the projects in table get get checked too!! Selecting a user in table a is not supposed to trigger anything in table B.
I suspect there is a confusion about the IDs and classes associated with the normal checkboxes in table A and the master select checkboxes in table B.
Correction the 'other site' table 'C' is not affected just because few to no active users are member of 'other site' groups in production.
Okay, so it's possible I didn't notice the bug also affected table C. In any case, all these bugs should be fixed.
Also the second bug happens on user selection forms of the create new group page
More careful investigation shows that issue 2 is not a bug a feature purposely introduced by Natacha. Yet if annoying can be disabled on group member page, or alleviated by removal of one-member groups from UI: I find it annoying when clicking just one user enables bunch of tiny groups, also 1 or even 2 user groups are not as efficient and take valuable spcae. The first issue easy to put band aid yet did not figure how and why it was introduced yet
Issue 1 is the most important though: if I edit a project to add a new member, I don't want to lose all previous members! It happened to me on Wednesday when I was trying to add someone to an access project and I was furious.
Folks, don't spend to much time on problem 2 : if my initial bug report is not actually a bug but a feature and that the changing checkboxes are consistent back and forth, then let's leave it exactly as it was, I can live with that.
What is much more improtant is bug 1 : again today I tried opening the show page for a group in CBRAIN to add a user, and the checkboxes for the users already in the group were not already pre-selected. That is BAD !
well natacha fix seems work, though I suspect it would be more elegant to change on-load to assign the principal checkbox value based on subordinate checkboxes (maybe for non-persist cases only not sure).
for 'Bug 2' I would suggest just ditch less-useful small groups, to reduce annoying flicking. So most of case you would need click on few users to enable new groups which gives user idea how feature works. Something like
<%= check_box_tag("#{parameter_name}[]", user.id.to_s, @group.select {|g| g.users.length > 2 }.users.map(&:id).include?(user.id), { :class => (@users_multi_select_classes[user] || "") } ) %>