Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
History - Modification history and restoration
Overview
The Changes History & Restoration feature provides a robust way to track and manage modifications within the Requirement Yogi application. This feature enables users to view a detailed history of changes, monitor modifications over time, and restore specific items to previous states when needed.
💡Quick tip:
Key features
1. View change history
Users can access a comprehensive history of all modifications. This history includes information about each change, such as:
Who made the modification
What changes were made
The date and time of each modification
2. Restore to previous state
Users have the ability to revert items to a specific date in their history, allowing for targeted restoration of data to address errors or revert to previous configurations.
3. Single item restoration
Rather than having to roll back entire changes, users can select specific items to restore, offering a quick, precise correction without impacting unrelated data.
Scope and types of tracked changes
The change history feature tracks changes both in Requirement Yogi for Confluence and Requirement Yogi for Jira.
Tracked items are:
Linear document configurations
History retention duration
Change records are retained for 1 month during the BETA , ensuring users can reference past modifications when needed. After this period, it is automatically deleted. The retention period will be extended in the future.
How to use ?
The history is accessible in the Management tab.
View change history
| |
To make it easier to find specific records, the history feature includes flexible filtering options. Users can narrow down the history list by selecting from various filters, allowing for quick access to relevant changes without searching through the entire log.
Key filtering options include:
Key or name: Quickly find the changes associated with a specific item or identifier.
User : See changes made by a particular user, making it easy to review contributions or investigate specific modifications.
Type of change: Filter by the type of modification, such as updates, deletions, or updates.
Item type: allows users to narrow down the history list by the specific type of item that was modified. This filter is helpful as different types of data or objects are tracked such as:
Linear document configurations
Saved matrices (Traceability matrices and Modification matrices)
Date Range: Limit results to changes made within a specific date range to focus on recent modifications or historical periods of interest.
Variant and status: Only available for requirement items.
Restoring a single item
In the history list, a restore button is available for each item that can be restored.
Requirements cannot be restored from the history list because they are defined in Confluence pages. To restore requirements, re-index the corresponding Confluence page version.
Restore to previous state
Users have the ability to revert items to a specific date in their history, offering a precise and efficient way to manage data restoration. This functionality allows users to "roll back" any item to an earlier state, addressing unintended changes or errors. By selecting a specific date, users can restore an item’s configuration as it was at that time, avoiding the need for manual adjustments or extensive re-entry of data.
This targeted restoration feature is particularly useful in situations where data consistency is crucial, such as recovering from an accidental deletion, correcting a batch of incorrect entries, or reverting configuration settings. Each restoration action is also recorded in the history log, ensuring that the rollback is fully traceable and documented.
| |
| |
Permissions
Users have access to the resources they created and can restore them. They can also view the history of data they have read-only access to, but they do not have permission to restore it. To access a history item, a user must have at least read permissions.
Frequently Asked Questions
What is the difference between the History, Baselines and Variants ?
Think of the history as a line, it follows the lifecycle of your requirements. It lets you track each modifications made on requirements, and who made them.
Baselines represent a frozen state of requirements in their lifetime, marking a released version for example.
Variants are branches of that lifetime, letting you manage both lifetime in parallel.