[MGNLUI-2572] Work item state missing in Pulse - "new" is not enough Created: 14/Jan/14 Updated: 13/May/14 Resolved: 13/May/14 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | pulse |
| Affects Version/s: | 5.2.1 |
| Fix Version/s: | 5.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Rainer Blumenthal | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | aperto, support, ux | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Magnolia 5.2.1 on Linux |
||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Template: |
|
||||||||||||||||||||
| Acceptance criteria: |
Empty
|
||||||||||||||||||||
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
||||||||||||||||||||
| Bug DoR: |
[ ]*
Steps to reproduce, expected, and actual results filled
[ ]*
Affected version filled
|
||||||||||||||||||||
| Date of First Response: | |||||||||||||||||||||
| Visible to: |
Frank Sommer
|
||||||||||||||||||||
| Description |
|
After you have clicked a message once, the “new” marker disappears - and you can’t see from the pulse, if you have already taken action on an item or not. It is essential for editors to have an overview of the pending items.
1. Remove the bold from the text after an action has been proceeded. I like Nr. 2 better. After you started reading your messages, you do not have an overview on what messages you already proceeded / rejected. This is a major requirement - which definitely need for the new "Airbus Group" corporate website. |
| Comments |
| Comment by Andreas Weder [ 13/Feb/14 ] |
|
Yes, I agree with you that the flow of messages does not work to keep track on the state of individual work items. We're very aware of that. Actually, the original concept for Pulse messaging asked for the list of work items to be managed separately from the flow of Pulse messages. And we definitely want to go down that path. There's a detailed UI design for this repositioning of work items in Pulse: http://wiki.magnolia-cms.com/x/ZA5PB We do even have a visual design for this already; you can find an excerpt of this work attached to this issue. It's from an earlier state and doesn't indicate "completed" work items yet. However, this change is not on the roadmap for 5.3 workflow currently: http://wiki.magnolia-cms.com/display/DEV/Workflow+Roadmap |
| Comment by Rainer Blumenthal [ 14/Feb/14 ] |
|
Okay, understood. Thank you very much. Fact is: We have 100+ editors who are used to read their work items, and have an overview of what they already did. So we definetly need a solution for that for the Airbus Group, otherwise they will say: "It is a step back." So the only way to get this in - is building it ourselves, as we have no clue on where to hook-in to modify "Pulse" could you please connect our developers: Frank Sommer with anybody who can explain what we have to do? Direct contact is the only chance I see, as 5.4 is too late. |
| Comment by Rainer Blumenthal [ 20/Feb/14 ] |
|
It is much harder than I thought so far: Please imagine 2 editors in the same group, let's say "publisher".
This makes it a blocking point for me. |
| Comment by Andreas Weder [ 28/Feb/14 ] |
|
Rainer, we've discussed the issue we have with workflow items and Pulse, as well as your case and needs. We know that Pulse messaging is not a good solution to serve as an inbox for work items. We've decided to change some of our planning and will start to address this problem now. There's a dedicated team currently working on the workflow functionality. This team will draft a concept until Wednesday, March 12, describing a better solution for dealing with work items in Pulse, based on what I've already shown to you earlier. That concept will be publically available, and we plan to include mockups to illustrate the proposed solution as well. Our current plan is to deploy that solution with 5.3, as we expect that the amount of changes required to implement it will prevent us from shipping it during a 5.2.x maintenance cycle. However, we also plan to improve the current situation ahead of 5.3. One idea is to make it apparent in the message details screen, if content has already been published. This could be achieved by checking the publication state of an item and then updating that screen accordingly. If feasible, this would also allow us to disable some actions available there. The exakt solution and a feasibility research for this are going to be part of the conceptual work we plan to deliver until March 12. BTW and FYI, a Beta 2 release of the workflow module is being built as I write this, which will bring a set of bug fixes and improvements. You may have read the blog posts already: |
| Comment by Espen Jervidalo [ 13/May/14 ] |
|
Superseeded by task introduction. See linked ticket |