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

66 lines
2.0 KiB
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
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
{% if 'caseworking' in current_service.permissions %}
Remove show/hide behaviour from permissions form In research we found that: - people didn’t initially realise that the permissions expanded when the ‘admin’ option was selected - not having all the options visible at once makes it hard to know what permissions you are (and more importantly aren’t) giving to people This commit makes it so that: - the options within the ‘admin’ option are always visible - a bit of Javascript logic makes it so you can pick ‘caseworker’ and ‘manage service’, for example (by deselecting one when you pick the other)
2018-06-21 14:00:00 +01:00
<div class="conditional-radios" data-module='conditional-radios'>
{% call radios_wrapper(form.user_type) %}
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
{% for option in form.user_type %}
Remove show/hide behaviour from permissions form In research we found that: - people didn’t initially realise that the permissions expanded when the ‘admin’ option was selected - not having all the options visible at once makes it hard to know what permissions you are (and more importantly aren’t) giving to people This commit makes it so that: - the options within the ‘admin’ option are always visible - a bit of Javascript logic makes it so you can pick ‘caseworker’ and ‘manage service’, for example (by deselecting one when you pick the other)
2018-06-21 14:00:00 +01:00
<div class="bottom-gutter-1-3">
{{ radio(option, option_hints={
'admin': 'See dashboard and team members',
'caseworker': 'Send messages and see sent messages'
}) }}
</div>
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
{% if option.data == 'admin' %}
Remove show/hide behaviour from permissions form In research we found that: - people didn’t initially realise that the permissions expanded when the ‘admin’ option was selected - not having all the options visible at once makes it hard to know what permissions you are (and more importantly aren’t) giving to people This commit makes it so that: - the options within the ‘admin’ option are always visible - a bit of Javascript logic makes it so you can pick ‘caseworker’ and ‘manage service’, for example (by deselecting one when you pick the other)
2018-06-21 14:00:00 +01:00
{% call conditional_radio_panel('admin') %}
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
<fieldset class="form-group">
<legend class="form-label">
Remove show/hide behaviour from permissions form In research we found that: - people didn’t initially realise that the permissions expanded when the ‘admin’ option was selected - not having all the options visible at once makes it hard to know what permissions you are (and more importantly aren’t) giving to people This commit makes it so that: - the options within the ‘admin’ option are always visible - a bit of Javascript logic makes it so you can pick ‘caseworker’ and ‘manage service’, for example (by deselecting one when you pick the other)
2018-06-21 14:00:00 +01:00
Extra permissions
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
</legend>
{{ checkbox(form.send_messages) }}
{{ checkbox(form.manage_templates) }}
{{ checkbox(form.manage_service) }}
{{ checkbox(form.manage_api_keys) }}
</fieldset>
{% endcall %}
{% endif %}
Remove show/hide behaviour from permissions form In research we found that: - people didn’t initially realise that the permissions expanded when the ‘admin’ option was selected - not having all the options visible at once makes it hard to know what permissions you are (and more importantly aren’t) giving to people This commit makes it so that: - the options within the ‘admin’ option are always visible - a bit of Javascript logic makes it so you can pick ‘caseworker’ and ‘manage service’, for example (by deselecting one when you pick the other)
2018-06-21 14:00:00 +01:00
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
{% endfor %}
{% endcall %}
</div>
Remove show/hide behaviour from permissions form In research we found that: - people didn’t initially realise that the permissions expanded when the ‘admin’ option was selected - not having all the options visible at once makes it hard to know what permissions you are (and more importantly aren’t) giving to people This commit makes it so that: - the options within the ‘admin’ option are always visible - a bit of Javascript logic makes it so you can pick ‘caseworker’ and ‘manage service’, for example (by deselecting one when you pick the other)
2018-06-21 14:00:00 +01:00
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
{% else %}
<fieldset class="form-group">
<legend class="form-label">
Permissions
</legend>
{{ checkbox(form.send_messages) }}
{{ checkbox(form.manage_templates) }}
{{ checkbox(form.manage_service) }}
{{ checkbox(form.manage_api_keys) }}
</fieldset>
<div class="bottom-gutter">
<p class="form-label">
All team members can see
</p>
<ul class="list list-bullet">
<li>templates</li>
<li>history of sent messages</li>
<li>who the other team members are</li>
</ul>
</div>
{% endif %}
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