darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-08-18 05:29:38 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
e77e9200cd0ec373d682d5223bd042e6235579e8
notifications-admin/app/templates/main_nav.html

42 lines
3.8 KiB
HTML
Raw Normal View History

Make a function for parsing `help` query param Our templates are a littered with `request.args.get('help', '0')`. This commit refactors these into a single helper method, which can be used by the view functions, then passed to the template. This makes the templates cleaner, and should make it easier to refactor `help` out of the query parameters entirely in the future.
2016-07-05 11:39:07 +01:00
{% if help %}
Let caseworkers send one off messages The main task that we think ‘caseworker’ users do is send one off messages. So this commit: - makes sure users who don’t have the `view_activity` permission (ie not ‘admin’ users) can still send messages - adds navigation so that these users have a place to go from which to start the process of sending a one off message
2018-06-12 16:17:20 +01:00
{% include 'partials/tour.html' %}
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
{% else %}
Tidy up navigation code - use SASS variables for colours and spacing - make navigation an include not a macro (because it doesn’t take any parameters)
2015-12-17 10:28:15 +00:00
<nav class="navigation">
Renamed Notification history to View activity Moved View activity under service name No line under h2 Removed Job history from side nav
2016-03-21 17:01:31 +00:00
<ul>
Allow org team members to see team and usage Organisation team members will be ultimately interested in the detailed usage of each service, but shouldn't necessarily have access to the personal data of that services users. So we should allow these organisation team members to navigate to live services usage page from the organisation page. They may need to contact the team so they should also be able to view the team members page. So they'll then see just usage and team members pages. If they are actually a team member of the service they're viewing, then they'll see the full range of options as usual. This commit implement the above by adding an extra flag to the `user.has_permissions` decorator which allows certain pages to be marked as viewable by an organisation user. The default (for all other existing pages) is that organisation users don’t have permission.
2019-06-19 16:39:13 +01:00
{% if current_user.has_permissions() %}
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
{% if current_service.has_permission('broadcast') %}
Ensure correct selected nav item on broadcast page Once a broadcast has been submitted for approval it either lives on the ‘Current alerts’ or ‘Previous alerts’ page, depending on where it is in its lifecycle. Therefore when clicking into a broadcast from one of those pages the same navigation item should remain selected. Because we select the navigation items based on the request endpoint, this means we need an endpoint for each navigation page, even if the content of the pages will be the same in both cases. This commit adds the two new end points, removes the old, single endpoint and updates links to point to the new endpoint.
2020-10-15 13:15:22 +01:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('current-broadcasts') }}" href="{{ url_for('.broadcast_dashboard', service_id=current_service.id) }}">Current alerts</a></li>
Change previous to past
2021-07-05 13:47:10 +01:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('previous-broadcasts') }}" href="{{ url_for('.broadcast_dashboard_previous', service_id=current_service.id) }}">Past alerts</a></li>
Add a separate page for rejected alerts We don’t want to mix these up with alerts that actually went out.
2021-04-08 13:09:29 +01:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('rejected-broadcasts') }}" href="{{ url_for('.broadcast_dashboard_rejected', service_id=current_service.id) }}">Rejected alerts</a></li>
Add a dashboard for broadcast services This is just a placeholder for now
2020-07-08 11:34:16 +01:00
{% elif current_user.has_permissions('view_activity') %}
Replace links in navigation Includes: - removing all styling of those links outside of GOV.UK Frontend (except for a few fixes due to their interaction with our design) - bringing together some duplicate styles into one block - changing how links are marked as selected, now they have multiple classes Fix Sass-lint error in navigation.scss
2019-12-11 20:33:57 +00:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('dashboard') }}" href="{{ url_for('.service_dashboard', service_id=current_service.id) }}">Dashboard</a></li>
Refactor navigation logic Will be easier to change if the navigation shown to org users is separated from the navigation shown to regular users of a service.
2020-02-03 11:35:17 +00:00
{% endif %}
UI tweaks
2022-07-29 15:28:10 -07:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('templates') }}" href="{{ url_for('.choose_template', service_id=current_service.id) }}">Send messages</a></li>
Remove jobs from the dashboard We’ve done this already for services with the upload letters permission. And all services can upload letters now. But we’re still returning it in the JSON response we use to AJAX-ify the page. Since the jobs response can query stats for up to 50 jobs at a time this puts some load on the API/database. Hopefully this might drop that load a bit.
2020-03-16 12:08:38 +00:00
{% if not current_user.has_permissions('view_activity') %}
Replace links in navigation Includes: - removing all styling of those links outside of GOV.UK Frontend (except for a few fixes due to their interaction with our design) - bringing together some duplicate styles into one block - changing how links are marked as selected, now they have multiple classes Fix Sass-lint error in navigation.scss
2019-12-11 20:33:57 +00:00
<li><a class="govuk-link govuk-link--no-visited-state{{ casework_navigation.is_selected('sent-messages') }}" href="{{ url_for('.view_notifications', service_id=current_service.id, status='sending,delivered,failed') }}">Sent messages</a></li>
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
{% endif %}
Hide irrelevant things from nav for broadcast services Services doing broadcasts wont: - incur costs, so don’t need to see the usage page - be sending anything by uploading, so don’t need to see the uploads page - (for now) be sending anything using the API, so don’t need to see the API integration page
2020-07-08 09:57:32 +01:00
{% if not current_service.has_permission('broadcast') %}
UI tweaks
2022-07-29 15:28:10 -07:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('uploads') }} demo-tooltip" data-demo-tooltip="⚠️ This feature is not available in demo mode" href="{{ url_for('main.uploads', service_id=current_service.id) }}">Letters</a></li>
Hide irrelevant things from nav for broadcast services Services doing broadcasts wont: - incur costs, so don’t need to see the usage page - be sending anything by uploading, so don’t need to see the uploads page - (for now) be sending anything using the API, so don’t need to see the API integration page
2020-07-08 09:57:32 +01:00
{% endif %}
Replace links in navigation Includes: - removing all styling of those links outside of GOV.UK Frontend (except for a few fixes due to their interaction with our design) - bringing together some duplicate styles into one block - changing how links are marked as selected, now they have multiple classes Fix Sass-lint error in navigation.scss
2019-12-11 20:33:57 +00:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('team-members') }}" href="{{ url_for('.manage_users', service_id=current_service.id) }}">Team members</a></li>
Hide irrelevant things from nav for broadcast services Services doing broadcasts wont: - incur costs, so don’t need to see the usage page - be sending anything by uploading, so don’t need to see the uploads page - (for now) be sending anything using the API, so don’t need to see the API integration page
2020-07-08 09:57:32 +01:00
{% if current_user.has_permissions('manage_service', allow_org_user=True) and not current_service.has_permission('broadcast') %}
Replace links in navigation Includes: - removing all styling of those links outside of GOV.UK Frontend (except for a few fixes due to their interaction with our design) - bringing together some duplicate styles into one block - changing how links are marked as selected, now they have multiple classes Fix Sass-lint error in navigation.scss
2019-12-11 20:33:57 +00:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('usage') }}" href="{{ url_for('.usage', service_id=current_service.id) }}">Usage</a></li>
Refactor navigation logic Will be easier to change if the navigation shown to org users is separated from the navigation shown to regular users of a service.
2020-02-03 11:35:17 +00:00
{% endif %}
{% if current_user.has_permissions('manage_api_keys', 'manage_service') %}
Replace links in navigation Includes: - removing all styling of those links outside of GOV.UK Frontend (except for a few fixes due to their interaction with our design) - bringing together some duplicate styles into one block - changing how links are marked as selected, now they have multiple classes Fix Sass-lint error in navigation.scss
2019-12-11 20:33:57 +00:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('settings') }}" href="{{ url_for('.service_settings', service_id=current_service.id) }}">Settings</a></li>
Refactor navigation logic Will be easier to change if the navigation shown to org users is separated from the navigation shown to regular users of a service.
2020-02-03 11:35:17 +00:00
{% endif %}
Make it easy to see API keys for broadcast service This made it easier to debug a problem with the functional tests due to the fixtures not working correctly [^1]. It's a platform admin only convenience over knowing the page URL. We may want to expose the top-level "/api-integration" page but that will require more work to show which broadcasts were sent with which key - currently it's oriented around "messages". For now I think it's useful to see what keys a service has. [^1]: https://github.com/alphagov/notifications-functional-tests/pull/411#pullrequestreview-920069799
2022-03-24 12:29:14 +00:00
{% if current_user.has_permissions('manage_api_keys') %}
{% if current_service.has_permission('broadcast') %}
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('api-integration') }}" href="{{ url_for('.api_keys', service_id=current_service.id) }}">API integration</a></li>
{% else %}
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('api-integration') }}" href="{{ url_for('.api_integration', service_id=current_service.id) }}">API integration</a></li>
{% endif %}
Refactor navigation logic Will be easier to change if the navigation shown to org users is separated from the navigation shown to regular users of a service.
2020-02-03 11:35:17 +00:00
{% endif %}
{% elif current_user.has_permissions(allow_org_user=True) %}
Replace links in navigation Includes: - removing all styling of those links outside of GOV.UK Frontend (except for a few fixes due to their interaction with our design) - bringing together some duplicate styles into one block - changing how links are marked as selected, now they have multiple classes Fix Sass-lint error in navigation.scss
2019-12-11 20:33:57 +00:00
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('usage') }}" href="{{ url_for('.usage', service_id=current_service.id) }}">Usage</a></li>
<li><a class="govuk-link govuk-link--no-visited-state{{ main_navigation.is_selected('team-members') }}" href="{{ url_for('.manage_users', service_id=current_service.id) }}">Team members</a></li>
API keys hooked up and working. All tests passing.
2016-02-29 14:57:07 +00:00
{% endif %}
Remove keylines from nav We have lots of keylines in our pages, eg tables, email message previews This makes the pages look quite cluttered, especially because the keylines don’t always align. I think it looks much cleaner without the keylines in the nav, and we have few enough nav items that we don’t need to chunk them up.
2016-04-11 10:40:32 +01:00
</ul>
Tidy up navigation code - use SASS variables for colours and spacing - make navigation an include not a macro (because it doesn’t take any parameters)
2015-12-17 10:28:15 +00:00
</nav>
Make the tour interactive _The code for this is quite hacky and light on tests. But I’d really like to get it in the app for the research tomorrow to see how well the feature works._ This commit changes the tour from being a set of static screens to some help which guides you through the process of sending your first test message. The theory behind this is that what users are really struggling with is the concept of a variable, rather than the relationship between the placeholders and the column headers. And like learning to program, the best way to learn is by taking an example and modifying it to your own needs. This means that when someone adds their first service we set them up an example email template and an example text message template. Then there is a guided, three step process where _all_ the user can do is send a test message to themselves. Once the message is sent, the user still has the example templates which they can edit, rather than having to remember what they’re supposed to be doing.
2016-05-20 12:05:05 +01:00
{% endif %}
Reference in New Issue Copy Permalink