Open GoogleCodeExporter opened 8 years ago
GoogleCodeExporter
commented
8 years ago Can you elaborate on what you try to achieve, and what exactly fails?
As far as I am aware you can provide a comma-separated list of Audit
applications that will be harvested. I manage for example to add the CMIS
change-queue...
Original comment by tjarda.p...@incentro.com on 13 Nov 2013 at 4:07
GoogleCodeExporter
commented
8 years ago Ok, ok.
I wasn't aware what "Auditing Queries" meant. I have added "alfresco-access" to
the lessFrequent harvesting and now I have a table with all the auditing data
from the application.
So only the report suggestions make sense for my comment.
Having a way to report all the audit trail for a document would be great,
something like the show_audit.ftl template for Alfresco Explorer
(https://wiki.alfresco.com/wiki/Content_Auditing#Using_Alfresco_Explorer_to_view
_the_audit_trail).
It would even better if this could be filtered by path so that not only the
trail of a document would be reported but all the trail of all the contents
under a folder. This would allow to make reports like "What happened in
Contracts folder during last month".
The other very interesting report would be being able to report what a user has
been doing during a period of time. What documents he has accesed, what he has
deleted etc.
Original comment by igor...@gmail.com on 13 Nov 2013 at 5:14
GoogleCodeExporter
commented
8 years ago I can see the value for what you describe. However, I like to ship reports that
just work as-shipped on any Alfresco instance. The Auditing feature you
describe is quite heavy on resources. I do not dare to enable that by
installing this module. Therefore the report generation will fail. (Will result
in many reports if applied to all folders... needs to be more specific? in
scope or time?)
What I do can offer is providing such a report for downloading. Kind of
marketplace for reports. Package the report definition + Audit definition + a
little description and have it available for those that need it...
Original comment by tjarda.p...@incentro.com on 14 Nov 2013 at 11:07
GoogleCodeExporter
commented
8 years ago That sounds reasonable and good.
A couple of feature ideas:
1) Add type and aspects applied to node for query tables "folder" and
"document" tables.
It would be great if query tables would have an "appliedAspects" (comma
separated list) and an "actualType" column. That way we could make reports like
"documents per type" or reports like "number of versionable documents". It
would also, in some cases, avoid the need to create and additional table just
to collect data to report just around a concrete subtype.
Maybe even a third "typesImplemented" (comma separated list) field could be
interesting. This field would hold all the type inheritance in an ordered list.
Sometimes the actualType might not be enough because there might be subtypes of
the content you want to report.
2) Action to "execute a report against a node".
The idea would be that apart from the possibility to execute a report scheduled
or in-place you would have an additional action for folders and documents
called "Execute selected report". When pressed the user would have to select a
report from a list and that report would be executed. The report would receive
as a parameter the "noderef".
That feature might not make sense for reports like the ones you have now but
would make sense for reports like the two ones commented in this issue.
Original comment by igor...@gmail.com on 14 Nov 2013 at 11:44
GoogleCodeExporter
commented
8 years ago 1) sounds reasonable and doable. I will add it to my to-do list
2) I hear what you're saying. However, I like to ship this tool with working
out of the box reports. The proposed solution requires a resource intensive
audit-framework-application, and specific report execution features. Although
the solution can almost do as you describe, the report execution does need some
tweaking. I can see the benefit of your idea, and I will try to analyse the
options and possibilities in a future release. It also has a draw-back on the
UI (how to configure these reports?) so it might not be that easy. Please share
you're (hand-drawn) UI idea's where available :-)Original comment by tjarda.p...@incentro.com on 25 Nov 2013 at 8:37
GoogleCodeExporter
commented
8 years ago The 'alfrescoType' and 'aspects' columns are added to the reporting database
;-) (please wait for the 0.9 release)Original comment by tjarda.p...@incentro.com on 26 Nov 2013 at 7:56
GoogleCodeExporter
commented
8 years ago Great fantastic news. Will you also add typesImplemented field so that subtypes
can be checked?
I'll try to post some UI ideas this evening as requested.Original comment by igor...@gmail.com on 26 Nov 2013 at 8:49
GoogleCodeExporter
commented
8 years ago [deleted comment]Ok the attachment ContentReportPropertesProposal shows how I propose managing
the configuration of "content reports". I would add a property that would tell
if this is a regular report or a report intented to be executed against a
content.
For those reports, in parameters substitution property ${nodeRef} would be
substituted by the nodeRef of the content against which this report is being
executed so that each report cand receive the nodeRef in whatever variable they
prefer, in the screenshot the report would receive the nodeRef in the variable
auditedNode. We could possibly avoid this substitution at all and just assume
that the report will always take the nodeRef in a variable with a fixed name.
With this we already know which reports are suitable to be executed against a
node and which ones no. The other 2 screenshots suggest 2 possible ways of
executing the content reports, you could start the execution from the report
itself or you could start the execution from the content.
If you run the execution from the report the action should get the user to a
page where she/he has a picker to select the space or content he wants to
audit. In Alfresco Share there is already such a kind of picker, not sure in
Alfresco Explorer.
If you run the execution from the content itself once clicked the user should
get a screen with a combo box where all content reports are listed.
Another aspect that might not be very clear in "content reports" would be where
to leave the output file. Would it be possible to set target paths relative to
the content?
I've done the screenshots in Alfresco Explorer because that's where you know
have the report execution actions but I think the same approach would make
sense in Alfresco Share.Original comment by igor...@gmail.com on 27 Nov 2013 at 12:48
Attachments:
GoogleCodeExporter
commented
8 years ago 
Thanks for your input!!
The substitution of the noderef is no problem. What I am wondering about is the
business use case. I think this action is required when closing a case, or
archiving the content. I.e. part of a business process, probably driven by a
Rule, Behaviour or Workflow. I see the optional use of a manual action, but
usually it is something done without user interaction. It is triggered because
content is archived. And then it is a must, not a manual choice...
My first step would be to investigate how the ActionExecuter can/needs to be
changed. If that is done, the action can be included in Behaviours and
JavaScript-Rules. It is up to you to make it an action, because you need
evaluators too. I have the feeling I cannot do that right for everybody...
Please share your thoughts about how it should be used in your business
situation...
But first... Get release 0.9 out asap!Original comment by tjarda.p...@incentro.com on 27 Nov 2013 at 8:40
Original issue reported on code.google.com by
igor...@gmail.comon 13 Nov 2013 at 4:00