[MGNLUI-678] Streamline Security App Created: 19/Feb/13  Updated: 21/May/13  Resolved: 21/May/13

Status: Closed
Project: Magnolia UI
Component/s: security app
Affects Version/s: None
Fix Version/s: 5.0

Type: Improvement Priority: Major
Reporter: Daniel Lipp Assignee: Tobias Mattsson
Resolution: Obsolete Votes: 0
Labels: apiteam, app-api
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLUI-675 Simplify defining a main subapp Closed
supersession
is superseded by MGNLUI-1412 Add support for non-closable sub apps Closed
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)
Date of First Response:
Sprint: Beta 2, Beta 3

 Description   

Security App is not really following the app pattern.

  • does not have a main sub app but 4 "same level" ones
    -> has to code opening of all subapps on startup
  • does not offer a way to re-open a sub app once it has been closed

We should either split security app into several apps or create a main subapp that allows opening/closing of other sub apps. Then we could also directly use ContentApp instead of having to define proper SecurityApp (only adds opening of the sub apps) because of the above problems:

        getAppContext().openSubApp(new DefaultLocation(Location.LOCATION_TYPE_APP, "security", "systemUsers", "/system"));
        getAppContext().openSubApp(new DefaultLocation(Location.LOCATION_TYPE_APP, "security", "groups", ""));
        getAppContext().openSubApp(new DefaultLocation(Location.LOCATION_TYPE_APP, "security", "roles", ""));
        getAppContext().openSubApp(new DefaultLocation(Location.LOCATION_TYPE_APP, "security", "users", "/admin"));



 Comments   
Comment by Tobias Mattsson [ 29/Apr/13 ]

I don't agree that the security app is the problem. Seems to be a valid use case. In my opinion the app framework should be flexible enough to support an app that wants to do this. It should certainly not impose rules on apps simply for making them all uniform. Not all apps are equal.

Comment by Andreas Weder [ 03/May/13 ]

I agree with you, Tobias.

The original design, which is quite close to what we have already, called for three 1st level tabs "Users" (with 2nd level tabs "Regular users","System users" as filters), "Groups" and "Roles", plus a dashboard-board like page for a security overview. None of the 1st-level tabs are supposed to be close-able, and they are always open.

For 5.0, I thus suggest that we make the following changes:

  • hide or disable the close button in those tabs featuring one
  • switch the default view from being a tree to a list. Or can there be folders, or is it possible for e.g. a group or role to have sub roles and sub groups? If so, then we'd need a new action or properly enable the existing "new" action in order to support that.

I've discussed this with Pascal and we both agree that we do not want to invent a springboard-like navigation for opening a closed sub app at this point in time. We will define such an element later, if we find it to be necessary. For the security app, we don't see that.

Also, splitting those closely related sub apps into separate apps is really not an option: it would make for a very disruptive UX. You'd have to switch apps several times when creating a new user and assigning her a role and groups. This is exactly a case, where a set of closely related task does not call for separate apps, but for a single app supporting a set of UIs working to gather. Our app granularity would be to high, if we'd have four apps instead.

Comment by Tobias Mattsson [ 06/May/13 ]

We already have the feature of setting a sub app as closable or not closable. All we need is to expose this in the API.

I think the best approach would be to let the sub app itself control if it should be closable. The standard sub app classes in the content app framework should have this configurable.

Since apps open sub apps using locations there's no room for them to say whether it should be closable or not.

Comment by Tobias Mattsson [ 21/May/13 ]

Following discussions the decision has been made to add functionality for making any sub app non-closable.

Comment by Tobias Mattsson [ 21/May/13 ]

We're adding support for non-closable sub apps with MGNLUI-1412

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