| Info |
|---|
Release Notes: Grid Behaviours - v ? Release Date: January 4th, 2025 This release document provides a detailed overview of the new Grid Behaviours Feature, outlining its purpose, functionality, and key benefits. |
| Table of Contents | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
Idea: Provide Behaviours of using/displaying grid/grid's columns based on different conditions. The feature should add a lot of flexibility to the grid. Grid can change its view and behaviour Grid Behaviours feature enables restrictions on editing grid content based on user group and environment. It will cover so many use-cases and our customers' needs.
A part of Roadmap 2024 Q4 - 2025 Q1
🎯 Goal: Enable restrictions on editing grid content based on user group and issue status to facilitate a simplified first-release Minimum Viable Product (MVP) for managing editable and read-only access within gridsissue 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.
Example:
Input:
Output:
Key Features
Step-by-Step Migration Process:
A new, detailed UI guides users through the entire migration process, explaining each step and outlining all prerequisites required for a successful migration.
Progress Tracking
The migration process now features clear step indicators within the UI, allowing users to easily identify their current position in the workflow at all times.
Simplified Authentication
Authentication between Jira Server/Datacenter and Jira Cloud is streamlined with a user-friendly interface, including fields for:
Jira Cloud site URL
User email for migration
Protected authentication token for Jira Cloud.
Improved Grid and Column Mapping
A dedicated UI allows users to easily map source grids from Jira Server/Datacenter to target grids in Jira Cloud. Users can select source and target grids via checkboxes and map columns with matching data types.
Support Contact Integration
A direct link to the Table Grid support portal is now available, making it easy for users to ask questions or seek help during the migration process.
Real-Time Error Notifications
Users can monitor live logs and view detailed error screens to diagnose issues during the migration process.
Migration Progress Visualization
A progress bar is included to show real-time migration progress and provide an estimated time for completion.
Pre-Migration Review
Users can now review migration details before initiating the process, ensuring they are fully informed about the actions to be taken.
Instructions for Use
| Note |
|---|
|
Open Migration feature: Click Manage apps → Click Migration in Table Grid section
Step 1: Prerequisites
You will find all the necessary information and requirements needed before proceeding with the data migration in this step. Make sure to review this section carefully to ensure a smooth migration process.
TGNG apps installed on both Jira Server / Datacenter and Jira Cloud instances
All grids configuration must be manually exported from Jira Server / Datacenter instance and imported into the Jira Cloud site, or you can choose to create a new grid in the mapping screen.
All Jira projects and issues that are using grids from the source instance must already be migrated to the target Cloud site
→ You need to create corresponding Projects and Issues on your Jira Cloud (same Project Key and Issue Key)
All Columns in the Grid Config are made editable in the Jira Cloud site before running the script (can be changed after)
Click “Next” button at the right bottom corner to come to Step 2.
Step 2: Authentication
This is the crucial first step, where you authenticate and connect to your target Cloud instance. Ensure that all the information you provide is accurate and follows our guidelines to avoid any connection issues.
Field Name
Description
Your email account
The email account that you use for Jira Cloud
Your Instance Name
Part of Jira Cloud URL before the “.atlassian.net”
Your Jira API Token
Get it on https://id.atlassian.com/manage-profile/security/api-tokens
Your TGC API Token
Get it on API Tokens tab on Apps page/Table Grid section
Your User Name
The username that you use to log in Jira Cloud
When you filled in all above fields, click “Next” button to verify your Jira Cloud account and come to Step 3.
Step 3: Select Grid
Select Grid: After authentication, you can now select the grids you wish to migrate by selecting the corresponding checkbox. Multiple grids can be selected at once.
| Note |
|---|
The Single Select List/Multi Select List column type with Dynamic Options cannot be migrated to Jira Cloud. If your grid includes this setting, it will be ignored during migration. |
View Projects: Additionally, you'll see useful information related to the projects associated with each grid to help guide your selection by clicking on the number of projects on each grid.
When you complete choosing grids, click “Next” button to come to Step 4.
Step 4: Mapping
On this screen, you will begin mapping grids from TGNG Server to the target grids on Jira Cloud. In default, all selected grids have the option “Add new grid” which will automatically create a new grid on Jira Cloud with the same configuration and data as Jira Server, simplifying the migration process.
Mapping grids by selecting the target grid on Jira Cloud that is corresponding to the original grid from TGNG Server.
When you complete mapping grids, click “Next” button to come to Step 5.
Or if you want to adjust the list of selected grids, you can click “Back” to come back to Step 3.
Step 5: Review
Before the migration begins, you will be able to review your selected grids and mappings. You also can go back to previous steps if any adjustment is needed.
Additionally, the number of all warnings related to the mapped grids that could impact the migration process will be displayed in the “Warning found” section, let you be noticed necessary updates before proceeding with the migration.
For example, if you're migrating grids with different configurations between Server and Cloud, a warning will appear to inform you of this discrepancy, because you need to make sure grid configuration is the same between Server and Cloud.
Step 6: Migration Process
Here we go the migration run, in this screen, you can track the progress of migration by seeing the progress bar and also the remaining time until it finishes.
You can also have option to Cancel the migration before its progress is complete by clicking “Cancel” and then click “Yes” to confirm.
| Info |
|---|
Grids that were already migrated before the cancellation will remain on the Cloud and cannot be rolled back. Additionally, you can use the Retry button to continue migrating any remaining grids in Step 7 |
When the migration is finished, please click View Result button to come to Step 7 and see the result.
Step 7: Result
Once the migration progress is complete, you will be able to see detailed information, including the number of grids successfully migrated, any grids that failed to migrate. You'll also see the total execution time and overall migration status.
Contact: If you have any questions, click “Contact” button to contact our support team through
https://tablegrid.atlassian.net/servicedesk/customer/portal/1
Download: Additionally, you can click “Download” to download the migration log for further review if needed.
View failed grids: You can view the list of grids that failed to migrate, along with the specific reasons for failure.
Retry: If you cancelled the migration in Step 6, you can use the “Retry” button to continue migrating any remaining grids that have been cancelled migration.
Click “Finish” button to finish the current migration and then go to Step 8.
Step 8: Success
When you finished each migration, you can decide to continue to migrate or not. If yes, you will go back to Step 1 to start a new migration.
Grid Configuration UI Update
A new "Behaviours" tab is added to the grid configuration interface for managing editing behaviours.
Add New Behaviour Button:
A button labelled "Add new behaviour" allows users to create and configure grid behaviours. Clicking opens a form-based popup.
Behaviour Configuration Form:
Element Input: Pre-selected as "Grid" and can not be changed.
Attribute Input: Choose between "Editable" and "Read-only", affecting all grid columns.
Condition Input: Define conditions using "Issue Status", specifying statuses like "Open", "In Progress", and "Closed."
Restriction Input: Select who is affected by selecting "Everybody", specific "Users", or specific "Groups"
| Info |
|---|
Sub-options for "Users" and "Groups" allow multi-selection from available lists. |
Audit Log Monitoring:
Tracks behaviour logs with a focus on conflicts and errors. It displays:
Failed/conflict logs.
A success count (e.g., "Number of success runs: 61").
Automatic cleanup of logs older than 24 hours (daily at 00:00 UTC).
Logic to Apply Behaviour:
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.
Conflicts are flagged when overlapping rules exist, with earlier-created behaviours taking precedence.
Instructions for Use
| Note |
|---|
Add Grid Behaviour
Step 1: Accessing Grid Behaviours:
Navigate to the grid configuration interface.
Select the "Grid Behaviours" tab.
Step 2: Adding a New 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 the Behaviour:
Name Input: Enter your Grid Behaviour’s name
Element Input: Pre-selected as "Grid" (default) and you can not change it.
Attribute Input: Choose between "Editable" or "Read-only".
| Info |
|---|
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. |
Condition Input: Select "Issue Status".
Issue Status Input: Select applicable statuses (e.g., "Open," "Closed").
| Info |
|---|
You can select multiple issue statuses for each behaviour. |
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.
| Info |
|---|
You can select multiple users. You can type characters in the “Select Users” fieldto search for users. Especially, you can type “@” in the “Select Users” field to show all the active users in your organization as selections in the dropdown list. |
6.3 Groups: Apply the access of this grid behaviour to all users in the selected groups.
| Info |
|---|
You can select multiple groups. You can type characters in the “Select Groups” fieldto search for groups. |
Click "Save" to save the grid behaviour configuration.
After saving, the new grid behaviour will be displayed on the Behaviours List.
Monitoring Behaviour Logs:
Access the "Audit Log" from the "Behaviours" tab.
Review conflict and error logs.
Success run counts are displayed for verification.
Feedback and Support
For more information, visit our Support Portal here.
Conclusion
The new Migration feature is designed to streamline the transition from TGNG Server/Datacenter to TGNG Cloud by providing a user-friendly, built-in interface that simplifies the entire process. With this intuitive solution, you no longer need to depend on external tools like Script Runner, making the migration experience faster and more efficient. By automating most of the workflow, this feature significantly reduces the complexity and effort required, allowing you to focus on other priorities.We encourage all users planning a migration to explore this new feature and experience firsthand the benefits of a seamless, efficient migration process. Make the switch to TGNG Cloud with confidence, knowing that our solution is built to make this transition as smooth as possibleGrid 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.