We are excited to announce some updates to how Groups and Restrictions function in version 2.34.0!
Here is what is changing:
- A default group must be designated
- All users must be in a group. Note: this does not apply to admins or super admins, as they cannot be in groups.
- Users can be added to multiple groups.
- Administrators have more opportunities to customize and bulk manage group permissions.
Below are some frequently asked questions and answers to help you navigate the new changes.
FAQ
Q: What happens if I did not have a default group designated prior to this update?
A: If you did not have a default group designated prior to this update, Hudu will automatically create one called Default Group that will not have any access to companies or to the Global KB. You can change this by designating a different group as the default group if needed. Once you have designated a default group, you can delete the one Hudu created.
Q: What happens to all the users who were not in a group prior to this update?
A: If you had any users who were not in a group prior to this update, Hudu will automatically create a group called Previously Ungrouped Users and add all of those users to it. This group will have the same access they had previously as ungrouped users. You can leave them in that group, or you can work your way through that group member list and move them to other groups as needed. You can delete this at any time, as long as the users are in at least one other group.
Q: Did anything change with how password folders work?
A: No; password folder still work the same, but what you can do with them has changed, since you can now add users to multiple groups. For example, Joe is a member of Tech Group 1, Tech Group 2, and Tech Group 3. You create a password folder that only Tech Group 3 can see. Even though Joe is in other groups that haven’t been given access to this folder, he is also in the group that was, therefore Joe can see this password folder.
Q: When should I use allow list?
A: Allow list means the group will only have access to the companies you specifically list. It is the most restrictive method for controlling company access. You may want to use this list for your default group, or if you typically want to restrict users in your instance from accessing companies as much as possible. If you create a new company in Hudu, a group using allow list would automatically not have access to that company unless you add that company to the group’s allowed companies list in the group’s settings.
Q: When should I use deny list?
A: Deny list means the group will have access to any companies unless you have specifically denied the company. This is a less restrictive option than allow list. If you create a new company in Hudu, a group using deny list would automatically have access to that company unless you manually add that company to the group’s denied companies list in the group’s settings.
Q: When should I put users in multiple groups?
A: Multiple groups are most useful when you want to create combinations of different permissions for users within the same instance.
Example 1:
An MSP has 10 employees and the following needs:
-
- 2 of them should not be able to view company passwords.
- All 10 should not view Test Co
- 1 should not view AtlasCo
- Otherwise, they should be able to view everything.
One way to handle this would be to:
Create a group named NoTestCo Group in deny mode, so all users in it can access all companies unless otherwise specified. Deny that group access to TestCo and add all 10 users to it.
Create a group in deny mode named NoAtlasCo Group so all users in it can access all companies unless otherwise specified. Deny that group access to AtlasCo and add the 1 user to it.
Create a group named NoPasswordView Group in deny mode, so all users in it can access all companies unless otherwise specified. Do not specify any companies. On the Restrictions tab, remove access to company passwords. Add the 2 users to it.
Multiple groups are also helpful when it comes to password folders.
Example 2:
User A is a part of a Technicians group and a Super Technicians group.
User B is a part of a Technicians group.
There is a password folder named High Security Passwords.
There is a password folder named All Techs Passwords.
Super Technicians group is given access to view the High Security Passwords folder.
Technicians group and Super Technicians group are given access to view the All Techs Passwords folder.
Results:
User A (members of Technicians group and Super Technicians group) is ALLOWED to see High Security Passwords.
User B (member of Technicians group) is NOT allowed to see High Security Passwords.
User A is ALLOWED to see All Techs Passwords.
User B is ALLOWED to see All Techs Passwords.
Q: What happens if a user is in groups with conflicting permissions?
A: If a user is in multiple groups with conflicting allow/deny permissions, Hudu defaults to the deny permission.
For example, a user belongs to:
- Group A (Deny List): Denies access to companies X and Y
- Group B (Allow List): Allows access to companies Y and Z
- Group C (Deny List): Denies access to company W
Result:
- User cannot access companies W, X, and Y (denied by Groups A and C)
- User can access company Z (allowed by Group B)
- User cannot access any other companies (due to Allow List default for mixed group types)
Password folders work differently, since you cannot explicitly deny a group access to a password folder. (You can inherently deny a group access to a password folder by granting access to the folder to specific groups.) This means it is impossible to have conflicting allow/deny permissions for a password folder.
Q: I want to set permissions for KB folders and specific passwords and KB articles.
A: These changes, along with the ability to add users to multiple groups, are the first step in implementing our larger permissions system update. We plan to release a beta version of the ability to set group permissions for folders in the coming weeks. This timeline allows us to resolve any potential issues with groups before we roll out the next phase of the permissions system.
Q: Being able to add users to multiple groups isn’t solving my permissions use cases.
A: We know that while this update is an improvement, it does not solve every permissions need. Being able to add users to multiple groups is necessary for the larger permissions update. While we finish up development on that larger update, we wanted to at least provide access to this feature in the meantime. If this feature in its current form doesn’t meet your needs, you can leave your groups as they are and reassess if you’d like to make changes to your groups once we have released the full permissions system update.