darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-02-18 17:34:34 -05:00
Code Issues Packages Projects Releases Wiki Activity
Files
203393de235631db0ce3c38dec85da170a634fba
notifications-admin/app/templates/main_nav.html

29 lines
1.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>
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
{% if current_user.has_permissions('view_activity') %}
Rewrite navigation as a class Because we have multiple navigations, which will share the same methods (by subclassing) but different mappings of navigation items to endpoints by overriding the `.mapping` and `.exclude` attributes.
2018-04-25 10:24:32 +01:00
<li><a href="{{ url_for('.service_dashboard', service_id=current_service.id) }}" {{ main_navigation.is_selected('dashboard') }}>Dashboard</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 %}
Rewrite navigation as a class Because we have multiple navigations, which will share the same methods (by subclassing) but different mappings of navigation items to endpoints by overriding the `.mapping` and `.exclude` attributes.
2018-04-25 10:24:32 +01:00
<li><a href="{{ url_for('.choose_template', service_id=current_service.id) }}" {{ main_navigation.is_selected('templates') }}>Templates</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
{% if not current_user.has_permissions('view_activity') %}
<li><a href="{{ url_for('.view_notifications', service_id=current_service.id, status='sending,delivered,failed') }}" {{ casework_navigation.is_selected('sent-messages') }}>Sent messages</a></li>
Refactor go-live readyness into service model All this info is info about the service. So it’s better to put it on the service model because: - encapsulation - later reuse
2018-09-20 09:43:28 +01:00
{% if current_service.has_jobs %}
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
<li><a href="{{ url_for('.view_jobs', service_id=current_service.id) }}" {{ casework_navigation.is_selected('uploaded-files') }}>Uploaded files</a></li>
{% endif %}
{% endif %}
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
<li><a href="{{ url_for('.manage_users', service_id=current_service.id) }}" {{ main_navigation.is_selected('team-members') }}>Team members</a></li>
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
{% if current_user.has_permissions('manage_service') %}
Rewrite navigation as a class Because we have multiple navigations, which will share the same methods (by subclassing) but different mappings of navigation items to endpoints by overriding the `.mapping` and `.exclude` attributes.
2018-04-25 10:24:32 +01:00
<li><a href="{{ url_for('.usage', service_id=current_service.id) }}" {{ main_navigation.is_selected('usage') }}>Usage</a></li>
API keys hooked up and working. All tests passing.
2016-02-29 14:57:07 +00:00
{% endif %}
remove any_ from has_permissions we branch on any_ to either say "require ALL these permissions" or "require ANY of these permissions". But we only ever call the decorator with one permission, or with any_=True, so it's unnecessary
2018-03-01 10:37:55 +00:00
{% if current_user.has_permissions('manage_api_keys', 'manage_service') %}
Rewrite navigation as a class Because we have multiple navigations, which will share the same methods (by subclassing) but different mappings of navigation items to endpoints by overriding the `.mapping` and `.exclude` attributes.
2018-04-25 10:24:32 +01:00
<li><a href="{{ url_for('.service_settings', service_id=current_service.id) }}" {{ main_navigation.is_selected('settings') }}>Settings</a></li>
manage api keys permission should be able to see senders
2018-01-25 15:29:05 +00:00
{% endif %}
remove admin_override from all has_permissions usage as previously pointed out, it's not used anywhere.
2018-03-01 10:30:17 +00:00
{% if current_user.has_permissions('manage_api_keys') %}
Rewrite navigation as a class Because we have multiple navigations, which will share the same methods (by subclassing) but different mappings of navigation items to endpoints by overriding the `.mapping` and `.exclude` attributes.
2018-04-25 10:24:32 +01:00
<li><a href="{{ url_for('.api_integration', service_id=current_service.id) }}" {{ main_navigation.is_selected('api-integration') }}>API integration</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