Snipe-it: Bulk User Edit - Group Permissions Not Applying

[fletch8527]

Please confirm you have done the following before posting your bug report:

• [ yes ] I have enabled debug mode
• [ yes ] I have read checked the Common Issues page

Describe the bug
Users are not assigned permissions from a group when being added to that group using the bulk edit option on the People tab. If you edit the user individually it works as expected

To Reproduce
Go to People tab
Select some users (even just one)
Select the Bulk Edit option at the top
Assign user(s) to a group

Expected behavior
Users should be put in the group (working) and assigned permissions of that group (not working)

Screenshots
If applicable, add screenshots to help explain your problem.

Server (please complete the following information):

• Snipe-IT Version: 4.3.0
• OS: Windows Server 2016
• Web Server: IIS
• PHP Version: 5.6.31

Desktop (please complete the following information):

• OS: Windows 10
• Browser: Edge, Chome
• Version: Latest

Error Messages
Unable to test in demo and I would need to need to see actual database to confirm issue. No errors listed.

Additional context

• Is this a fresh install or an upgrade?
  Upgraded from 4.2.0
• What method you used to install Snipe-IT (install.sh, manual installation, docker, etc)
  Manual
• Include what you've done so far in the installation, and if you got any error messages along the way.
• Indicate whether or not you've manually edited any data directly in the database

Add any other context about the problem here.

In trying to find the issue I connected to the DB to see if I might uncover something. That's when I noticed that users that were added to their first group via bulk edit(the users were imported from LDAP and never assigned to a group on SnipeIT) that their permissions field was still set to NULL. But when I added users individually to a group I saw that their permissions field got populated with all the different access levels set to 0's. It seems that when that permissions field is set to NULL but they are assigned to a group that has permissions that those group permissions are ignored.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[snipe]

You're conflating two different things, I think. Permissions on a user can be null. If you edit a user and do not grant them additional person-level permissions, that field will be populated, but with "inherit" as the permission. This is basically just a side-effect of editing and saving a user, since the form fields on the permissions tab for the user will be collected and added to the user's permission - but null works the same as having that user permissions field populated with nothing but "inherits".

[snipe]

Could you break down (with screenshots) exactly the use case you've got here? What should the user be able to do, not do, what permissions does the group have/not have, what permissions the user has/is denied, etc.

[fletch8527]

I realize that permissions in the user table is for user specific permissions and that permissions in the group table are different. I created a group called "Users". That group only has View Requestables permission.

I bulk edited all of my users and added them to the "Users" group but when a user logs in they can ONLY see their assets, and the Requestables is not shown on the left when the user's permissions field in the user table is set to null.

If I edit that user individually it will update their permissions field in the user table and after that the user can now see the Requestables. I replicated this by modifying the DB directly (setting it to null and then back). Attached are screenshots of both situations.

[fletch8527]

Just to clarify, I made no other changes between those screenshots other than editing the user individually. I changed nothing in the users edit page, only clicked Save. Also note that if I select just that one user and use the bulk edit option is will not update the permissions field in the user table for that record.

[fletch8527]

I just upgraded to PHP 7.1.17 and SnipeIT 4.4.1 and can confirm that the issue is still happening.

[snipe]

I bulk edited all of my users and added them to the "Users" group but when a user logs in they can ONLY see their assets, and the Requestables is not shown on the left when the user's permissions field in the user table is set to null.

The user's permissions being null is to be expected. Associating a user to a group doesn't change the individual user's permissions, only group affiliation.

You're seeing the permissions mask when you save a user individually because you're submitting the user's permission form (in the permissions tab when you add/edit a user). They're set to inherit from the group if nothing special is selected there.

In your User's list, after a bulk edit, does it show the user as belonging to the Users group? (You may need to show the Groups column in your listing).

[andrefecto]

I am having the same problem and I'm a little confused by the responses from @snipe . My process is (after an LDAP import of new users) I click the checkbox next to their names in the "Current Users" list then click "Bulk Edit"

I then click the group I want them to belong to.

When I am brought back to the "Current Users" screen the users show as being apart of the chosen group, in the "Groups" column.

However, when one of these people try to log in, they do not have the permissions granted to them by their group that is shown in "Groups" column.

To have the permissions take effect I have to navigate to the specific user and click "Edit" then all I have to do is click "Save" without making any changes. Then once they refresh the page, the groups access rights take effect.

