On Thu, Jan 28, 2010 at 10:50:10AM -0500, LeVan,Ralph wrote: > > But we don't > > *use* e.g. telephone numbers, so why store them if we don't have to? > And we > > certainly should NOT copy data from the directory (when there is > > one) and keep local duplicates which eventually go stale and mislead > our users. > > We don't need two sets of stewards for the same data. > > I wish it was that simple. Sometimes people leave the institution and > drop out of whatever directory you were hoping to get data from. When > that happens, do you intend for the user to get none of that > information?
Good point, and yes, I do. If the person has left the institution, his contact information is no longer operative. It is better to say nothing than to give misinformation. What this tells me, actually, is that contact information for submissions should not be a property of the user at all; we need separate "user" and "submitter" objects. When a user also becomes a submitter, the submitter's preferred contact information can be preloaded from the user's personal data, and he can replace it at need. When an in-house user is separated, he can convert his DSpace account to a local-password account and he'll be able to continue updating his linked submitter record. We could do with a small "grooming" application to trawl the user list for directory-backed accounts that no longer exist in the directory (and other exceptions). At one time we actually had another use for this split: corporate submitters could be represented by more than one user. (No, we never implemented that. )-: And a user might be a submitter to several different aggregations under different roles, possibly making it convenient for him to have multiple linked submitter personae. It looks like it's time to review the OO analysis of roles and the objects associated with them. I wonder if there's a good role-management abstraction out there already that we could use? (Directory services can do this, but only for objects in the directory, and some sites need to manage both in- and out-of-directory objects.) -- Mark H. Wood, Lead System Programmer [email protected] Friends don't let friends publish revisable-form documents.
pgpe1vNBK2jyl.pgp
Description: PGP signature
------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com
_______________________________________________ Dspace-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-general
