Allow users to see personal workflow reports

[smagnusson]

Users need a personal workflow report, providing at least the following.

1. Content authors need to a list of what pages they've submitted into the workflow system and which user(s) are now to action these.
2. Publishers need a list of all the pages they're being asked to action, what the action is, who's waiting on them, how long they've been waiting, etc.

The current workflow reporting is inadequate and merely lists every active or completed workflow, and is not accessible to most users, it is intended for superusers.

[phptek]

Implementation Notes

(Please forgive any replication of Sig's original comments)

For Sig's point 1).

Content author and Publisher are arbitrary labels given to security groups and users and as such will differ on an implementation by implementation basis.

The basics

Author's pushing work into a workflow should be able to see a GridField based report of the following:

• Page-titles of pages they've submitted for actioning (e.g. "Approval") was made
• The date and time that submission for actioning (e.g. "Approval") was made
• The name of the group or individual user by whom the work is to be actioned (as per the group(s)/user specified in the creation of that specific transition in that particular workflow)
• The report would be viewable in the existing CMS ReportAdmin GridField showing only those content-items submitted by the current logged-in user (or CMS admin or "Publisher" groups/users who would both see all such items)

For Sig's point 2).

The basics

Similarly to 1). above, "publishers" - as users or belonging to such group(s) - should see a ReportAdmin GridField entry for those content-items ready for actioning by them, and those items having already been actioned.

"Publishers" should therefore see a report of the following:

• Page-titles of pages submitted for actioning (e.g. "Approval")
• The date and time that submission for actioning (e.g. "Approval") was made
• The date and time that submission was actioned (e.g. "Approval")
• For simplicity, selecting an entry in the gridfield goes directly to that content-item with the usual "Approve" button.
• If time allowed, a relevant action button might be shown directly on the gridfield entry itself
• The name of the individual user who submitted the work for actioning.

Anything else?

This all assumes, that ReportAdmin and indeed GridField are the ideal presentation methods for this data. Comments and notes on alternative implemenation are welcome :-)

[stojg]

Are the normal gridfield actions as Filter, Pagination and Sorting included in the scope as well?

[phptek]

I envisage - a least at the outset - using what's already there for ReportAdmin (/admin/reports/). At this stage however I'm not sure how much work is involved in "pulling in" workflow action/transition data to this GridField. Ideas welcome :-)

[nyeholt]

Ideally the individual's workflow details (submissions or actionable items) would appear in a dashboard as soon as they log in (a nice point of integration with UncleCheese's dashboard module...).

I normally think of the 'Reports' section as a system-wide location for reports, as opposed to a personal report section. Because of that, it feels a bit more natural that the two grids appear in the 'Workflow' section as opposed to the 'Reports' section - and that the 'Workflow' menu item has a highlight on it if the current user has items needing action.

[phptek]

