Currently, in the person content type, the node title is labelled 'name', but there is also a fullname field.
In my mind, this adds confusion, and so we should only have a single name field.
The question though:
- How to deal with the circumstances in migrating where both are set, but they are different?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | storm--671622-7.patch | 6.75 KB | juliangb |
Comments
Comment #1
dbt102 commentedIn my circumstance, I've been setting them both to the same. And I use (http://drupal.org/project/advanced_profile) for advanced user profile pages. However, I think it would be great to deal with names in a more Drupal-like way, if there is such a thing...
When creating a Storm person you can also specify the 'User' which is the drupal 'Username', and it allows for creation of a stormperson who may or may not be a drupal user with a signon account. This is a good feature, because some of My storm persons have a third party enter their timetrackings, as they do not have site access.
I have been using the person's First Name (ex: Marco) and Last Name (ex: Polo) of the person for both the 'name' field (ex: MarcoPolo) and the 'fullname' field (ex: MarcoPolo), so for me they are the same, redundant and confusing...
The real name module (http://drupal.org/project/realname) seems to offer some insite since it distiguishes between a displayname (such as the storm node title labelled 'name') and a persons real name (fullname field) and what should be displayed.
http://drupal.org/node/122303 has a good discussion of Real Names vs Display Names with discussion on resolving some issues with D7 core.
I've a new project to integrate LDAP access to a site (and I'm thinking I can follow recipe such as http://drupal.org/node/480820) so user name fields are of particular interest to me at the moment...
At the moment however, for this issue I'm thinking that just renaming the node title labelled 'name' to something like 'Storm Display Name' would make things much clearer without having to fold in other module dependencies.
Hmm...maybe I overthought this one...
Comment #2
Magnity commentedI wonder also whether the 'prefix' and 'fullname' fields of organizations could be scrapped.
EDIT: separated out into #685140: Remove prefix and fullname fields.
Comment #3
JGonzalez commentedI see little use in the prefix and name fields.
While some users might like the ability to use prefixes, for most it just adds more field to leave blank.
The fullname field I've been using copying whatever the name is and don't see much use for it.
Ideally, if a drupal user is found using the User field, the name would either not be needed or would fill automatically according to the users profile)
Comment #4
Magnity commentedRight - I propose that we go ahead in two stages. First of all, all user facing parts of the field is removed. Second stage, in a couple of months, the database field goes. This way, if someone was using it, they don't just suddenly lose the data.
Not convinced about removing the prefix from people. Yes, perhaps not everyone will use it, but its not duplication so I think a better way is to think about options to hide fields.
Comment #5
tchurch commented+1
Comment #6
juliangb commentedI'd like to do this before releasing on the 2.x branch, so that the change comes in at a similar time to the one on Storm Organizations (already committed).
Comment #7
juliangb commentedPatch for testing.
Comment #8
juliangb commentedI think this is ready for committing, but will leave in the queue for a day or so to see if anyone else has views on it.
The patch removes all except the database field, which would be removed down the line in a separate issue.
Comment #9
juliangb commentedCommitted to git.
I've opened an issue for the database cleanup at #1161908: Clean up fullname data.