Dashboard

The dashboard is setup to display a series of cards related to a user or group. Depending on the group/user permissions, they will see tasks that are related to them.

The cards for the resource are custom created to display information that has been requested by the team. Separate cards are created for each team.

Counters are displayed at the top of the dashboard showing a count for different categories. These can be set in dashboard.py

Front end

The front end is written in Knockout.js and comprises of two files dashboard.htm dashboard.js

counters - this contains the categories at the top of the page that show the counts. These are formatted as an object:

{
	counter1:{
		status1: 2,
		status2: 12,
		status3: 8
	},
	counter2:{
		status1: 6,
		status2: 9,
		status3: 1,
		status4: 6
	}
}

In knockout this will display each counter in a new box and then list its values as key value pairs underneath.

loading loadingCards There are two loading states. Loading is activated on the initial load to compensate for the slow response when building the tasks. This activates loading across the whole page.

loadingCards activates a small loading sequence over the cards only. This is used when changing the filter

sortBy Determines the filters that can be used. These are set in the backend

sortOrder This is always set to asc desc and will change the order

getTasks This calls the api endpoint dashboard/resources and gets the task information from the back end. This returns a paginated response. There are several parameters that can be set for this:

• page (int): determines which page number is returned
• itemsPerPage (int): how many pages should be returned per page
• sortBy (string): the sorting filter to use
• sortOrder (string): the order in which to sort the tasks
• update (bool): whether to rebuild the tasks or call from the cache

openFlagged The function that will open the associated workflow. An item is set in local storage

workflow-open-mode: true

This allows the workflow to be edited. You then need to call the correct reponseSlug for the workflow and the resourceId of the resource to be edited

updateItemsPerPage This controls the amount of items displayed based on the screen size. This is to prevent the cards from overflowing the page. An event listener is tracking a change in the screen size and will call getTasks requesting a new response with a change to the items per page.

Back end

An endpoint is set up dashboard/resources which calls the Dashboard class in dashboard.py

To build the resources the arches orm is being used.

Currently this is working independently of the permissions. The orm is run with with admin() to allow access to all the resources. These are then filtered out depending on the groups the user is a part of.

get This gets the Person resource linked to the user account It will then check to pull from the cache if data is present otherwise it will run the logic for building the resources.

A check is done to see what groups the user is part of. From this output we then choose a strategy that we want to implement for the user. This has been set to allow for multiple strategies to be used

	user_group_ids = self.get_groups(person_resource[0].id)
	strategies = set()
	for groupId in user_group_ids:
	strategy = self.select_strategy(groupId)
	if strategy:
	strategies.add(self.select_strategy(groupId))
	for strategy in strategies:
	resources, counters, sort_options = strategy.get_tasks(groupId, person_resource[0].id, sort_by, sort_order)
	task_resources.extend(resources)

This logic determines how the resources are built for each group In the current example it checks for all groups related to the planning team and then applies custom functions to build the tasks.

Strategies

Strategies are determined by the base strategy Task Strategy

Task Strategy get_tasks - this returns the resources that relate as tasks to the users, this is where the conditions are applied to determine tasks build data - this is where we build the custom data to return for the task. Here we pick out the needed nodegroups

For new dashboards create additional strategies and update the select_strategy function

Get Tasks

This is the logic to determine what tasks the user should receive. It filters the Planning Consultations and checks a group and builds the appropriate tasks for that user. Inputs: groupId (string) - resource id for the group userResourceId (uuid) - the user resource id sort_by (string) - set to deadline but can be adjusted to any key output sort_order (string) - set to either asc or desc

The initial logic in this function creates several states for each user depending on their group It then grabs all the consultations and filters them by name for the planning consultations Then for each resource we check the nodes and run them through a series of conditions to check if they are a task for the user

conditions_for_task is a boolean expression which contains the logic for determining the group. If additional logic is needed it should be added to this variable.

Node Checks

You will see several node checks - these have been implemented to prevent infinite loading if node alias's change

action_status = utilities.node_check(lambda: consultation.action[0].action_status )

Counters

This calls get_count_groups which is a function to build the counters. This is where you can adjust the categories that are returned by adding to the list

counters = utilities.get_count_groups(planning_tasks, ['status', 'hierarchy_type'])

Here we are creating counters for ‘status’ and ‘hierarchy_type’ The string is determined by the key output in the get_tasks

Sort Options

This determines the options used to sort the tasks This is a list of dictionaries with key value pairs id - sets an id for the select on the front end name - the string displayed in the select drop down

Cache

A cache is set to eliminate the need to build the resources with each call. This can be slow. cache_key is set to give the user a unique cache cache_data stores several bits of data: task_resources counters sort_options

Paginator This is set up to work with the arches built-in pagination

Build Data

Description: This builds the data structure for a single resource

Inputs: consultation (resource) - a single resource is used groupId (string) - the groupId that is linked to the strategy

Node Checks

Node checks are performed to check that the nodes exist

Address

The address is built from 3 of the fields: Street, Town, Postcode Adjust address_parts if these needed to be changed, anymore than 3 may break the layout in the UI

Dates

Both dates are changing formats deadline - also controls the warning message. The create_deadline_message needs to run before changing the date format

Resource Data

This is the structure of the data once it is returned. This can have additional added but if any keys are changed they will need to be updated on the front end

Utilities

Any additional functions are in the utilities class

Get Count Groups

Inputs: resources (list) - the list of task resources that is generated count_groups (list) - this is the categories you want to show as counters. These must match the keys output by the resource.

Get Response Slug

Inputs: groupId (string)

This is the slug used to open the correct existing workflow when using the open button on a task

Create Deadline Message

Inputs: date (date)

This creates a message to return to the task for the deadline warning

Sort Resources

Inputs: resources (list: resource instances) sort_by (string) sort_order (string)

This sorts a list of resources depending on the inputs