: 4582 | 108668 | 12353

Ability to tell AdminP to not remove a name from a document for deletion requests 
Use this IdeaSpace to post ideas about Domino Server.

: 44
: 50
: 6
: Domino Server / Admin Tools
: adminp, name
: Michael Sobczak2969 20 Dec 2007
:
: / Email
In custom Notes applications, user names are typically stored in Reader, Author or Names fields.  If the database's ACL has the "Modify all Names fields" setting enabled, AdminP will update the user's name in all Reader, Author and Names fields in accordance with a name change.  However, when a user has been terminated, AdminP will remove the user's name completely from all Reader, Author and Names fields.  For some applications, this means that important workflow information will be deleted.
 
For example, user "Jane Smith" uses a Notes-based Expense Report database.  Her name is only stored in an Authors field.  When she leaves the company, an AdminP deletion request is submitted.  If the Expense Report database's ACL has the "Modify all Names fields" setting enabled, AdminP will remove Jane Smith's name from all of the Expense Reports she created.  This means that the Expense Reports Jane created will no longer have her name as the author, and Jane's Expense Reports will no longer appear under her name in any of the views.
 
Of course, Jane Smith's name could also have been stored in a Text field in addition to an Authors field.  AdminP does not update non-Names fields. However, if Jane Smith's name is changed to "Jane Doe", AdminP would update the Author field, but not the Text field. The document now has two versions of Jane's name.
 
Another example of how AdminP's behavior is problematic is an Issues database with an Issues form.  This form includes a single AssignedTo field of type Names.  When the author creates an Issue document, they select multiple names in the AssignTo field.  The names in the AssignTo field need to be retained for audit purposes.  Having AdminP change the names in the list is acceptable, but having AdminP remove names from the list effectively destroys required audit information.
 
In my experience, it is impractical to redesign existing Notes applications so that they can work the unilateral way that AdminP processes deletion requests.
 
In my opinion, the best way for custom Notes applications to take advantage of the AdminP name change functionality would be if the Action drop-down list in a database's ACL also included an option or check box to the effect of "Process name changes only" or "Ignore user deletions".   We would be able to tell AdminP how to process name changes and deletes on a database-by-database basis.  Best of all, we wouldn't have to rewrite existing applications.



1) Paul Mooney2039 (20 Dec 2007)
Sounds like a good idea to me Mike. It would be possible to delete the request from admin4.nsf to prevent this, but that requires input from the admin guy, and is a risk.
2) Paul Davies12381 (20 Dec 2007)
perhaps an adminp property on every reders/authors/names field

allow update
allow delete
etc
3) Kerr Rainey3860 (20 Dec 2007)
Interesting. I didn't know that. Sounds like something us developers should be more aware of.
4) Peter Moline1403 (20 Dec 2007)
Makes sense as described. As you have suggested, a good way to implement it would be in the ACL (advanced tab), with an additional option under 'Action'. Then you could implement it on an application by application basis.
5) Vitor Pereira1697 (20 Dec 2007)
I find that selecting 'Modify All Readers and Authors fields' in the ACL instead of 'Modify all names fields' works for me. Your workflow name type fields will remain unchanged if you set it up this way. Doesn't this work for you?
6) Peter Presnell26659 (21 Dec 2007)
It would seem to me we already have enough options with the ability to set Modify Readers & Authors versus Modify All Name Fields at an application level.
7) Michael Sobczak2969 (25 Dec 2007)
@5 Victor: if a person's name has changed, I want it changed in all Names field types. Not having AdminP change a Names-type field defeats the purpose of using this field. I can't understand how having two different version of a person's name in the same document is helpful to users at all.

@6 Peter: we don't. I've been using Notes for 12 years and not having the ability to propagate name changes throughout custom applications has been a major thorn in my side. Having more control over how AdminP does its thing seems like a small thing to ask. Sure, us developers can write custom agents that help database owners manually change names, but that is nonsensical and a waste of developer and database owner time.
8) Tom McArthur1022 (26 Dec 2007)
@7 Michael: "can write custom agents that help database owners manually change names". That's what adminP does. Why would you need to write a custom agent? The only thing that seems "nonsensical" here is writing unnecessary custom code.
9) Michael Sobczak2969 (31 Dec 2007)
@8 Tom: if you allow AdminP to update all Names fields in a document, it will remove names when a person has been terminated. The only way to avoid this is to write custom code that allows database owners to manually effect name changes. As it stands today, with AdminP, you get name changes *** AND *** name deletions. I believe that AdminP was originally written only to be used on the Domino Directory, and was extended to custom applications without much thought. I've come across many instances over the years where enabling the "Update all Names fields" option would have removed Notes names from documents where that information was very important to say the least. I can't see how anyone could ever enable this feature on a custom application without rendering the data in those documents unusable.

Here's just one example: if you enable this on the Discussion Forum, AdminP will remove the values from the From field when the document creator is terminated. This means that documents in the main view in this template that were intially displayed like this:

Some Main Topic (Joe Blow)

will be displayed like this when Joe Blow is terminated:

Some Main Topic ()

Based on these results, Enabling even the "Modify Readers and Authors fields" options has serious consequences.

If someone can tell me how I can configure Domino to not do this, I'm all ears.
10) Tom McArthur1022 (31 Dec 2007)
I agree that "Update all Names fields" would be dangerous to custom applications because you would lose the From name. But I still disagree that there is any danger in removing terminated user names from Reader and Author fields.

BTW, I'm not trying to be argumentative - I'm just debating the issue. ;-)

So, can you give an example of a negative consequence of removing a terminated user name from an Author field?
11) Josť Manuel Rodriguez Moreno985 (15 Jan 2008)
This is absolutely needed.
12) Eoin Meaney10 (09 Sep 2010)
Not being able to trust the Notes administrator round here (me) I wrote an agent to yank "Delete in Readers/Authors fields" requests from the Administration Requests Db and copy it over to an archive file (just for recording purposes):

Sub Initialize
Dim s As New NotesSession
Dim ndbThis As NotesDatabase
Dim ndc As NotesDocumentCollection
Dim nd As NotesDocument
Dim ndbArchive As NotesDatabase
Dim ndDeleteRequestInArchive As NotesDocument
Dim ndDocumentReference As NotesDocument
Dim ndcChildren As NotesDocumentCollection

Set ndbThis = s.CurrentDatabase
Set ndbArchive = New NotesDatabase(ndbThis.Server, "Archive\\Admin4.nsf")
Set ndc = ndbThis.Search({Form = "AdminRequest" & ProxyAction = "18" & ProcessedBy != "Move Delete in Reader/Author fields requests to archive"}, Nothing, 0)
Set nd = ndc.GetFirstDocument
Do Until nd Is Nothing
Set ndcChildren = nd.Responses
If ndcChildren.Count = 0 Then
'Looks like Adminp hasn't process the request so we can just copy it over to the Archive and delete it from this Db
Set ndDeleteRequestInArchive = nd.CopyToDatabase(ndbArchive)
Set ndDocumentReference = nd
Set nd = ndc.GetNextDocument(nd)
Call ndDocumentReference.Remove(True)
Else
'Looks like Adminp has processed the request : ( Just leave it where it is for reference
nd.ProcessedBy = "Move Delete in Reader/Author fields requests to archive"
Call nd.Save(True, True)
Set nd = ndc.GetNextDocument(nd)
End If

Loop

End Sub

The field ProxyAction hs the value "18" for this type of request

Agent name "Move "Delete in Reader/Author fields requests" to archive"

Run on event "After documents are created or modified"










:
:




Welcome to IdeaJam


You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>






IdeaJam developed by

Elguji Software Logo