Follow-up issue from #1441648: UI: TMGMT Core.
Quote from @cgalli:
#3 hmmm, we did indeed discuss the option of defining a 'published' state.
We could define a node (= job Item) as translated when all data items are clicked to green. And use the 'approve all' step as publishing. Useful for management of larger tasks. Logically, we would need to present a filter for the 'translated' state in the jobs list as well as a VBO 'publish' command. A manager could prepare all translations and release them into the wild at a given point in time.
Some remarks, further discussions later:
- Publish could be confusing as there is is an overlap with e.g. published nodes. There is no guarantee that a published translation results in a published node. Maybe "Accept and publish translation" as the button instead of just Publish?
- We already have a job item status accepted, we could optionally rename that or at least visualize it in the progress circle would help. Color suggestion?
- Filter on jobs items where all data items but not the item itself is accepted/approved/published is tricky, because we can't query for that information and currently don't persist it.
- We already have a Publish VBO actions that is currently called Accept translation (just on the job overview). We can rename that to be similar to the button label, of course.
- Also note that accepting single data items is and will continue to be optional, publishing/accepting with the global button/vbo action does not care about that.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | reviewed-approve-accepted-1873828-9.patch | 38.95 KB | berdir |
| #9 | reviewed-approve-accepted-1873828-9-interdiff.txt | 7.11 KB | berdir |
| #7 | reviewed-approve-accepted-1873828-7.patch | 35.12 KB | berdir |
| #5 | reviewed-approve-accepted-1873828-5.patch | 41.31 KB | berdir |
| #5 | Job overview Drupal 7.png | 23.57 KB | berdir |
Comments
Comment #1
cgalli commentedAs remarked, 'translated' is not really a status but represents a node state in which all data items have been marked as ok.
When saving the review, it can be checked if the job item is in the state of 'ready to release to the public site'. At that moment a status 'ready for release' can be set on the job item. This can be filtered for in the jobs view and and can be shown in the circles. (colors see below). For the time being, a data item status cannot be reversed, so there is no way to change the data item once the job item status has been set to 'ready for release'.
There should be a second action to go from this state to 'translated'. On the review pane we could call the button 'Release to public' to prevent confusion with the 'published' state of a node. Hopefully there would also be a way to apply this step to a bunch of job items (bulk ops). I do see the difficulty of doing this in the VBO as such an action must only be applied to job items with state 'ready to release'.
As far as colors go, we have a little problem. Translated and released should remain green, signaling an ok situation. There is no color between yellow (needs attention/needs review) and green. So we can only move all colors up one notch:
in progress: blue (unchanged)
outdated: red
needs review: orange
ready to release: yellow
translated: green
Any further suggestions are welcome.
Comment #2
berdirTranslated sounds to me like "needs review". It doesn't imply that the translation is good, it just says there is one. Which is what we call needs review.
- Release to public isn't better than publish. We don't care or know what will then happen with it. The created/updated node might default to unpublished. We could be on a server and clicking the button means that the translation is sent to the client. We're doing just one thing: Accept/Approve the translation. Anything else is context specific, a context that we currently don't know. Maybe we can try to get that context and ask the source plugin for a label, not sure.
- As I said, the ok buttons are optional (In fact, everything is, you can just have everything auto-approved). You can release/accept/publish anything, the only thing that we can/should prevent is accept something that is only partially translated. So there is no reason that the VBO action only needs to happen on ready to release items.
We might need to discuss this once more in person.
Comment #3
miro_dietikerGood to see progress here. The current situation is really confusing.
For the VBO actions i see both required:
* Release all items that are approved
* Autoaccept and Release all items
This could be one action with an option "approve all items".
The indicators have two important missions
* Show ME if i need to do anything currently
* Provide me overview in the whole process / progress
The current progress bar is at 100% if all items are accepted. A user doesn't understand that this still needs action. We need a last step for finalized items (release to public, publish, ... however the naming is).
Regarding naming:
* Accept: to mark something as fine (and optionally notify the translator of it)
* Release: to transfer accepted items to the source plugin
This could be named "Release and publish" if we know the status flag is set to "published". A source plugin can have a capability to tell us about native status. We might add a checkbox to the "Release" to optionally "publish". Note here we need extensibility to add complex custom workflows.
Regarding the progress bars: I thought about splitting them up between local and remote progress:
* TMGMT Local: Progress on our-side steps like "needs review", "accepted" (ready to release), "released"
** Outdated is a special case that possibly even needs special coverage. I don't know the details here, but an item in any state could be outdated.
* TMGMT Remote: "in progress", "rejected" ... we are waiting for translator work ... till "completed"
* Native Source: "outdated"
If i reject an item in your status list above, what is the new status?
If we have multiple perspective statusbars, we possibly need less colors and they are more clear.
I really don't know what is best here. My status split list needs more detail and thinking.
Comment #4
berdirOk, discussed and I think we have something that makes sense.
We make the following changes:
- Rename the buttons on the review form to "Save as completed" and "Save", similar to the local translator page
- The button label for the data item approve is renamed to "Reviewed"
- You can "Unreview" something, icon should be a barred checkmark if possible
- Reviewed/Unreviewed has no functional implications, it is just a flag that you can use or not
- We introduce a new data item state called "Accepted" (Matching the "Accepted" job item state) with a dark green color
(Later)
- Ask the user after he marked everything as reviewed if we wants to complete the job item.
This allows to separate reviewed (clicked the checkbox) and accepted data items (part of a job item that was accepted) on the job overview, which is currently the same color/state.
Comment #5
berdirOk, here we go, first patch.
Implemented as described above.
- Renamed all occurences of approved to accepted, so that the data item state matches the job item state.
- Colors probably need to be improved, I just picked something
- The icon is a now a checkmark that is striked through with CSS Looks ugly, but don't really have a lot of options..
- Have not touched the local translator, we will need to figure out how to deal with states and colors there in a separate issue.
- Also make sure to test that viewing an item after it has been accepted/completed works as expected.
- Contains upgrade path, that means after applying this patch, you need to run update.php and then you can't go back, so you probably want to make a backup first. Also, the upgrade should be tested to work as expected...
Also attaching two screenshots of the job and job item overview.
Comment #7
berdirDiffed against an old branch.
Comment #9
berdirFixed the failing tests and also improved the upgrade tests a bit.
Comment #10
cgalli commentedInstalled the patch and ran updates without problems. Using local translator to test gives me the following message.
Fatal error: Call to undefined method TMGMTLocalTask::getCountReviewed() in /var/www/tmgmt/sites/all/modules/tmgmt/views/handlers/tmgmt_handler_field_tmgmt_progress.inc on line 34
Correct this or should I test with other translator?
Comment #11
berdir@cgalli: Which patch did you test? The latest one from #9 should contain a fix for this and be ready for testing.
That said, it is possible that the progress/colors/counts for the local translator are even more confusing (if that's possible ;)) with this patch, we need to discuss and fix that in another issue so don't worry about it. The local translator should still *work*, though.
Comment #12
cgalli commentedInstalled and tested #9, the error is gone.
The flow works as discussed. It remains a complex system, but the statuses are unambigious now.
The colors are pretty clear to me, no need to change for the time being.
Cooperation with LUI on the same machine can indeed be confusing as one system show status from the other :-)
Comment #13
berdirThe patch removes the call to approve/acceptDataItem(), so that is currently not implemented at all.
No translator is AFAIK currently using it, so I opened a follow-up issue for that as I think we want to change it to operate on job item level anyway.
#1887742: Re-introduce accept functionality on job item level
Comment #14
berdirConfirmed that all translator tests are still passing and commited this. Thanks for testing.
Will add a quick change notice about this later on.
Comment #15
berdirhttp://drupal.org/node/1889864