Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

Release Notes: Grid Behaviours - v2.5.0

Release Date: January 6th, 2025

This release document provides a detailed overview of the new Grid Behaviours Feature, outlining its purpose, functionality, and key benefits.
It aims to help users understand how the feature facilitates editable and read-only access management within grids. It includes step-by-step instructions for using the feature, and highlights any technical dependencies or requirements.
By providing this information, the document ensures smooth adoption and integration of the Grid Behaviours Feature into existing workflows.

Overview

(lightbulb) 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.

image-20241224-101719.png

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)

In the current version, Grid Behaviours are not supported for team-managed projects; they are only available for company-managed projects.

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.

image-20241224-041901.png

Step 2: Adding a new Grid Behaviour

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

image-20241224-042013.png

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

image-20241224-052638.png

Step 3: Configuring Grid Behaviour

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

image-20241224-042619.png
  1. Element Input: Pre-selected as "Grid" (default) and you can not change it.

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

Editable: Users who have this access can read and edit the grid.

Read-only: Users who have this access can read and can not edit the grid.

image-20241224-042851.png
  1. Condition Input: Select "Issue Status".

image-20241224-043221.png
  1. Issue Status Input: Select applicable statuses (e.g., "Open", "Closed").

You can select multiple issue statuses for each behaviour.

image-20241224-043844.png

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

Logic to Apply Behaviours:

Behaviours enforce grid access permissions based on priority:
Individual Users > Groups > Everyone.

If a user is both individually editable and read-only as part of a group, the individual setting overrides the group restriction and everyone restriction also.

If two grid behaviours in a grid have the same restriction and condition, prioritize the earlier-created grid behaviour.

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

image-20241224-045721.png

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

You can select multiple users.

You can type characters in the “Select Users” field to search for users.

Especially, you can type “@” in the “Select Users” field to show all users in your organization as selections in the dropdown list.

image-20241224-050542.png

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

You can select multiple groups.

You can type characters in the “Select Groups” field to search for groups.

image-20241224-051902.png
  1. Click "Save" to temporarily save the grid behaviour configuration.

image-20241224-052229.png

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

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

image-20241225-100109.png

Apply Grid Behaviours to Grids

Example:

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

image-20241225-093753.png

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

Order by earlier created date

Name

Attribute

Issue Status

Restriction

1

GB1

Read-only

Todo

Groups (including John Doe)

2

GB2

Read-only

Done

Users (John Doe)

3

GB3

Read-only

In Progress

Users (Jessica)

4

GB4

Read-only

Done

Everyone

5

GB5

Editable

Done

Users (John Doe)

6

GB6

Editable

Done

Groups (including John Doe)

7

GB7

Editable

Done

Groups (not including John Doe)

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.

image-20241225-093950.png

Key Points to Remember

  • Behaviours are sorted based on Issue Status, Restriction, and Creation Date.

  • Conflicts are resolved by prioritizing the highest-ranked behaviour.

  • The system automatically adjusts the grid based on the user’s role and the issue’s context.


View Recent Failed Audit Logs

  1. Open the "Recent Failed Audit Logs" from the "Grid Behaviours" tab by clicking image-20241224-105137.png button.

image-20241224-104924.png
  1. 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.

image-20241224-104541.png

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.

image-20241224-110616.png

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.

  • No labels