[Bug]: Group permissions bugged

[swift2512]

Snipe-IT Version

v8.3.4 - build 20218 (master)

PHP Version

PHP 8.3.23 (cli)

Composer Version

Composer version 2.8.6

MySQL/MariaDB version

mariadb Ver 15.1 Distrib 10.6.22-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper

How did you install Snipe-IT?

Git install

Is this a fresh install or an upgrade?

Upgrade

What happened?

First of all - Report Access can be set to GRANTED/DENIED at the same time. If saved - it stays like this ant can't revert to GRANTED or DENIED only. (Confirmed on Snipe-IT Demo.)

Second issue is related to large user count in group. This may be only related to my installs. (Couldn't test it on Snipe-IT Demo due to restrictions.) Basically, if add more than 882 users to that permissions group (my case), you will loose number of permissions based on number of users you are over 882, when that group is edited and saved. (You don't need to change any permissions - just press Save in edit page.) No errors are shown in DEBUG mode, nothing saved in laravel.log file - green banner with success message.

Third issue - users are stripped of permission group membership if there are more than 995 users in that group.

1. Have a permission group with 1000 members.
2. Edit that permission group (EDIT -> SAVE)
   Result: only first 995 users are left in that group (in my case), other remaining users are removed from that group.

What browsers are you seeing the problem on?

Firefox, Microsoft Edge

Can you reproduce this on the public demo?

Yes

Do you have full multiple company support enabled?

Yes

If you have full multiple company support enabled, do you have location scoping to company enabled?

No

Application log output

Browser console output

Common Issues

• I have searched this repo for existing issues related to my issue (including closed issues)
• My APP_URL is set correctly in my .env file (including http or https and no trailing slash)
• I have searched the official Snipe-IT documentation and have checked the Common Issues documentation (where applicable)
• I have run database migrations (where applicable).
• I have attached screenshots and/or videos of the issue (where applicable)

Code of Conduct

• I agree to follow this project's Code of Conduct

[snipe]

First of all - Report Access can be set to GRANTED/DENIED at the same time. If saved - it stays like this ant can't revert to GRANTED or DENIED only. (Confirmed on Snipe-IT Demo.)

Checking

Second issue is related to large user count in group. This may be only related to my installs. (Couldn't test it on Snipe-IT Demo due to restrictions.) Basically, if add more than 882 users to that permissions group (my case), you will loose number of permissions based on number of users you are over 882, when that group is edited and saved.

That's... a weird one.

[snipe]

995 is such a random number...

When you load the group in the edit screen, do you see all 1000 selected, or do some of them fall off from the users selection menu on that edit screen page load?

[snipe]

Just a quick update here - the permissions being lost seems directly related to the number of users that are pre-selected. 500 users in a group, everything works fine. 1000 and I see the same thing you're seeing, although I have absolutely no explanation for that behavior. For now, I might just do a check for selected users and if it's over 990, hide that user selection menu, just so folks don't end up accidentally dropping permissions on the group. This would just be a short term solve and we'll figure out a longer-term solve shortly, but I'd much prefer not have people accidentally falling out of groups, especially when there are so many people, you wouldn't necessarily notice while looking at the page.

[swift2512]

@snipe It has to be some sort of limit how many entries can be written to the database. Because it's not only affecting 'People' and 'User groups', but also 'Assets'. I ran a quick test and find out that with every new custom field added another cell is left unfilled. (1000 entries per page.)

[snipe]

It has to be some sort of limit how many entries can be written to the database.

It's definitely not that.

I ran a quick test and find out that with every new custom field added another cell is left unfilled. (1000 entries per page.)

That's expected though. When viewing all assets, it has to show you all custom fields, filled or otherwise, since viewing a broad list of assets will inherently include a mixture of models which may have a mix of custom fields.

[snipe]

Quick question. In your php.ini file, if you change these variables, do you still have the problem?

max_input_vars = 2000
max_multipart_body_parts = 2048