app/templates/views/manage-users/permissions.html

{% from "components/checkbox.html" import checkbox, checkboxes_nested %}
{% from "components/radios.html" import radio, radios, conditional_radio_panel %}

<fieldset class="form-group">
  <legend class="form-label heading-small">
    Permissions
  </legend>
  <span class="hint">
    All team members can see sent messages.
  </span>
  {% for field in form.permissions_fields %}
    {{ checkbox(field) }}
  {% endfor %}
</fieldset>

{% if form.folder_permissions.all_template_folders %}
  {{ checkboxes_nested(form.folder_permissions, form.folder_permissions.children(), hide_legend=True, collapsible_opts={ 'field': 'folder' }) }}
{% elif user and user.platform_admin %}
  <p class="bottom-gutter">
    Platform admin users can access all template folders.
  </p>
{% endif %}

{% if service_has_email_auth %}
  {% if not mobile_number %}
    {{ radios(
      form.login_authentication,
      disable=['sms_auth'],
      option_hints={'sms_auth': 'Not available because this team member has not added a phone&nbsp;number to their profile'|safe}
    ) }}
  {% else %}
    {{ radios(form.login_authentication) }}
  {% endif %}
{% endif %}
Revert "Change checkboxes to GOVUK frontend" 2020-05-14 16:59:34 +01:00			`{% from "components/checkbox.html" import checkbox, checkboxes_nested %}`
Display nested folders permissions form on user permissions page We're reusing the logic for the `move_to` nested radios field for the user folder permissions nested checkboxes. The main difference between the two forms (aside from the different input type) is that "Move" form contains the root "Templates" as an option, whereas the folder permissions doesn't. It turns out that, because of the way NestedFieldMixin.children and select_nested macro are implemented the easiest way to get the desired folder permissions behaviour is to add the root folder as a choice with a `None` value and `NONE_OPTION_VALUE = None` set on the field, which allows the `child_map` to be constructed but doesn't display the root folder checkbox itself since it gets overwritten in the final `child_map`. 2019-02-25 16:23:28 +00:00			`{% from "components/radios.html" import radio, radios, 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
Revert "Change checkboxes to GOVUK frontend" 2020-05-14 16:59:34 +01:00			`<fieldset class="form-group">`
			`<legend class="form-label heading-small">`
			`Permissions`
			`</legend>`
			`<span class="hint">`
			`All team members can see sent messages.`
			`</span>`
			`{% for field in form.permissions_fields %}`
			`{{ checkbox(field) }}`
			`{% endfor %}`
			`</fieldset>`
Email auth for inviting members and editing permissions 2017-11-01 15:36:27 +00:00
Remove edit_folder_permissions service setting (feature flag) This removes the edit_folder_permission checks from the code, enabling the folder permissions for all services. This also fixes folder-related tests to set up appropriate user permissions. This should only be merged right after alphagov/notifications-api#2428, when all other permission stories are done. 2019-04-02 15:23:46 +01:00			`{% if form.folder_permissions.all_template_folders %}`
Revert "Change checkboxes to GOVUK frontend" 2020-05-14 16:59:34 +01:00			`{{ checkboxes_nested(form.folder_permissions, form.folder_permissions.children(), hide_legend=True, collapsible_opts={ 'field': 'folder' }) }}`
Hide template folder permission editing for platform admin users Platform admin users can access all template folders, so the folder permissions form always displays everything as checked for them, which makes it look like the form isn't actually working. We could do the check based on folder data, but the field still wouldn't have any effect on permissions. So instead, we hide it completely for platform admin users. Submitting the form will remove any folder permissions from the DB for the platform admin user (which can still be created by changing permissions on the template folder 'Manage' page), but that's only relevant if a user stops being a platform admin but keeps their Notify services. 2019-04-03 17:20:32 +01:00			`{% elif user and user.platform_admin %}`
			`<p class="bottom-gutter">`
			`Platform admin users can access all template folders.`
			`</p>`
Display nested folders permissions form on user permissions page We're reusing the logic for the `move_to` nested radios field for the user folder permissions nested checkboxes. The main difference between the two forms (aside from the different input type) is that "Move" form contains the root "Templates" as an option, whereas the folder permissions doesn't. It turns out that, because of the way NestedFieldMixin.children and select_nested macro are implemented the easiest way to get the desired folder permissions behaviour is to add the root folder as a choice with a `None` value and `NONE_OPTION_VALUE = None` set on the field, which allows the `child_map` to be constructed but doesn't display the root folder checkbox itself since it gets overwritten in the final `child_map`. 2019-02-25 16:23:28 +00:00			`{% endif %}`

Email auth for inviting members and editing permissions 2017-11-01 15:36:27 +00:00			`{% if service_has_email_auth %}`
Edit user permissions page shows redacted phone number and Change link Also make plan for story development 2019-02-21 13:03:06 +00:00			`{% if not mobile_number %}`
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			`{{ radios(`
			`form.login_authentication,`
			`disable=['sms_auth'],`
Replace hasn't with has not 2019-09-13 12:49:00 +01:00			`option_hints={'sms_auth': 'Not available because this team member has not added a phone number to their profile'\|safe}`
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			`) }}`
			`{% else %}`
			`{{ radios(form.login_authentication) }}`
			`{% endif %}`
			`{% endif %}`