This one is more easy to fix without potentially broke existing code.
I fix it quickly

The other need fix :

• we use owner_id : in 3.X , user can create a group and be removed from group by super admin : then need a owner_id update
• we keep same 3.X functionality ;: what to do with previous group ? Nothing : 18289 still there, Updateing to put owner_id in group : always needed ? Broke potential Permission usage.

Well, you are asuming this is bug.
By looking at the discussions on the other tickets, I am not sure it is a bug.

In 3.X , user can create a group and be removed from group by super admin : then need a owner_id update

In 5: user can not see the group after creation…

@ollehar : see other ticket, way to resolve and owner_id issues

With usercontrolSameGroupPolicy
In 3. X :

1. creator are added to user list
2. if superadmin remove user from group
3. creator didn't see group (i didn't test with hacking forms …)

In 5.X :

1. creator are NOT added to user list
2. creator didn't see group
3. But creator seems have some rights on usergroup (Maybe he have same right in 3.X)

See : https://bugs.limesurvey.org/view.php?id=18281#c71525

My opinion :

1. This fix this issue and ONLY this issue : minor impact

2. To have a clean owner_id system and Permssion systeml for view : we need to move to PermissionTrait for user and usergroup :

3. usercontrolSameGroupPolicy == false => All user have read rights on user and on groups

4. usercontrolSameGroupPolicy == true => User have read right if in same groups OR if there owner in group

5. user with create right : owner_id is set : user can see it (and move to group)

6. User update can only update if he have read rights on this user

7. We need a update owner in UserGroups + Users (but it(s a new feature)

PLease solve it this way:

For LS5:
The group owner should be member of the group. The patch fixes this, but points to the wrong branch currently (master instead of 5.x).

For LS6:
The group owner can be a group member, but doesn't have to be. However, the group owner should always be able to see/edit group members.

The group owner can be a group member, but doesn't have to be. However, the group owner should always be able to see/edit group members.

Then : need a Permission system adding owner_id in Group model.

Right ?

For LS5:
The group owner should be member of the group. The patch fixes this, but points to the wrong branch currently (master instead of 5.x).

Pull request from Aug 26, 2022 …

@DenisChenu what is the status of this ticket? I see one PR https://github.com/LimeSurvey/LimeSurvey/pull/2581 but it is not clear to me how should I proceed.

I need toi update for last 5.X
And create a new one for 6

Ready for 5.X

5.X : https://github.com/LimeSurvey/LimeSurvey/pull/2581
master : https://github.com/LimeSurvey/LimeSurvey/pull/3504

Fix committed to 5.x branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=35563

Fix committed to master branch: http://bugs.limesurvey.org/plugin.php?page=Source/view&id=35564

Tested and merged.

Fixed in Release 6.2.10+231004

Unluckily, the v6 PR didn't considered a refactorying we have done.
https://github.com/LimeSurvey/LimeSurvey/pull/3447/files#diff-0a0e2b974470e717a216950e1374f76ba04f409a55f562a9b59f91cb79451ccd

Why our refactoring got lost?
#18995 was done & merged.
Then reverted.
That's when this ticket got done.

Not sure what's the best way to handle this.
I think it is best if @DenisChenu you could take the refactoring and merge it in the code you did.

What do you think?

It's about getUserList and protected static function getPermissionCriteria ?

Right ?

Then best seems to include Permission::Trait ,

But totally related to User Permission (update/delete)

V6 PR do the minimal update to fix this issue.

The getpermissionCriterai is realted to whole Permission system for User