The admin screens for groups are clear. One may assign a group to another (main) group. Any user that is assigned to the first, becomes automatically a member in the second. As long as the 'hierarchy' is flat, that is 2 deep, there's no problem. What about the following:

I do have friends, special friends and very special friends. Ann is a very special friend and appears in all 3 groups. Bill is just a friend and appears only in the friends group.
To achieve this I must tell GL that the friends group is subordinate to the special friends group which is subordinate to the very special friends group. So, while my listing of friends will contain friends, than special friends, than very special friends, the GL structure is upside down to achieve this: very special friends contains special friends contains friends. This is somewhat counter intuitive, and the wording is misleading too with respect to the intentions.

When Bill becomes a special friend, I just add him to that specific group. Does this create a second group assignment row ?

And more. Now I am in a mobbing war with Ann and she is not a very special friend any more, but it is not so bad that she is no longer a friend. So, I will remove Ann from the very special friends group. And whoops! She is gone in all groups. cannot even update the groups in one go.

The problem is, off course, that I don't remember how I did structure these groups after all, and there is no easy way to show it to me, in GL that is.
What is missing is a tree view of groups and users.

Good points.

A tree view would be helpful but difficult to load as the groups could become circular if the Admin has things setup differently like:

A belongs to B, B belongs to C, and C belongs to A.

You should put a feature request in for this on GitHub.

The jQuery tree control would have to be able to load nodes on the fly and handle groups that have a lot of users (thousands).

---

One of the Geeklog Core Developers.

Well, in that case, no Admin could remove a user from neither A, neither B, neither C, while any membership generates membership in all of them. Worse, adding one of these groups to another (independent) group has a similar effect for that (independent) group.

And, according to the admin screen:



So, GL should detect such circularity and deny the update.

Unanswered question: when I add (my friend) Bill to my special friends, does that generate a row in the table group_assignments?

Yup we would have to make sure that detection is in place



I would have to look at how things work in the code (I am travelling at the moment) but adding Bill to special friends should generate a record, he would also have one in friends. If using the tree view and you dragged him over then you could consider it a move I would think..

---

One of the Geeklog Core Developers.

Got the logic behind the GL processing figured out. In short it means that the admin screen for Users is not consistent, but not in all cases.
What happens, is that GL updates the group_assignment based on the tick boxes, which is incorrect and leads to confusion. In fact, GL should distinguish between permanent membership and inherited membership.

Example.
Bill is a friend and has one row in the group_assignments table. When Bill is added to special friends, he has two rows in that table.
Ann is a very special friend and has one row in group_assigments table. The admin screen however shows me she is a member in friends and special friends with the blue tick boxes.
Now, saving Ann again using the admin screen, she suddenly has three rows in the group_assignments table. The resulting admin screen is the same, though the database is in a different state.

Another example.
Somehow I decided that all very special friends should be able to moderate comments for a short period, so I added that group to my very special friends. That works. After that short period I remove the group again. This works, but not for members of very special friends that went thru an update using the admin screen: they stay in the comment moderation group.

Proposal.
The admin screen should reflect the state of the membership, either permanent (blue), either inherited (proposal: green). Than, GL only updates the table according to the blue tick boxes and ignores the green ones.
This can be done by a select value, rendered as a tick box. Whereas a mouse hover can reveal the parent group(s). This eliminates the need for a tree view (and the hidden code for shadowed tick boxes).

There exists a similar issue with the rights admin screen. The effects are even more confusing.

Example.
Include polls admin in a group. The polls admin rights show now with a shadowed tick box.
Try to edit this group to remove just one (polls) right. Impossible. Just save now.
After you tried this, the next screen shows blue ticket boxes. Remove one (polls) right. Save.
GL won't let you do this. The right returns with a shadowed ticket box.
Damn. Than remove the group polls admin from that group. Now you get those polls admin rights permanently with blue ticket boxes (out of the blue).

Sometime I was even able to let toggle some poll admin rights between blue and shadowed without even having the poll admin included.

This screen also could make use of the proposed green ticket boxes. It than shows which rights are inherited (they show now as shadowed ticket boxes, until the group is saved again) and which rights are permanent. Than Admin can choose if he wants to make one of these inherited rights a permanent one. Currently this is only possible by adding polls admin, save twice, remove polls admin and save, than remove the desired permanent rights. Not very intuitive.

One may say, that is far sought, or, this is no real world problem. Fact is, as soon as you work with hierarchical groups, you will get caught by this.

The user screens is one of the few areas I haven't really worked on (and I don't have the code to look at currently). Sounds like you have found a few issues. What you propose with the colors makes sense.

In regards to the DB, are you saying that when the special friends group is added to the friends group, users of the special friends group get additional records for the friends group? (and it is not inferred that the are a member of the friends ground because of the hierarchy of the groups). I don't think we can easily change how the basics of this works as we would have to rewrite the user security functions and depending on the groups hierarchy this could create some complex SQL statements which might affect plugin compatibility (hard to say without looking at the code). What we could do to solve the issue would be to add an extra column to the group assignment table that shows that it is an inherited group assignment. Not sure if this would work with multiple nested groups though as I would have to take a look at the code and db structure.

Would you be able to add the bugs to our GitHub repository and your proposal as a feature request?

https://github.com/Geeklog-Core/geeklog/issues

It will be easier to discuss the specific points.

---

One of the Geeklog Core Developers.

Well, I don't have access to Github.

On the other hand, the issue is a design issue. GL code is in place for inherited groups and inherited rights. The docs and instructions mention the feature, but lack to describe how it is done.

There should be a warning that removing groups could cause that users simply disappear from parent groups, or worse, that the inherited rights stick to the user(s) affected.
The lack of such warning would say (to me) that they don't stick and that user(s) not simply disappear.
And this issue, off course, is introduced by the GUI of the admin screens with underlying update scripts. The GUI suggests database contents (membership of inherited groups) which is not there but will be there as soon as one saves a second time.

So, I am in need to know how the feature(s) are (or should be) implemented in the database.

Note: I have added this issue to GitHub as well: https://github.com/Geeklog-Core/geeklog/issues/803

---

One of the Geeklog Core Developers.