[Building Sakai] Question regarding names

[David Horwitz]

Just some thoughts on this. Yes its nicer to allow users to change their
names to something their known as. We collected some data outlining the
use cases when we migrated to Sakai:
http://sakaiwiki.cet.uct.ac.za/index.php5/Identity_management#Reasons_why_people_change_their_names

I recall on our legacy system 10% of students chose to edit their names.
However in the Sakai world we have had to remove the ability of students
to edit their names because of several cases of abuse. This has been
mitigated by the SIS now supporting "preferred names" for students. 
Currently we allow staff and guests to edit their names and all users to
edit their email address.

Regards

David

On 04/12/2010 03:12 PM, Bristow, Paul wrote:
> John,
>
> I think in terms of storage this makes some sense. I presume any deployment can have from 1..n names - that n will not be defined for a deployment but for a user. We have 'complexities' with some systems assuming n > 1 which does not hold true for all our users. For your sorting option I guess we need to make sure the sorted field is the first field to be populated?
>
> Equally there appears to occasionally be confusion over the correct ordering of names in different cultures. 
>
> I'm not sure in what contexts you see the information being collected (or used) and might have an issue with your display names.
>
> We have a  number of users who prefer not to use their official 'first' names. Some use a second (or other) name, some a contraction or derivation of their first name, there may be others. They can become quite heated about systems that insist on calling them a name to which they do not answer.
>
> We have included a 'preferred name' where possible in our enterprise identity. I don't know if this is the same as your display name (we've had users use 'pet names' as portal display names with no link to preferred names) or if preferred name is a candidate default display name.
>
> As far as not allowing users to overwrite...
>
> Personally if it is necessary to stop users using distasteful, offensive, or otherwise inappropriate names I'd prefer to try policy before applying a technological lockdown.
>
> If the issue is use of unmeaningful names to act anonymously where interactions are only identified by display name - this is a tougher issue. Do you see any way other users can link a display name back to some other identifier? Would this be something variable according to privacy options? Are there situations where anonymity is preferred - do we have alternate display names in these contexts? If so are they temporary or can they persist over a longer period?
>
> Will a display name always be unique in a group or could there be duplicates? If so they won't be enough to unambiguously identify who did something anyway.
>
> To get back to how the information is collected - I think if the name is user supplied at registration the user should always be able to override a default. We could hint a display name the same way we hint at site urls. If the user is self registered they're (assuming no delegated, federated, or otherwise automated proofing) effectively anonymous anyway so they are free to call themselves what they want.
>
> If the user information is provisioned any rules for (default) display names should be applied in the integration according to an organisation's policies. Perhaps they could then be locked or any overwritten alias in a context could be resolvable back to an identity for that context.
>
>
> Paul Bristow
> Applications Architect
> Division of Information Technology
> Charles Sturt University
>
> ----------------------------------------------------
> -----Original Message-----
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of John Norman
> Sent: Thursday, 8 April 2010 6:23 PM
> To: i18n at collab.sakaiproject.org
> Cc: sakai-dev Developers
> Subject: [Building Sakai] Question regarding names
>
> In Sakai 3 personal profile work the question of how to handle international names came up. I will summarise what I think I heard, but I have a worry that we may be trying to solve a problem that has been solved before so I am writing to tap your collective wisdom.
>
> I *think* we concluded that the following would be sufficiently flexible and useful:
> 1. 'name' is required in Sakai
> 2. 'name' will be composed of an indefinite number of fields: name01, name02, ..., nameN - field labelling is a deployment option e.g. name 01 could be surname or family name or lastname according to local practice or it could be labelled as firstname, given name, etc.
> 3. one field will serve as displayname
> 4. displayname will be created by rules from the name fields, e.g. displayname = name02+name01 the default composition rule will also be a deployment configuration option
> 5. displayname can be overwritten (if allowed in the local deployment) by the user
> 6. for list sorting, the name fields can be given a 'sort importance' so if the local convention is to sort by familyname and familyname is the label for name02, then name02 will be given sort importance=1 and when the UI displays a sortable list, name02 will be a default field because of its sort importance. Where displayname is free-form, it will not normally be a primary sort field.
> 7. there will also be a link associated with a name field for help, e.g. if firstname and lastname are supplied by LDAP as read-only while displayname can be edited in Sakai, the first 2 fields will link to instructions for updating LDAP data and the displayname will link to Sakai help.
>
> Does this make sense. Does anyone know where to look for a better idea?
>
> TIA
> John
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>