What Happens When Your Users Get Married?
I know this is one of those things I really probably ought to know, but, after 10 years as a Notes developer I've never given the matter of name changes much thought. This is most likely as, until now, it's never been something I've had to deal with. Now that the topic has cropped up I'm wondering how it's best dealt with.
A user of an application I've developed has got married and is requesting their name be changed in all the places it appears.
Like most applications the database in question stores the canonical @UserName in various places and uses it as the primary key that ties together all the documents which belong to that user. If the user's name is changed directly in the Domino Directory then, next time they log in, it will appear there's no content which belongs to them.
What to do?
Do I need to write some code to find all documents in which @UserName is stored and update them all one by one? I don't mind doing this but I can't believe this isn't something that crops up all the time.
Surely there's an easier way? Doesn't AdminP handle all of this somehow?
It leaves me wondering about an @UserID function which returns a never-changing unique number for each user in the NAB. You can change the user's name as much as you like. The user's ID will never change and, if that's what's stored in the document, this isn't a problem. That's how it would work in LAMP ;o)
Skip to the 
You can subscribe to an individual
If there is an Administration Server specified on the Advanced tab in the ACL of the database, everything will be handled by AdminP - but only if the name is stored in Readers/Authors fields (or ACL itself).
Changing the name in Text fields will have to be handled by an agent as AdminP leaves those alone.
Hi Sanel. Thanks for confirming what I thought might be the case.
For that to work does the name need to be changed in the Person document in a special way?
Also, does it apply to Names type fields or just Authors/Readers?
>> Also, does it apply to Names type fields or just Authors/Readers?
Also specified on the Advanced tab in the ACL.
Short answer... it depends.
Long answer. Using the admin client to change a persons name triggers a series of AdminP processes. The entire set of AdminP steps is outlined in the Administration Help database.
Amongst the requests is the updating of the person document with the new name. The person document does not need to be touched manually by anyone.
Another AdminP request is submitted to update Names in databases. This request is processed by all servers running the AdminP task.
Assuming your server is running AdminP, when it responds to this request, it will check all database for which it is the Administration server. Your database can have one of four settings in the ACL for the Admin server.
1. No Admin server ...... nothing happens.
2. Do Not Modify Names fields ... ACLs get changed to reflect the new name.
3. Modify All Readers and Authors fields ... all readers and authors fields will be modified to reflect the new name.
4. Modify All Names Fields ... Names fields that are not readers and authors fields will also be modified.
This seems all well and good, but there are some caveats.
AdminP will also remove names if the person is removed from the Domino Directory. In this case, using AdminP to modify Names fields can be a problem if you want to keep a record of the names for historical reasons. An example, we had a task tracking database which stored the names of the person raising the call and thhe name of the support person who handled the call as Names field. Someone changed the ACL and set the last option to Modify All Names fields. As people left the organisations tasks raised by these people or handled by these people had that information removed by AdminP. another example was an application similar to TeamRoom, which contained memos. Same situation with the Modify All Names fields. In this case, the memos started losing information such as who the memo was sent by, CCed too etc.
Another caveat is when there is a legal requirement for the name to be shown as it was when the document was created ... in this case you shouldn't allow AdminP to change it.
In my opinion, the use of Names fields and Authors and Readers fields in any application needs careful consideration up front to consider the ramifications of future name changes and whether these can/should be handled automatically. Its one of those areas that, like you, most developers don't think about, but probably should.
@ Jake
Yes, AdminP could rename "Names type fields" if you select the good option in the ACL (Administration Server tab)
But my experience in "Lotus renaming with AdminP" is that the process is very very long when you have lots of databases and lots of changes
For the text fields, you should use a specific agent or an other process/soft like Cooperteam changeString now available in the "Migration Pack" ... sorry for the link, it's only in french ;=)
That's what we do in our society
Thanks guys. That about answers all the questions I had in my head about this. In my case it looks like a custom agent is going to be the best way forward.
If have access to teamstudio's toolset Configurator will do it for you using replace all - that is how I have done it in the past
Hi Jake
Whilst I have not been involved with Notes for a couple of years, I seem to recall that when you change a users name you would specify a period of time when both the old name and the new name will apply. I also updated the user document and their mail acl to have their previous name as alias. Seemd to solve this problem for me.
Regards
Alan
Chris Hudson's caveat bit me a few years ago. It was an employee performance review application, and when people left, their names were erased from their (and their subordinates') documents!
My solution had two parts... one part was to only refresh reader and author names. The other part was to duplicate some authors field values in text fields, and use that for display and a backup in case the authors fields were clear. I didn't like either part of that solution much, but it worked.
If you find a better one, please post.
You didn't mention the option that we employ here.
We say "NO".
That sounds harsh, but you would be amazed at the number of women who are glad to have an excuse to keep their maiden name.
On the other hand, we do have one or two women who have gotten divorced and would like their name changed back to their maiden name. They tend to be a bit annoyed, but since we don't change ANYBODIES name, they get over it.
@Timothy
That seems a little on the harsh side. Name changes are a fact of life, in any moderately sized organisation they are going to happen regularly. Shouldn't we build our systems and applications to deal with these occurrences?
@Timothy
I agree with Kieren. That does sound harsh? In fact I think I'd be very annoyed if that was the answer I got (not that it would happen to me, but you see what I mean).
AdminP does it all and does it well - see this technote to make sure your system is set up correctly.
Title: Frequently Asked Questions - The Administration Process (AdminP)
{Link} Read the articles linked inside the TN for more details. We have lots of info out there for this.
By the way, do NOT select the All Names Fields options mentioned above for your directory or your mail files - those are handled correctly with the default setting. Caveats are fine on the deletes, but renames work.
Just saying "no" isn't a realistic option for a business of any reasonable size. First of all, you could end up being hit with a discrimination lawsuit. Second, it gets rather confusing as time goes by - once people forget that "Jane Doe" used to be known as "Jane Smith", and you see Smith's name all over documents, people will be baffled about who this Smith person is. The AdminP rename process works pretty well, as long as you select options intelligently as discussed above.
Concerning our "NO" policy, I should mention the following:
I work for a organization made up of less fifty people.
The name change would have to take place in multiple systems.
The policy was in place long before I got here.
We don't have a dedicated Notes admin. This results in us being really big on "if it ain't broke, don't fix it."
It would be nice if the UNID of the person document could be stored in name fields and the ACL and the lookup to the person's name done dynamically both for visual representation and for authorization. There are performance implications for that though some purists would object to making Domino remotely relational.
Hi Jake,
Be glad you aren't being asked to change the domain as well! Teamwork Solutions recently completed a project that involved thousands of users changing their org names and hence domains as well. Not exactly the same but there was a compound approach that seemed to work pretty well.
- String replacement - As mentioned above, Team Studio Configurator works well if using manually against a single app or only a few. Otherwise, you probably want to get into some custom code to hit all applications in the organization. Don't forget design elements that may have been restricted to the users name (bad practice but not impossible and hence a possible problem).
- Adminp - as mentioned above, pretty much the easiest way (with due comprehension) to handle security related changes.
- Audit trail - something nobody has mentioned much yet. Keeping a record of all the changes made will be very useful for verification as well as backing out the change if something goes wrong. It also may be a legal requirements depending on the business your customer is in.
- Encrpytion - only because we change domains (I don't think a name change requires this) the public / private keys also changed, meaning any thing with encryption had to be decrypted and re encrypted - especially file attachments.
[shamelessplug]Todd Stratman at our office can provide more details on the approach used.[/shamelessplug]
My systems are web facing only ... no Notes Client applications. So when a user registers for an account I use their email address as their ID, after removing the "at" sign. (A valid email address is guaranteed to be unique in the whole worlds.)
I have a separate field for their email address. This way the user can change any of their data except their initial ID ... first name, last name, email address ... and nothing on my system needs to be updated. I never let them change their ID once it's created, so this is kind of like Timothy's just say no policy, but easier for the user to swallow.
The downside is that anywhere I want to display the use name is a call to @dblookup in a computed-for-display field or computed text. I do have some computed fields that have the names in them so those would have to be refreshed.
Yes well, the concept of a SID as per Active Directory is very clever indeed. Notes is archaic by comparison.
A good friend from mine (also a Notes Admin) had the idea from a company policy for this.
So Marie Mueller can only marry Peter Mueller. And Paul Woodstock can marry only Sabine Woodstock.
That wouldn´t cause some problems :-)
In our Domino directory there is a userid (eg M023454) as well as their canonicalised named stored in the Fullname field. This is a fairly common occurrence in companies that use single sign-on or mainframe access.
I just went through this in detail.
We merged two domains... and renamed all the users from one domain to the other.
In my experience....using the adminp works the best.
When using the adminp, there is a caveat. You have to run the "adminp process all" command a couple of times in a row (probably like 5) in order for changes to get done. It will do part of a change, and then post the next change... running it again will run that change just posted and so/on. And even then, some things will NOT be changed until the next day or even week.
However, because you can specify a "failover" type date when doing a rename, the user will still retain access to db's etc as required until the process is complete. Watch the admin4.nsf db for the adminp tasks ready to go... keep running the "process all" until you see all the tasks completed.
I used the option 3. Modify All Readers and Authors fields on all the apps (from Chris's post). We set it globally from the admin client.
This is usually where the issue shows up. Not the display names, but rather the readers/authors fields - which could restrict access to docs when the person's name changes.
I then wrote agents to update the other fields but only on certain apps as required. I made it very clear that this was a big deal and that the users had to have a huge requirement for me to do it.
We had great success with this and it took at max 1 week to complete ALL renaming - with most functionality renamed within the first hour.
Team Studio - Configurator is definitely the easiest way. It will find all occurences of the name in any type of field, and will take no effort (then time for a cup of tea whilst it runs).
Hi Jake,
It should work on all names, readers and authors fields, provided the name is stored in canonical format. The "Renaming" ahould be done through the users tab in the administrator client. This should create the appropriate adminp task, once the administration server is set up on the acl of the database(s) in question.
Regards,
Niall.
Jake,
In my old job, we went through a lot of the same issues, plus our Domino directory synched nightly with our corporate directory, so name changes weren't user-initiated (nor did we have the option or time to run name changes from the directory manually).
We had agents that initiated the adminp requests for name changes; we relied on the administration process to take care of name changes in names/authors/readers fields and basically told developers that they needed to fix anything else that no longer worked (i.e., if they were storing the name as text). One other thing we did is that we aliased the person document by appending the old canonical name to the shortname field in the person document at the same time we changed the fullname field.
We rarely had any problems with this approach.
just want to reiterate about storing the full name (inc certifiers and all the ou's)
i have seen an app with a bunch of readers field storing only the common name, after after a domain name change guess what happend?
the readers name doesnt get recognised and no documents available to users