Audit Trial

Next topic

Author	Message
Brendan Pike	Friday 25 July 2003 10:17:47 pm A couple of times of I been asked if eZ publish supports Audit trials. Is this a feature that has been considered? www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Jan Borsodi	Saturday 26 July 2003 4:09:09 am Well, if you could explain what an Audit trial is. :) -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Brendan Pike	Saturday 26 July 2003 7:33:45 am Audit trial !! As in a clear record of all changes made over the site by any and all users. www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Jeroen van Gorkum	Thursday 31 July 2003 2:16:46 pm you meant 'trail', didn't you? like a changelog or `cvs log', but for sitecontent. i like the idea -- tho' i'm not sure what it should show (diffs? revision numbers? timestamps?, links to archived revisions? log messages?) -- because other views on the same data / result set could display the 10 pages that were last changed in section X, or root folders (home, products, services, ...) sorted by activity, or a sitemap with pagetitles marked that were added / changed since my last visit, etc. jeroen.
Bård Farstad	Thursday 31 July 2003 2:33:59 pm We should definetly add this. Suggestions for what excactly should be logged in this log? create edit remove purge login change password ... Something like: action user time ip siteaccess --bård Documentation: http://ez.no/doc
Jeroen van Gorkum	Friday 01 August 2003 6:53:01 am > create > edit > remove > purge yes, the standard new, edit, delete actions & similar. maybe the criterium for an entry to be logged should be that what it changes is noticeable for a human being. > login > change password i don't think these two should be regarded as an object change, as long as we're talking about articles, forum posts, etc. they are if we're looking at 'user objects'. jeroen.
Jan Borsodi	Saturday 02 August 2003 2:22:50 am Keeping track of logins can be useful. For instance you could configure it to only store logins to the administrator interface, that way you can get an overview of who has logged in and when. -- Amos Documentation: http://ez.no/ez_publish/documentation FAQ: http://ez.no/ez_publish/documentation/faq
Jeroen van Gorkum	Saturday 02 August 2003 7:30:37 am > Keeping track of logins can be useful. true, but i was just thinking about what a changelog page should display, and what should trigger an changelog entry, not how to accomplish this technically. say you were looking at the changelog for one article. it wouldn't make sense to have entries in there marking the moments that users logged in from this page, because that action didn't change the article itself. i'd also like an overview of who has logged in and when, but that's more 'site statistics', opposed to 'content changelogs'.
Brendan Pike	Sunday 03 August 2003 4:47:39 am How embarrassing, yes I did mean "trail" (wish I could say english was my second language) I was also thinking about a "display difference" view inside the versioning area even if it was just in raw XML it would be useful. But I think that should be kept separate from the Audit Trail in an effort to keep it clean and legible. No reason why links couldn't be provided I guess. www.dbinformatics.com.au We are always interested in hearing from experienced eZ PHP programmers and eZ template designers interested in contract work.
Stuart Fenton	Monday 04 August 2003 5:01:33 am I have been looking into this as well. Primarily to provide accurate support with a CRM (customer relationship management) to allow support of a user by knowing what has went on with their account. I want to be able to keep a log of every change in the system that effects the user: 1) Every change a user does with their own data. 2) Changes the admin does to their data. 3) Changes the admin or editors do so we can track down site problems. 4) Shop transactions: (account status information) Credit card payment taken. Credit card refused. Account closed (self). Account closed (admin). etc 5) Changes in membership type: Free user changed to pay-for user. Pay-for user changing to a free user. 6) Email communications. Shop emails. General emails. user replies to emails etc The idea is that I can simplify all my support issues because I have a log of all actions and communications/responses over the entire website. This also allows external companies or people to be hired to deal with support because a support person can deal with an issue easily as the entire trail of events is readable so they can start form zero knowledge and still deal with issues that arise. As this is a live issue for myself where would I hook this type of system into the kernel? Also I was thinking of writing a separate sql table to hold the events data. Since all changes will be recorded I wanted to avoid the overhead of using standard EZ objects although ez Objects would be used to parse and read the data. I assumed I would write a module to hold the support functionality. If you are thinking of doing this anyway would there be any timescales or should I go ahead and do this myself? Thanks Fats. -- Stuart stuart@grandmore.com http://www.grandmore.com