Closed erussey closed 1 year ago
We are creating a table for these from the Workflow Implementation Team, but question for @AGCooper and @lisahamlett ...should we wait to set these permissions until we do our final data load (which will overwrite the data in test)? Or do it now and change the ticket to set permissions in both prod and test?
@erussey Ideally, I'd prefer to set the permissions in prod and have the Lyrasis guys copy them to test when they do the sync, if possible -- that way we only have to do it once. Otherwise, whatever process sets us up to where we only have to do prod and test once each would be preferrable. Beyond that, I have no preference on the process.
Just as an update on this, the archivists have the permission structure set and are gathering usernames to be associated with each permission. They will have this to me by Wednesday and I will ping the Core Systems team when I have added it to the ticket. As decided in our sprint planning, we'll add the permissions to prod only so we don't overwrite them when we do our final data migration.
@lisahamlett : this ticket is ready to go. Let me know if you have questions!
@erussey @tmill29 Checking on our process. This ticket is in the backlog with no sprint or estimate. This ticket will be part of sprint planning next Wednesday April 12th for the work to occur between April 12 and April 26. Is that correct?
@erussey @libdgg this ticket has an estimated score of 13pts. This done not have to be completed in sprint but the requirement is that it needs be completed prior to the final data load. If capacity is allowed by core systems it can be completed in this sprint.
Thanks @tmill29 Do we know yet when the final data load will be? Or is there a ticket on the board that represents that task? (copying @erussey on this)
@libdgg : We do not know the exact date as it is dependent upon Lyrasis, who will be doing the work. Regardless, it will happen post-graduation so as not to put in a change during finals. I have created a ticket for the final data load to track that dependency (ticket #123)
@erussey Most of these users do not user their netids to log in to in ArchivesSpace -- they use their email alias. We will need you to provide the names for each of the netids, as I don't know all these people and Ann and Avery will know even fewer.
@erussey Additionally, we cannot provide access for people who have never attempted to log in, so any of these folks who have never logged in will need to do so before they can be given permissions.
@erussey Under "users to assign", only Basic Data Entry Staff have specific repositories listed. Does that mean everyone under a specific role gets it for all repositories?
@lisahamlett : Yes, everyone under a specific role gets it for all repositories except those listed under Basic Data Entry Staff. We are working on the list of names associated with the netids for you and will have that this afternoon and added to the spreadsheet linked above. For people who have not yet logged into prod, please flag those on the spreadsheet I'll get them to log in.
I have updated the groups for each of the repositories and am waiting to hear from Elizabeth that we have the names of each person who needs permissions. Then Ann, Avery, and I will start working on that.
Also, I sent the full list of users with current access to @erussey because the list of users who need access is significantly longer than those who have accounts. Anyone not in ArchivesSpace will have to log in for Shibboleth to pull over their IDs for us to assign permissions.
EDIT: Elizabeth is going to reach out to those not on the list and get them to log in before we start doing permissions.
Dropping into blocked because I can't do any more until (1) I get the full list of names of users from @erussey and (2) the users who don't have accounts have been notified to log in so we can set up their accounts.
@lisahamlett : I am working on getting everyone on the list to sign in. I've added usernames to the spreadsheet. Do you know if we can delete users from ASpace that don't need permissions anymore? Does it affect editing history from showing with records they created/changed?
We can and I have for the ones I know are gone.
I am setting up the LTDS staff and @libah and @avejohnson will do the individual permissions for each of the repositories.
Have not logged in yet: inihini, bradak, tlucero, byilma3, jcoulis, oalldri, mjenk27, amcshan
Almost finished with WHSCL, Oxford and Rose, should be finished tomorrow or when the rest of the users log in.
Also almost finished with Pitts, Law, and EUA.
We will check on the folks who have not logged in before sprint closing tomorrow. At sprint closing, the ticket can be closed out and user management for any stragglers will roll over to the user managers at each library.
Please note who has not logged into the system @libah.
These users have not logged in as of 5:00 pm ET, on 4/12/23: inihini, bradak, tlucero, byilma3, oalldri, mjenk27, amcshan
Per our discussion, closing this ticket with the expectation that archivists will assign permissions to the above.
Per the guidelines in #51
The revised matrix for permissions is available in Sharepoint. It includes the permissions for each group as well as the usernames to be assigned to that group. These permissions should be set in PROD: https://archives.libraries.emory.edu/staff . If we can complete this ticket prior to May 8, changes can automatically be copied over to our test environment.
The following tasks need to be completed:
[ ] Set group permissions for the 4 groups Emory will use: Repository Managers, Archivists, Basic Data Entry Staff, Viewers
[ ] Remove other local permission groups or mark as inactive.
[ ] Add system administrator permissions for Core Systems staff and Elizabeth (erussey@emory.edu)
[ ] Assign users in the permissions spreadsheet to the appropriate groups. Note that for all permissions except Basic Data Entry Staff, the users listed should be assigned to that permission in all repositories. For Basic Data Entry Staff, user permissions should be set on the repository listed only.
[ ] Unassign permissions for any user not listed in the spreadsheet
Since this is prod, all these users should have an account. Please put a comment on this ticket if there are users that cannot be added until they log in.