Integration would be nice, but time and budget here dictate otherwise :-( having said that, the reports admin already contains lists of page-level info (broken links, pages with no content etc) and what I was thinking was a "pages with workflow xxx that need my attention" report.

Indeed, looking at Sig's recent details just sent to me, I think he envisages something similar to how v2.4 CMS reports admin worked which is to show "publication requests I need to approve" and "My requests pending review" etc, and as many of these as there are workflows in the system.

[phptek]

On a very simplistic level, something which can be built onto later when client/OSS needs requires is simply:

For each workflow in the system (for there can be multiple workflows in effect at any one time) show a simple report in reportsAdmin for each WorkflowAction to be actioned by the current logged-in CMS user.

I think that's pretty much what Sig is keen on for a client he is working with and mostly for whom any work I perform on this will be for.

[nyeholt]

I've spent a few minutes banging together a quick solution at https://github.com/nyeholt/advancedworkflow/tree/user_tasks

It effectively adds two gridfields to the /admin/workflows view - one containing the list of items assigned to that user (directly or via groups) and one displaying all those items that the user has submitted

Note that I haven't bothered with figuring out the actual submission of the subsequent forms from the ItemDetailForms yet...

[phptek]

Hi Marcus,

We should establish a "workflow" of our own on these issues. If one of us is going to start work on an issue, we should try to ensure the issue gets assigned to prevent duplication. I am guilty of not having done this, but we should ensure we do so in future - I had already gotten 2/3rds the way into this issue (#28) when I saw your update.

I haven't pulled your code yet to see if I can combine yours and my work to make some sort of coherent "whole", so what say I do this and post suggestions to this thread?

Cheers.

[nyeholt]

Yeah sure - this had been knocked up in about an hour to demonstrate what I was meaning as opposed to actually writing a working solution (it's quicker for me than banging crap together in gimp! :D)

I'll try adding you to the project so issues can be assigned to people who are working on them. The presumption then is that anyone wanting to contribute anything code wise should check with whoever is assigned before doing something, or if unassigned, post in the thread to let others know something is being done. Sound workable?

[phptek]

I have removed any ref to my original work showing pending/submitted items in a separate report - although part of me still thinks it intuitive to have it there - in favour of modifying your quick solution Marcus to show SiteTree objects as items in the two gridfields instead of workflow items (although there is still a "Workflow Status" heading).

Users then select a row which goes to the page-edit view as per the UI they would get if they went straight to the "Pages" admin directly, for that page.

I think this is more intuitive than showing workflow-only entries in the gridfield, as users need to know what it is they're needing to approve, or what it is they have approved at-a-glance, without needing to click or navigate away to check.

What still needs to be done is to add another column to the gridfield headed "Quick Action" (or some such) where users can click and see the form you had originally used, (but obviously include form-submission handling) that allows them to quickly select from a dropdown "Approve" or "Reject" (Or whatever, depends on effective workflow) if need be.

See: https://github.com/phptek/advancedworkflow/commits/issues/28 for more info (work in progress)

[nyeholt]

I'm not keen on tying userObjects directly to SiteTree, given any data object type can have a workflow applied to it. Would it not be better to have the DataGrid items refer to the WorkflowInstance getTarget() method to retrieve the information you're after? You can still have the action buttons connect to the relevant admin UI section, but doesn't tie workflow to sitetree explicitly.

[phptek]

For sure - hence the @todo comment on userObject() - I posted my thoughts for feedback, so thanks a lot for that - I'm onto it. I had been semi-conscious of the tightly-coupled nature of the implementation thus far, time to remedy that.

[phptek]

Implemented WorkflowInstance->getTarget() method, added permission checks to show suitable data etc.

[phptek]

Re-opening - used wrong issue ID on a previous commit, which auto-closed this one.

[phptek]

Feedback required: Sig (Functional review) Marcus (Code review) whenever each of you has the time.

N.B. This has been rebased with latest silverstripe-australias:master as at Nov 16th

https://github.com/silverstripe-scienceninjas/advancedworkflow/tree/issues/28

Potential Issues / Questions:

1). Clicking a row in each gridfield, take users straight to the "approve" / "reject" transition UI (workflow dependent of course) there is also a "default" hyperlink on the content-title, that takes users to the relevant Admin-area for that object.

Q: Will this suffice for now, with a view to making the additional hyperlink an icon in the future with designer feedback?

2). The data under the "Workflow Status" column, is always "Paused". Should we make the "status" as far as the user is concerned - actually be the current action? (represented by WorkflowInstance.CurrentActionID) ...very possibly I have answered my own question...

Thanks
Russ

[phptek]

Assuming Issue #28 is acceptable (Sig says it is) the following can be considered "would-like-to-have's":

1). Add new action-button/icon to each gridfield row, to speed-up approve/reject procedures. So CMS admins needn't click a a gridfield item to perform actions on it.

This may prove to be very complex given the potential for >2 transitions on any action.

2).

Via the standard CMS site-tree batch-action dropdown, allow CMS users to check the checkbox next to site-tree objects (subject to imminent changes being made to the actions API) and select from a full-range of transitions on the current action of that site-tree object.

Very complicated due to the changeable range of transitions on a given action.

3).

Add ability to view embargo/expiry dates in report-gridfield if QueuedJobs module installed.

4).

Make the existing bog-standard linked-anchor to target-object an icon instead of a simple hyperlink. (Design input needed)