Grid Behaviours Feature - v2.5.0

Overview

Idea: Grid Behaviours feature enables restrictions on editing grid content based on user group and issue status. It simplifies access management within grids by defining editable and read-only permissions.

Goal: The primary goal is to provide a streamlined workflow and interface for configuring and applying grid editing restrictions, ensuring flexible yet controlled access to grid content.

Open

Use Case: Order Management for a Pizza Shop

Scenario

A popular pizza shop uses a Grid on Issue Screen to manage customer orders. The grid contains rows for each order item, with columns like Order Items, Price, Amount, Total, and Special Requests. Issues include 4 Issue Statuses like Todo, Preparing, Ready, Delivered, Canceled.

The staff includes:

• Manager: Oversees operations and resolves escalations.

• Kitchen Staff: Handles order preparation.

• Delivery Staff: Manages delivery of orders.

Currently, all fields in a grid row are either editable or read-only based on user role and the order's status. While this simplifies permission handling, it still ensures data integrity by locking rows when orders are completed or cancelled.

How Grid Behaviours Solve This

1. Role-Based Permissions

Permissions are applied to the entire grid, rather than individual fields:

• Manager: Can edit all rows at any time, including updating orders, changing statuses, or reassigning tasks.

• Kitchen Staff: Can only edit rows for orders that has Preparing status (e.g., updating items, amount or special request). Grids for other statuses are read-only.

• Delivery Staff: Can only read rows for orders in all statuses.

2. Status-Based Restrictions

• Grids for orders marked Delivered or Cancelled are read-only for all users except the Manager, preserving historical records.

Example Workflow in Action

1. Order Creation and Preparation:

• A cashier adds a new order for "Order #2001" with the status Preparing.

• Kitchen Staff view the order in the grid and prepare the items. Once done, they update the Status to Ready, making the grid read-only for them.

2. Delivery Process:

• Delivery Staff check the orders with the Ready status. They update the Status to Delivered once the order reaches the customer.

• After marking an order as Delivered, the grid becomes read-only for everyone except the Manager.

3. Manager Oversight:

• The Manager reviews all orders, resolves escalations (e.g., mistake in order items, amount, or wrong special request), and ensures all Delivered or Cancelled orders remain locked.

Key Features

Grid Configuration UI Update

A new "Grid Behaviours" tab is added to the grid configuration interface for managing grid behaviours.

Configure New Grid Behaviours

A button labelled "Add Grid Behaviours" allows users to create and configure grid behaviours. Clicking opens a form-based popup.

Edit Grid Behaviours Configuration

Users can edit the existing grid behaviours configuration by clicking “Edit” button on each one.

Delete Grid Behaviours

Users can delete the existing grid behaviours by clicking “Delete” button on each one.

Apply Grid Behaviours to Grids

Apply access for a user to a grid on an issue based on:

• Attribute (Editable/Read-only)

• Condition (Issue Status)

• Restriction (Users/Groups/Everyone)

Audit Log Monitoring

Tracks grid behaviour logs with a focus on conflicts and errors. Automatic cleanup of logs older than 24 hours (daily at 00:00 UTC).

Instructions for Use

Add Grid Behaviour

Step 1: Open Grid Behaviours tab

1. Navigate to the grid configuration interface.

2. Select the "Grid Behaviours" tab.

Open

Step 2: Adding a new Grid Behaviour

Click "Add Grid Behaviours" button to add your first grid behaviour.

When you already have grid behaviours, click “Add” button to add a new grid behaviour.

Step 3: Configuring Grid Behaviour

1. Name Input: Enter your grid behaviour’s name

2. Element Input: Pre-selected as "Grid" (default) and you can not change it.

3. Attribute Input: Choose between "Editable" or "Read-only".

4. Condition Input: Select "Issue Status".

5. Issue Status Input: Select applicable statuses (e.g., "Open", "Closed").

6. Restriction Input: Select "Everybody", specific "Users", or specific "Groups".

6.1 Everybody: Apply the access of this grid behaviour to all users in the current organization.

6.2 Users: Apply the access of this grid behaviour to all the selected users.