Is this not what the bulk edit is supposed to be used for or is this a bug?

[nixn]

I got this issue too and wrote a PR (#6229). It's an error in the checking of user permissions while the user's permission is NULL in the database.

[ajsy]

I am having the same problem too, here is the workaround
update database, users table, permissions column

if the value is NULL , then update to

{"superuser":"0","admin":"0","reports.view":"0","assets.view":"0","assets.create":"0","assets.edit":"0","assets.delete":"0","assets.checkin":"0","assets.checkout":"0","assets.audit":"0","assets.view.requestable":"0","accessories.view":"0","accessories.create":"0","accessories.edit":"0","accessories.delete":"0","accessories.checkout":"0","accessories.checkin":"0","consumables.view":"0","consumables.create":"0","consumables.edit":"0","consumables.delete":"0","consumables.checkout":"0","licenses.view":"0","licenses.create":"0","licenses.edit":"0","licenses.delete":"0","licenses.checkout":"0","licenses.keys":"0","components.view":"0","components.create":"0","components.edit":"0","components.delete":"0","components.checkout":"0","components.checkin":"0","users.view":"0","users.create":"0","users.edit":"0","users.delete":"0","models.view":"0","models.create":"0","models.edit":"0","models.delete":"0","categories.view":"0","categories.create":"0","categories.edit":"0","categories.delete":"0","departments.view":"0","departments.create":"0","departments.edit":"0","departments.delete":"0","statuslabels.view":"0","statuslabels.create":"0","statuslabels.edit":"0","statuslabels.delete":"0","customfields.view":"0","customfields.create":"0","customfields.edit":"0","customfields.delete":"0","suppliers.view":"0","suppliers.create":"0","suppliers.edit":"0","suppliers.delete":"0","manufacturers.view":"0","manufacturers.create":"0","manufacturers.edit":"0","manufacturers.delete":"0","depreciations.view":"0","depreciations.create":"0","depreciations.edit":"0","depreciations.delete":"0","locations.view":"0","locations.create":"0","locations.edit":"0","locations.delete":"0","companies.view":"0","companies.create":"0","companies.edit":"0","companies.delete":"0","self.two_factor":"0","self.api":"0","self.edit_location":"0"}

after that go to Bulk Edit and update the Groups

[snipe]

This issue is resolved on develop and will be in the next release.

[halaszarpad]

Hello,
I have just updated to the latest release 4.6.15 build 4011 and this bug was not fixed yet.

[edg4rgarci4]

@snipe you say this is fixed but it was never referenced as a bug fix on any of the releases...

[meyerje]

Fresh install and this is still an issue. Edit single user, change nothing, click save, and the group permissions apply.

[Joly0]

I have the same problem. If i import Users with Ldap from my AD Server and bulk edit them and add them to user group which should make them able to see all assets, it doesnt work. I have to click on every single user, edit and click save, only then, group permissions are set.

[nicosalvadore]

Same issue on my installation : v4.9.3 - build 4395

[namarie23]

This is still very much an issue, I have to delete the users, reimport them, then manually select the group.

[namarie23]

Any fix or workaround for this @snipe ?

[meyerje]

Any fix or workaround for this @snipe ?

We are doing the same thing. Delete user, reimport, then manually select the group.

[Joly0]

If your problem appears after ldap importing users and then no group permissions are applied, then I opened a Pr to fix this, but it hasnt been merged yet. You can look it up, its mentioned here in this issue and use the modifications that i used to fix this for me.

[meyerje]

I did try using the Pr you have Joly0 but had an error. Will reattempt, and thank you for contributing a fix for those affected.

[namarie23]

If your problem appears after ldap importing users and then no group permissions are applied, then I opened a Pr to fix this, but it hasnt been merged yet. You can look it up, its mentioned here in this issue and use the modifications that i used to fix this for me.

Completely missed that, thanks I'll give that a try!

[nixn]

I already wrote a PR in 2018 (#6229), which was merged into the develop branch, but apparently has not made its way into master. Did you try it too?

[meyerje]

No, but I definitely will nixn, thanks!
Edit: It's working great, thank you again!

[namarie23]

I already wrote a PR in 2018 (#6229), which was merged into the develop branch, but apparently has not made its way into master. Did you try it too?

Hi Nixn, your fix worked beautifully, thank you!!

[nixn]

This issue is resolved on develop and will be in the next release.

Looks like this was not the case, @snipe ...