[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: PNG File 1 JCR browser.png     PNG File 2-1 JCR browser - opt v1.png     PNG File 2-2 JCR browser - opt v2.png     PNG File 3 JCR browser w sys props.png     PNG File Searchable combobox.png    
Issue Links:
dependency
depends upon MGNLUI-322 Location fragment should be escaped Closed
depends upon MAGNOLIA-1306 Allow more nodetypes in jcr browser Closed
depends upon MGNLUI-3589 Allow views to offer view options Closed
is depended upon by MGNLUI-3580 Replace the "JCR config"/"Configurati... Closed
duplicate
is duplicated by MGNLUI-2710 JCR Browser with multiple repositories Closed
relation
is related to MAGNOLIA-1201 tools: make a develop module Closed
is related to MGNLUI-3021 Provide ability to display system pro... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MGNLUI-3704 Fix the order of the components in wo... Sub-task Closed Aleksandr Pchelintcev  
MGNLUI-3705 Provide backwards compatible API for ... Sub-task Closed Aleksandr Pchelintcev  
MGNLUI-3706 Fix styling and layout issues of the ... Sub-task Closed Aleksandr Pchelintcev  
MGNLUI-3707 Provide JCR node type selector field Technical task Closed Aleksandr Pchelintcev  
MGNLUI-3708 Provide JCR node type column formatter Technical task Closed Aleksandr Pchelintcev  
MGNLUI-3726 Deleted property remains selected, le... Sub-task Closed Aleksandr Pchelintcev  
MGNLUI-3728 List of workspaces is not sorted alph... Sub-task Closed Aleksandr Pchelintcev  
MGNLUI-3729 Adjust visual appearance of view options Sub-task Closed Aleksandr Pchelintcev  
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:

  • The website JCR browser extends the workbench definition from the Configuration app. This is the first stumbling block for users who configure a browser for a different workspace. "Why can't I see all my nodes?" (because the Configuration app filters the node types)
  • It reduces clutter in the app launcher. When you don't need to create a separate app to quickly browse other workspaces, you need fewer tiles in the app launcher.
  • Flipping between workspaces is a common task. For example, when you are learning how the Imaging module generates renditions you look in the imaging, dam and website workspaces.
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.
For our work we typically immediately create browsers for the following workspaces:

website (pre-existing)
dam
users
groups
roles
ugc (that's our user-generated content)

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 selector

We'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.

    • The static selector, while easy to implement, has the disadvantage that it gets very long quickly. Actually, what I'm showing is the list of workspaces as of 5.4.1.
    • The searchable selector (I'm not fond of the paging options) is a bit more challenging to style, but it that would be worthwhile the effort. I wouldn't want to see the standard style here.

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 properties

The 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.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

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.
It is SO annoying to always have to manually create a bunch of copies of the JCR browser app just to have JCR browsers for all the different workspaces.
And for imaging workspace you really need it, there is no other way to selectively clear the imaging cache when you modify the variations.
For DAM, Users, Roles, etc... we often need it, also for our user-generated-content workspaces.

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:
https://github.com/rah003/neat-tweaks/blob/master/neat-tweaks-developers/src/main/java/com/neatresults/mgnltweaks/ui/column/NTColumnFormatter.java

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).
https://github.com/rah003/neat-tweaks/blob/master/neat-tweaks-developers/src/main/java/com/neatresults/mgnltweaks/ui/action/SaveConfigAddNodeDialogAction.java
dialog is buried here under neat-tweaks-developers:addContent id.
https://github.com/rah003/neat-tweaks/blob/master/neat-tweaks-developers/src/main/resources/mgnl-bootstrap/neat-tweaks-developers/config.modules.neat-tweaks-developers.apps.xml

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?
https://www.magnolia-cms.com/blogs/jan-haderka/detail~@20--life-changing-tweaks-for-magnolia-editors-and-developers~.html

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 protected private methods final might break binary compatibility, namely:

  • info.magnolia.ui.vaadin.integration.contentconnector.JcrContentConnector#parseNodePath(String)
  • info.magnolia.ui.vaadin.integration.contentconnector.JcrContentConnector#parsePropertyName(String)
  • info.magnolia.ui.vaadin.integration.contentconnector.JcrContentConnector#isPropertyItemId(String)

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:

Generated at Mon Feb 12 08:57:12 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.