Hide ‘edit’ option from My Library Card > Personal Details for specific user groups only
In Alma you can choose to hide the "Edit" option from the 'Personal Details' under 'My Library Card' for ALL your users by changing the parameter key 'primopatroninfo_updatable' to N
This works fine if all your users are set up as external users who automatically gets their contact information updated from a system outside Alma. But if you set up your students as external users and public users as internal users you will have to choose between letting the students update contact information that will be wiped out next time data is loaded in to Alma or not enabling public users to update their contact details anywhere.
I therefore suggest that it should be possible to choose which user groups you want to hide the 'edit' option from.
Caroline Myrberg
shared this idea
-
Jessica G
commented
Many institutions in our consortium of 89 libraries have external users whose data are held in a campus system and loaded into Alma, and also have local community users whose data are managed internally in Alma. It would be helpful to have a way to allow the local users to edit their data in Primo VE's My Library Card themselves with the Edit button, but to prevent the students/staff/faculty from editing their data, so distinguishing whether or not the Edit button displays by the user group seems like a good suggestion. Our libraries need for the campus system to be the authoritative source of contact information for students/staff/faculty; if these users are allowed to Edit information in My Library Card, that change is only in Alma and has no way to get back to the campus system, so it is best if these users are prevented from editing and made to change such information in the campus system directly, which will then feed into Alma with the next load.
-
If you allow updating information form Primo then the submitted data should not be wiped out by the next data load. The data from Primo will be created as an internal segment, attached to the external user account. This internal segment will not get wiped by the next load.
-
Caroline Myrberg
commented
We do not want the students to change their information in Primo at all. We want the external system to be the master and we want the students to update their information there, because then the contact details will be correct and the same in all systems at our university. If the information the students add themselves in Primo VE is not overwritten when they change their information in the master system, that is equally problematic, since they are encouraged to update their information in the master system to get their information updated everywhere.
-
Hi,
I am not sure about 'letting the students update contact information that will be wiped out next time data is loaded in to Alma'. Updates done by patrons from Primo should be recorded as internal segments (e.g. email) and not get overrun by a subsequent SIS import. Is that not your experience ?
-
Manu Schwendener commented
+1
