Skip to Main Content
Status Unlikely to implement
Categories Releases
Created by Raymond C
Created on Jul 10, 2020
Merged idea

This idea has been merged into another idea. To comment or vote on this idea, please visit APP-I-1741 Add Admin Ability to "Lock" the Features Assigned to a Release.

Lock unshipped releases to restrict everyone (including owner & contributor) from editing the release Merged

Idea: Lock unshipped releases to restrict everyone (including owner & contributor) from editing the release

Potential solution: Password lock releases that have finalized scope, timeline, and resources (users can choose when they want to lock the releases)

  • Only people with password can unlock the releases to make edits (assuming they received change request for the release)

Alternative: A new permission level where user with the permission can edit releases after releases are locked

Objective: Limit edits of releases that have feature locked down to avoid change scope/timeline during execution of the releases, which resulted in issues on resource allocations


  • We need this feature because we're using Aha as our primary location to determine product requirement/scope, deadline, and resources

  • If confirmed releases are not locked, contributors/owners may

    • Accidentally changed content of the release, which requires additional resource to fix the error

    • Made the changes without confirmation from all parties, resulted in miscommunication and setting wrong expectations for the releases

  • I understand shipped releases can not be edited, however shipped releases mean the product is complete and will confuse internal users

Thank you,

  • Admin
    Julie Price
    Jul 10, 2020

    Thanks for the idea!

    Currently, you can monitor changes to a release and its features through various channels, such as notifications and slack integration.

    With this in mind, we're unlikely to make changes in this area as we feel that this is an action which can be taken offline to enforce that product owners should not make changes to releases after sprint planning meetings. I hope you can understand.

    However, we will continue to monitor this idea for community feedback.