darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-16 20:49:00 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
cd0fcbb8ccfa311dcc892e7a00d432d19e31faee
notifications-admin/app/templates/views/manage-users/permissions.html

28 lines
782 B
HTML
Raw Normal View History

Set permissions with checkboxes, not yes/no inputs The yes/no pattern didn’t work too well, because: - it didn’t read naturally as a question and answer - often users left them completely unclicked if they didn’t want to set the permission (rather than clicking no) This commit changes both the invite and edit user pages to use checkboxes to set permissions. If also rewords these pages to read more naturally, and explain what the permissions mean. This meant changing some of the view logic around invites and persmissions, and I ended up refactoring a bunch of it because I found it hard to understand what was going on.
2016-03-22 13:18:06 +00:00
{% from "components/checkbox.html" import checkbox %}
Allow setting of caseworking on a user This commit changes the form that the user sees when inviting or editing another user, if the service has the ‘caseworking’ permission set. This will allow creating a new type of user, one who only has the `send_messages` permission, without the `view_activity` permission. We are doing this because we think there are a number of services with a lot of users who don’t need to see the dashboard, or the other team members, and that we can make a simpler interface for these users.
2018-06-12 14:29:47 +01:00
{% from "components/radios.html" import radio, radios, radios_wrapper, conditional_radio_panel %}
Set permissions with checkboxes, not yes/no inputs The yes/no pattern didn’t work too well, because: - it didn’t read naturally as a question and answer - often users left them completely unclicked if they didn’t want to set the permission (rather than clicking no) This commit changes both the invite and edit user pages to use checkboxes to set permissions. If also rewords these pages to read more naturally, and explain what the permissions mean. This meant changing some of the view logic around invites and persmissions, and I ended up refactoring a bunch of it because I found it hard to understand what was going on.
2016-03-22 13:18:06 +00:00
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
<fieldset class="form-group">
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
<legend class="form-label">
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
Permissions
</legend>
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
{% for field in form.permissions_fields %}
{{ checkbox(field) }}
{% endfor %}
Add a ‘See dashboard’ permission Our research and prototyping around ‘basic view’ found that: - a lot of users who send messages rarely or never look at the dashboard (yet it’s the first page they see when they sign in) - team managers like the idea of taking away things that users don’t need in order to make the interface simpler We’ve disentangled the simpler way of sending messages from being part of ‘basic view’. This means we can give managers the option of taking away the dashboard as an independent choice, not something that’s wrapped up in a separate ‘view’. I think that this checkbox is a more straightforward proposition than ‘basic view’ ever was (despite all the work we did to explain it and develop the nested checkbox pattern). In research users would often explain the feature back to us as being about hiding the dashboard – we should try to make Notify operate in terms of concepts that come naturally to people wherever possible.
2018-08-06 11:10:37 +01:00
</fieldset>
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
Relabel existing permissions Since we have added a new, 5th permission the existing permissions should be relabelled so that the five make sense as a coherent set. We especially want to make sure that: - the labels work against the checkboxes and against the tick/crosses on the manage users page (a long time ago this page was layed out differently so didn’t have space for full labels) - there is no confusion between usage and reports This commit also: - re-adds a line about what all users can see (‘sent messages’) but continues to omit the additional bullet points about templates and team members (because we think this is clear enough from reading the permissions) - refactors the `Form` subclass so that the content and order of the permissions only have to be defined once - brings back the ‘permissions’ legend on the `fieldset`
2018-08-08 08:45:58 +01:00
<p class="bottom-gutter">
All team members can see sent messages.
</p>
Email auth for inviting members and editing permissions
2017-11-01 15:36:27 +00:00
{% if service_has_email_auth %}
Add a hint to explain why SMS auth is unavailable If we’re going to ‘disable’ radio buttons then we should always tell users why the radio button is disabled. This is what we found with the API key choices anyway.
2017-11-15 16:04:50 +00:00
{% if user_has_no_mobile_number %}
{{ radios(
form.login_authentication,
disable=['sms_auth'],
option_hints={'sms_auth': 'Not available because this team member hasn’t added a phone&nbsp;number to their profile'|safe}
) }}
{% else %}
{{ radios(form.login_authentication) }}
{% endif %}
{% endif %}
Reference in New Issue Copy Permalink