6.3 Groups: Apply the access of this grid behaviour to all users in the selected groups.

7. Click "Save" to temporarily save the grid behaviour configuration.

After saving, the new grid behaviour will be displayed on the Behaviours List.

8. Click “Save” to save the grid configuration and the grid behaviour also.

How Grid Behaviours are applied to Grids

Example:

John Doe opens Issue A has Issue Status Done, including Grid 1.

Grid 1 includes 7 Grid Behaviours sorted by earlier created date.

Step 1: Reorganize the Grid Behaviours List

When John Doe opens Issue A with Issue Status = DONE, the system sorts the behaviours in the following order:

1. Prioritize by Issue Status:

   • Behaviours matching DONE will come first, above others (e.g., "In Progress").

2. Then, prioritize by Restriction:

   • Behaviours for Users (John Doe) are ranked higher than those for Groups or Everyone.

3. Finally, prioritize by Creation Date:

   • Behaviours created earlier are ranked higher.

Example Sorted List:

• GB2: Read-only, Issue Status = DONE, Restriction = Users (John Doe)

• GB5: Editable, Issue Status = DONE, Restriction = Users (John Doe)

• GB6: Editable, Issue Status = DONE, Restriction = Groups (including John Doe)

• GB4: Read-only, Issue Status = DONE, Restriction = Everyone

• Others are ranked lower based on mismatched conditions.

Step 2: Apply the Best Matching Behaviour

Once the behaviours are reordered, the system applies the best-matching behaviour according to these rules:

• Matching behaviour: If the behaviour's conditions (Issue Status, Restriction) match, it’s applied.

• Conflicts: If two behaviours have different attributes (e.g., one is Read-only, another is Editable), the system applies the one that’s ranked highest.

Example Application:

For Issue A, the system checks each behaviour in the reordered list:

1. GB2: It’s a perfect match (Read-only, Issue Status = DONE, Restriction = Users (John Doe)) → APPLIED

2. GB5: It’s Editable, so it conflicts with GB2 → NOT APPLIED

3. GB6: It’s also Editable, so it conflicts with GB2 → NOT APPLIED

4. GB4: It’s Read-only and matches the status and restriction → APPLIED

5. Other Behaviours: Do not meet the required conditions (either Issue Status or Restriction) → NOT APPLIED

Final Result: What John Doe Sees

• Since GB2 and GB4 are applied, the grid is Read-only for John Doe because:

  • GB2: Read-only, matches the conditions perfectly.

  • GB4: Also Read-only and matches the conditions, but it applies to a wider group (Everyone).

Conclusion: John Doe can only view the grid (read-only), and the system adapts dynamically to his user role and the issue's status.

View Recent Failed Audit Logs

1. Open the "Recent Failed Audit Logs" from the "Grid Behaviours" tab by clicking button.

2. Review conflict and error logs. View details by clicking “Show more” button.

a. Not applied grid behaviour:

A grid behavior will not be applied if either of the following conditions occurs:

• User who opened the issue including this grid isn’t in Restriction of this grid behaviour.

• Or the issue opened by user doesn’t satisfy Condition of this grid behaviour.

b. Conflicted grid behaviour:

A grid behavior will conflict if the following 4 conditions occur simultaneously:

• The issue opened by user sastifies Condition of this grid behaviour.

• User who opened the issue including this grid is in Restriction of this grid behaviour.

• This grid behaviour isn’t applied.

• Attribute of this grid behaviour is different from the applied one.

Feedback and Support

For more information, visit our Support Portal here.

Conclusion

The Grid Behaviours feature empowers administrators to control grid content access efficiently by defining restrictions based on user roles and issue statuses. With intuitive configuration options and robust monitoring via the Audit Log, this feature ensures that editing permissions align with organizational requirements while resolving conflicts through a clear prioritization hierarchy.

By leveraging this feature, users can streamline grid management while maintaining precise control over who can edit content and under what circumstances. This functionality is designed to reduce complexity and enhance productivity within your organization. We encourage users to explore the "Grid Behaviours" tab and customize access rules to suit their unique workflows. If you encounter any challenges or have feedback, our support team is available to assist and improve your experience further.