[Zope3-dev] DC Contributors

Michael Watkins mw at mikewatkins.net
Tue Dec 2 21:27:06 EST 2003


> Garrett Smith writes:
>  > I'd like to start capturing the principal who last modified an object. 
>  > My thinking is to use the pattern in
>  > 
>  >     zope/app/dublincore/creatorannotator.py
>  > 
>  > and apply it to the DC 'contributors' element. I.e. when an object is 
>  > modified (signalled by a published ObjectModifiedEvent) the principal 
>  > returned by getSecurityManager().getPrincipal() would be added to the 
>  > object's dublin core annotations as a contributor.

I'm not a Zopista but am following the discussions on Zope3 as I hail
from the document and content management industry. My two cents on this?

A principal that modifies a chunk of content is not the same thing as a
contributor. Someone that merely performs the act of modification is not
performing the  same function as the person who performs the act(s) of
creating the content (in the intellectual sense). The real contributor
may develop the content on a napkin; the person that turns that into
content accessible by the system is called... you give the role a name. 

Should you keep a history of this? Yes, absolutely, or yes, absolutely
make it an option.

We used to win deals against other document management package vendors
because their solutions did not capture sufficient audit detail (some
captured zero audit detail).

Where an audit trail is important, frequently a record of "edits" is
insufficient; you may be required to maintain a record of "views",
"approvals", "deletions" (can be tricky!), when a document became
available or unavailable, etc.

In some sectors (government is a good example of one) this type of
information is frequently critical. If you are building a solution for
an org that will manage content which is in any way considered part of
their official "record" (increasingly, all systems are viewed as such),
then the audit trail is a mandatory requirement.

Some organizations are going to want to know who made every change to a
particular piece of content. In the extreme, they may want to be able to
review every change, ever made.

They may never or rarely use audit trail features, but having the audit
trail makes it possible for them to assign a higher sense of reliability
and authenticity to content.

If you want to get really crazy about audit trails, you can check out
the DoD 5015.2-STD, "Design Criteria Standard for Electronic Records
Management Applications" for fun (I do not recommend it!)

There are many solution areas where Zope could be used that would
require the level of audit trail I've described:

- HR applications
- policy/procedure manual distribution
- any workflow application, 
- document change management apps are a classic use case

Just a quick two cents... I'll go back to lurking!


--
Mike Watkins
mw at mikewatkins.net


Meader's Law:
	Whatever happens to you, it will previously have happened to
everyone you know, only more so.




More information about the Zope3-dev mailing list