Extend the 'User detail' info of a database 
Use this IdeaSpace to post ideas about Domino Server.

: 8
: 8
: 0
: Domino Server / Admin Tools
: user detail, access, delegate
: Mathieu Pape8090 28 Aug 2012
: / Email
Currently it only shows who has read, written or deleted documents but you cannot make out which documents were involved. We have many cases where documents "magically" disappear and where it would be nice (or even sometimes we are being asked) to be able to show who did actually delete it. 
This specially makes sense for multi-accessed databases but also for Traveler-accessed database to make if the origin of the deletion is a mobile device. Mobile device can account for this as they might have multiple mail accounts, calendars, ... .
The info retained could simply be the Document UNID. Restoring a database would show which is (are) the UNID's involved and user detail info would then lead to the culprit. 
Sounds maybe a bit excessive but we receive quite a lot of such requests.

1) Vlad Sh10679 (03 Sep 2012)
Put handler QueryDocumentDelete and not remove documents from the database, and for example, change Form on "DeleteDocument", that is "move" documents to own recycle bin. And access to recycle bin, restrict administrators.
2) Mathieu Pape8090 (03 Sep 2012)
Hi Vlad,

thank you for your response. This means you need in-house designer skills which is not the case in smaller environments. And also means that you need to manage those undeleted documents. How long do you keep them? With all the risks that they may get archived by external tools, etc. ...
3) Vlad Sh10679 (03 Sep 2012)
If implement what you ask for, it will be impossible to recover the document.
I propose a solution that will permanently delete the document (later), and recover it.

> How long do you keep them?
This is more of an organizational issue.
I would prefer to focus not on the storage time, but to limit of removal of documents that may be important (eg registered, which were assigned a status, etc.).
So removed will only unimportant documents (mostly drafts), and the others are not relevant at the moment, but necessary for the history to move to the archive.
All these and other constraints (eg delete documents give only the author of the document or administrators) can be programmed in the event database QueryDocumentDelete. This is the only right and complete solution.
4) Alexey Katyushyn3674 (19 Oct 2012)
I vote for the need of logging of documents removal:
1. In User Activity in the properties of the database
2. In Session Activity in log.nsf

It would be nice to have the option, indicating that UNID of documents shold be logged. Not only for the removal, but also to read/modify.
Also would be nice to have the option, indicating what events shold be logged, i.e. DbOpen/Db Close, ViewOpen/ViewClose, etc.

It would be possible to introduce a logging section for server or configuration document. Which combines elements of existing logging and add new ones. Concept should be thought out. For example comes from Extracomm SecurTrac.


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