[MGNLUI-2496] Ability to switch workspace in JCR browser Created: 12/Jan/07 Updated: 15/Apr/16 Resolved: 29/Dec/15 |
|
| Status: | Closed |
| Project: | Magnolia UI |
| Component/s: | workbench |
| Affects Version/s: | 5.3.12, 5.4.3 |
| Fix Version/s: | 5.4.4 |
| Type: | Improvement | Priority: | Major |
| Reporter: | Andreas Weder | Assignee: | Aleksandr Pchelintcev |
| Resolution: | Fixed | Votes: | 7 |
| Labels: | is-time-consuming, jcrbrowser, pain-point, usability, user-feedback, ux | ||
| Σ Remaining Estimate: | 0d | Remaining Estimate: | 0d |
| Σ Time Spent: | 0.25d | Time Spent: | 0.25d |
| Σ Original Estimate: | Not Specified | Original Estimate: | Not Specified |
| Attachments: |
|
|||||||||||||||||||||||||||||||||||||||||||||
| Issue Links: |
|
|||||||||||||||||||||||||||||||||||||||||||||
| Sub-Tasks: |
|
|||||||||||||||||||||||||||||||||||||||||||||
| 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)
|
|||||||||||||||||||||||||||||||||||||||||||||
| Release notes required: |
Yes
|
|||||||||||||||||||||||||||||||||||||||||||||
| Date of First Response: | ||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | UX pain points 2018 | |||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Basel 25 | |||||||||||||||||||||||||||||||||||||||||||||
| Story Points: | 13 | |||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Currently, the jcr browser would be more useful if it could be used to browse any workspace. It would be great not to have to manually copy or change its config everytime we need to browse a different workspace; we could simply have a dropdown on top of the page to select the workspace we want to browse. |
| Comments |
| Comment by Antti Hietala [ 21/Jan/14 ] |
|
This would be a great enhancement. Please raise the priority. It would help on many levels:
|
| Comment by Mikaël Geljić [ 21/Jan/14 ] |
|
I'd gladly prioritize this more, but it's currently not under the radar - and actually depends on UI work for 5.3. So this won't change much in the next few weeks. However when the technical grounds and UX are ready it will most likely be a no-brainer to do, and we might then have a chance to sneak it in. Let's see what happens. As for node-types, it may be possible to use generic JCR nt:base, since JCR specific workspace config nodes and system properties are filtered out elsewhere. This can/should then probably be the subject of another quickwin issue. |
| Comment by Andreas Weder [ 08/Sep/15 ] |
|
I'm updating this issue since some dependancies seems to have been resolved. |
| Comment by Richard Unger [ 08/Sep/15 ] |
|
+1 This would be a great feature. It is mega-annoying to always have to create all those JCR Browsers for the other workspaces manually. website (pre-existing) |
| Comment by Andreas Weder [ 10/Sep/15 ] |
|
I've attached a couple of mockups illustrating the UI design for a JCR browser with a workspace switcher. The mockup actually also shows how this should look visually. The workspace selectorWe'll offer a (textual) selector in the area where the view switches and options are located. I've illustrated two options, one with a mostly static selector, one showing a selector with built-in search and paging, which resembles the Vaadin editable combobox.
Being a verbose ("show website workspace") is in-line with how we've been naming elements from the beginning, and also with other filters I've designed recently for solutions such as those used in the Definitions app, which will appear shortly. Optional: a way to show the system propertiesThe design also shows how we would handle system properties such as those starting with "nt:" and "mgnl:". By default, system properties are hidden, and the checkbox actually reflects that. Unticking the box shows all system properties in addition to non-system properties. What we haven't agreed upon yet is whether a view showing system properties should be: a) entirely read-only, b) only its system properties should be read-only or c) should remain editable. |
| Comment by Michael Mühlebach [ 04/Nov/15 ] |
|
Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes. |
| Comment by Andreas Weder [ 26/Nov/15 ] |
|
I'm reopening this issue as it's piece in our puzzle to improve the configuration story in 5.4.x. It was also "selected for backlog". |
| Comment by Richard Unger [ 26/Nov/15 ] |
|
Yes, please finally implement this. Please implement this feature!! |
| Comment by Andreas Weder [ 26/Nov/15 ] |
|
runger Yes, it's a total bummer. Thanks for emphasizing this - it helps to increase the pressure to tackle this. I'd like to get this done as part of a set of needed improvements to the 5.4.x family we're currently working on. The stories triggered by the light development feature stream are not completed yet, especially those dealing with how we handle, view and maintain control over configuration stemming from multiple sources. I've positioned this issue as part of that story arc. |
| Comment by Jan Haderka [ 30/Nov/15 ] |
|
If I may offer some contribution to this: Node Type column formatter that would be necessary if we browse through any-node-type workspaces: and action + dialog to create nodes with configurable types and w/ properties (as a bonus it allows you to create multiple levels of hierarchy at once). |
| Comment by Richard Unger [ 30/Nov/15 ] |
|
Yes, yes! Love it! |
| Comment by Jan Haderka [ 30/Nov/15 ] |
|
Not to do too much of self-promotion, but did you test rest of the tweaks? |
| Comment by Aleksandr Pchelintcev [ 18/Dec/15 ] |
|
It has been noticed that when system properties are included in a JcrContainer and hence are selectable - the location handling maybe flawed: system properties start with either mgnl: or jcr: which contain a colon. That makes it hard to parse to distinguish the parts of content app locations which are in turn also separated with colons. Currently there is a workaround for that in JcrItemUtil - the colon is replaced with — during serialisation/de-serialisation. |
| Comment by Philip Mundt [ 21/Dec/15 ] |
|
Making
when a method with the same name exists in subclass. I believe we can ignore this case!? (See http://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.4.17) |
| Comment by Andreas Weder [ 22/Dec/15 ] |
|
Reopened during QA: I've found two issues related to deleting items and a couple of visual problems. The latter we could tackle later, the former we should address before moving on, but I suggest we fix them all in one go. I've added subtasks for each issue: |