Adam Tauno Williams | 16 Jan 2009 22:59
Gravatar

Tombstoning in logs

OGo does not records the deletion of an object in the logs (table: log).
When an object is deleted it removes all the logs for the object, which
is sensible, but leaves no marker indicating the deletion.  This is
problematic for figuring out where a contact went as well as for any
kind of auditing.  In the past we've used a solution that simply created
a delete trigger on the DB,  this has surfaced on the list now an then.
But that method cannot capture the "who" part of the delete operation
(as in who did the delete).  Would it be acceptable to create a
tombstone entry for an object in the logs?  After deleting the objects
logs.

Like:

<patch>
  /* delete links */
  [[_context linkManager] deleteLinksTo:(id)[[self object] globalID]
type:nil];
  [[_context linkManager] deleteLinksFrom:(id)[[self object] globalID]
type:nil];

  LSRunCommandV(_context,  <at> "object",  <at> "remove-logs",
                           <at> "object", [self object], nil);

+  LSRunCommandV(_context,  <at> "object",  <at> "add-log",
+                 <at> "logText"    ,  <at> "Company deleted",
+                 <at> "action"     ,  <at> "delete",
+                 <at> "objectToLog", [self object],
+                nil);

  [super _executeInContext:_context];
(Continue reading)

Helge Hess | 16 Jan 2009 23:43
Favicon

Re: Tombstoning in logs

On 16.01.2009, at 22:59, Adam Tauno Williams wrote:
> Would it be acceptable to create a
> tombstone entry for an object in the logs?

Yes, I think it would be nice to keep the log entries and possibly add  
a 'delete' log entry to the log table (possibly with some extra info).  
Or maybe just the delete, don't know, depends on the motivation.

I guess this should be a configuration option, so that people can  
disable it.

Greets,
   Helge
-- 
Helge Hess
http://helgehess.eu/
--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer

Adam Tauno Williams | 17 Jan 2009 06:29
Gravatar

Re: Tombstoning in logs

On Fri, 2009-01-16 at 23:43 +0100, Helge Hess wrote:
> On 16.01.2009, at 22:59, Adam Tauno Williams wrote:
> > Would it be acceptable to create a
> > tombstone entry for an object in the logs?
> Yes, I think it would be nice to keep the log entries and possibly add  
> a 'delete' log entry to the log table (possibly with some extra info).  
> Or maybe just the delete, don't know, depends on the motivation.
> I guess this should be a configuration option, so that people can  
> disable it.

I implemented it for Company objects in r2166.  If no defaults are set
then the behavior remains unchanged: logs are deleted, no tombstone.
And added two new defaults:

TombstoneOnDeleteEnabled - if set to YES then a tombstone (action =
99_deleted) is created recording the deletion event and who deleted the
object.

LSDisableLogDeletion - Suppresses log deletion.  The object is deleted
but the logs remain.

--

-- 
OpenGroupware.org Developer
developer@...
http://mail.opengroupware.org/mailman/listinfo/developer

Sebastian Reitenbach | 28 Jan 2009 11:54
Picon

subclass WOHTTPURLHandle(class) should override cachedHandleForURL:

Hi,

I added the patch to bug 
http://bugzilla.opengroupware.org/bugzilla/show_bug.cgi?id=2005
to my ogo installation, that I link against gnustep-base.

When ogo tries to retrieve the xml file containing the contact information, 
e.g. coordinates, name, telephone numbers etc, then I get the following 
exception:
Application Server caught exception:

  session: 06100610014980354C
  element: 008498035a57fa7a408.5
  context: <0x0x7fa7a408[WOContext]: 008498035a57fa7a408 app=ogo-webui-1.1 
sn=06100610014980354C eid=008498035a57fa7a408.5 
rqeid=007498035977fa39808.0.17.1.3.b.1.9.1.1.5.0.1.1.2.button.5.1.1.map>
  request: <WORequest[0x0x7d82fb88]: method=GET

uri=/OpenGroupware.woa/wo/06100610014980354C/007498035977fa39808.0.17.1.3.b.1.9.1.1.5.0.1.1.2.button.5.1.1.map 
app=OpenGroupware rqKey=wo 
rqPath=06100610014980354C/007498035977fa39808.0.17.1.3.b.1.9.1.1.5.0.1.1.2.button.5.1.1.map>

  class:   NSException
  name:    NSGenericException
  reason:  subclass WOHTTPURLHandle(class) should override cachedHandleForURL:
  info:

It seems gnustep-base expects the subclass of NSURLHandle to implement the 
method, on libFoundation, this seems to be different, so I don't know which 
one is right.
(Continue reading)


Gmane