Bug 1026899

Summary: [Usability] Provide "lock" icons for read-only form modes as well
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jakub Cechacek <jcechace>
Component: Web Console - UXAssignee: Heiko Braun <hbraun>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Jelinek <pjelinek>
Severity: medium Docs Contact: eap-docs <eap-docs>
Priority: unspecified    
Version: 6.2.0CC: brian.stansberry, crobson, hbraun, hpehl, jkudrnac, lclayton
Target Milestone: DR5Keywords: Reopened
Target Release: EAP 6.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: Usability
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-09 11:38:16 UTC Type: Task
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
screen shot of writing datasource security
none
screen shot of reading datasource security
none
design alternatives none

Description Jakub Cechacek 2013-11-05 15:40:59 UTC
When attributes are not writable, the various edit forms show the lock icon next to the attribute. The "read" views for resources should do the same for attributes that are not readable, to give the user a better indication that the empty value displayed may not be the actual value.

Comment 1 Heiko Braun 2014-07-09 11:38:16 UTC
In agreement with Catherine we've decided that UX issues will be tracked separately.

Comment 2 Jakub Cechacek 2014-07-21 06:21:39 UTC
Issue moved under the UX component. 

Also moved to 6.4 as this issue is still valid for 6.3. Use ack flags to decide whether we want to go through with it or not.

Comment 3 Catherine Robson 2014-08-01 17:32:15 UTC
UX will look at improving this editing and viewing flow for 'locked' fields in EAP 7.

Comment 4 Liz 2014-08-12 18:13:02 UTC
Would it be possible to get a screenshot of this?

Comment 5 Brian Stansberry 2014-08-12 19:05:12 UTC
Created attachment 926194 [details]
screen shot of writing datasource security

Attached screenshot of editing attributes for a datasource when in a role that doesn't allow modification of those particular attributes. Lock icons are visible.

Comment 6 Brian Stansberry 2014-08-12 19:06:37 UTC
Created attachment 926195 [details]
screen shot of reading datasource security

Attached screen shot of just reading those same attributes. No lock icons visible. The attributes actually have values, but they are not shown because the user does not have permission to read them.

Comment 7 Liz 2014-08-13 17:45:17 UTC
Created attachment 926545 [details]
design alternatives

Comment 8 Liz 2014-08-13 17:46:45 UTC
Some alternative solutions, please refer to the attachment.

Option 1 – If NONE of the fields can be viewed or edited, it seems better to just provide an inline information message, rather than a form/table with “empty” values. The inline message would allow the user to quickly understand what the issue is. And it could even offer suggestions for resolution (log back with under a different role?).

Option 2 – If SOME of the fields can be viewed/edited:

* Alternative A) Hide the fields that the user is not allowed to see. And offer some inline help text to explain that the permissions are limiting the view.

* Alternative B) If showing the fields that the user does not have permissions to, is helpful to the user by providing context or additional information – then: Gray-out the fields that the user cannot view or edit, and provide some inline help text for each row.

Comment 9 Jakub Cechacek 2014-08-14 07:13:33 UTC
ad Option 2 option B)

This is partially what we are doing currently. If user edits the form and doesn't have the permission the field is Grayed-out. With that part I am quite OK. The real problem is reading the value out of edit mode. Unless some further information (e.g. the lock icon) is provided there is no way to know whether the value is empty or whether i simply don't have the permissions to read it (unless I switch to edit mode).

Comment 13 Heiko Braun 2014-08-25 13:33:02 UTC
Let's keep it simple and go for alternative B

Comment 14 JBoss JIRA Server 2014-10-10 08:21:04 UTC
Heiko Braun <ike.braun> updated the status of jira HAL-294 to Resolved

Comment 15 Pavel Jelinek 2014-11-26 09:30:56 UTC
Should this still remain in POST state?

Comment 16 Jakub Cechacek 2014-12-12 12:19:23 UTC
Verified 6.4.0.DR12