[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: |
|
||||||||||||||||
| 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.
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:
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 |