beginners' question on versioning & user mgmt

[Wolf Benz <eu...@gmail.com>]

Hi List,
I have a few beginner's questions:

1/ versioning for audit trail.
I understand after you add the versionable mixin, nodes, upon a  
change, get a new version nr.
The questions I have with this, are:
1.1 We also need to capture (aka "GxP Std") who made the change, and  
why. (so Uid & a String)
What do I need to do to also capture this extra info with the new  
version nr? Do I just add the fields to the node (UID & Reason for  
change) or is it possible to somehow extend the version info itself  
with these extra fields?

1.2 Is the versioning schema controllable? I mean: what happens if  
subnode B of Supernode A is changed from v3 to version 4. Is the  
supernode version then  NOT changed, or does it get a change like A  
v2 -> A v2.1 (.x for supernodes) etc... I'm sure you can imagine lots  
of other schemas. So: Which one is followed by default & is this  
configurable?

2/ Even more basic I'm afraid: basically my UC is very simple: I want  
to boot a repo against a DB and then capture and log changes users  
make to data.
Do Ithen boot the Repo (cf logincreds @ repo init time) against a  
system user to subsequently start sessions (?) by defined users or...?
& How do I do this? (rough schema) For teh user part: what do you  
people advise to use? JAAS or Acegi? (using Spring anyway so not much  
extras to setup)

Thx for all help!

Philippe

Re: How to best organize Audit Trail?

[Wolf Benz <eu...@gmail.com>]

Special Thanks to David who took the time to validate this approach:

The proposition was :
- define a mix:auditable that extends from mix:versionable  (extends - 
 > we already have the subsequent version nrs)
The extra auditable fields would then be: Date When, String Why and  
String Who

This mix:auditable could then be assigned to any node, without having to
reinvent the wheel everyime gain. (which is why I so much wanted to  
give JCR a try for this)

--> David's comments were:
"
That sounds like a good approach. Generally, this means that the  
application would ensure that the "why" and "who" would be filled-in  
before a check-in, while the "when" should be covered by the  
versionCreated date. The good news is that if you rely on checkin and  
versioning in general it is guaranteed that the information cannot be  
changed after the fact since versions are immutable.
"

Voila.
Now I get to try to implement it :-)

Greetz,

Wolf


On 14 Jan 2007, at 23:42, Wolf Benz wrote:

Hi List,
Has anyone an idea on this topic:

Versioning for Audit Trail.
I understand from JackRabbit's docs that after you add the  
versionable "mixin", nodes, upon a change, get a new version nr.

The questions I have with this, are:
1/ How to best ALSO capture WHO made the change and WHY? (so  
basically add to Strings to a version @ each version increment)

Do I just add the fields to the "content" node (e.g. for a Book node  
being under version control: add a "UID" & "Reason" property, both  
also faturing the versionable mixin) or is it possible to somehow  
extend the Version Node itself with these extra 2 fields?
In the latter case, this would substantially reduce the efforts to  
also audit trail other nbodes + be less invasive. (original Nodes are  
left untouched)

2/ Is the versioning schema controllable? I mean: what happens if  
subnode B of Supernode A is changed from v3 to version 4.
Is the Supernode version then NOT changed, or does it get a change  
like A (v2) --> A (v2.1)  etc...?
I'm sure you can imagine lots of other schemas. So: Which one is  
followed by default & is this configurable?

3/ For the authorization part: any recommendtions on whether to use  
JAAS or Acegi? (using Spring anyway so not much extras to setup acegi  
if there are advantages over JAAS)

Thx for all help!

Wolf

How to best organize Audit Trail?

[Wolf Benz <eu...@gmail.com>]

Hi List,
Has anyone an idea on this topic:

Versioning for Audit Trail.
I understand from JackRabbit's docs that after you add the  
versionable "mixin", nodes, upon a change, get a new version nr.

The questions I have with this, are:
1/ How to best ALSO capture WHO made the change and WHY? (so  
basically add to Strings to a version @ each version increment)

Do I just add the fields to the "content" node (e.g. for a Book node  
being under version control: add a "UID" & "Reason" property, both  
also faturing the versionable mixin) or is it possible to somehow  
extend the Version Node itself with these extra 2 fields?
In the latter case, this would substantially reduce the efforts to  
also audit trail other nbodes + be less invasive. (original Nodes are  
left untouched)

2/ Is the versioning schema controllable? I mean: what happens if  
subnode B of Supernode A is changed from v3 to version 4.
Is the Supernode version then NOT changed, or does it get a change  
like A (v2) --> A (v2.1)  etc...?
I'm sure you can imagine lots of other schemas. So: Which one is  
followed by default & is this configurable?

3/ For the authorization part: any recommendtions on whether to use  
JAAS or Acegi? (using Spring anyway so not much extras to setup acegi  
if there are advantages over JAAS)

Thx for all help!

Wolf