Manifest - Best Practices
A list of best practices we recommend manifest users to follow
Privileges
-
Use groups for privileges, instead of adding users individually
It is advisable to put users in groups, and assign privileges to those groups whenever possible. Often times, new users are given privileges individually. This makes managing privileges difficult in the future. In contrast, adding or (especially) removing people to a group then giving them rights to a bunch of things is far easier than adding the person to each of those things individually. In addition, this also saves the admin the trouble of having to remember what to add or to remove every time they have to add or remove someone.
- Designate a backup administrator for your group right away to prevent abandoned or orphaned groups upon your transfer from the department or school, or departure from the University.
Abandoned groups, defined as groups without any administrators, or orphaned groups, defined as a group all of whose administrator(s) has/have left the University, may be deleted in order to maintain efficiency of the service.
Folders
-
Create subfolders instead of requesting more folders from top level
While main folders Manifest can only be created by Manifest Service administrators, subfolders can be created by anyone with admin access to the folder it resides in. This means that subfolders can be created anytime without having to go through the approval process from the admins at Manifest Services. In addition, this helps ensure that folders are created in the right path and domain, making further management easier while also keeping organizational relationships clear.
See Manifest - Working With Folders for more details.
-
Only request for top level folder when necessary
It is desirable to reduce confusion and understand organizational relationships that we try to reduce the number of top level stems to make browsing more understandable. For example, conceptually separate items make sense to separate ( uw:domain:chtc.cs.wisc.edu doesn't have to be part of cs.wisc.edu), but we don't want to proliferate stems that are logically part of another (we wouldn't want to create uw:org:comp_sci_firewall_acls, but perhaps uw:org:cs_building_network_admin does make sense, as DoIT and Computer Sciences staff both have roles.)
Groups
-
Group ID - Use lowercase and underscore, and avoid having spaces
Having spaces in Group ID may cause problems because it will result in pathing issue. We recommend using underscores to replace spaces and use lowercase only to adhere to proper computing practices
E.g. Instead of Bucky Badger, use bucky_badger
Note: Do no confuse group name with Group ID. Group name is the name that will be displayed for the group. Hence, it can be anything and have spaces and other characters. See Manifest - Create a Group for more details.
-
Make reusable groups. Or use past groups
Create a group with reusability in mind. In other words, refrain from having to constantly create new groups for short term use. Similarly, users should look into past/old groups that they may reuse or repurpose before creating new groups. This is to prevent the Manifest folder from getting too cluttered with too many groups
It also helps to manage access for users when they don't have to be in too many groups. If users are grouped in 'roles' and given access accordingly, it will be easier to manage adding and removing access for anyone later on, without having to worry about missing anything. In fact, these 'roles' should be combined with other 'access policy' groups that actually are used for end applications. For more information about the Access Control Model in Grouper, please refer to Access Control Models
-
Use data to formulate groups when possible
For example, instead of creating a group for a department and adding everyone by hand, use UDDS groups and then add any exceptions by hand.
Data driven groups for HR and students are available. For reference on data-driven group, see Manifest - Data Driven Groups