Skip to Main Content
Status Future consideration
Categories Features
Created by Guest
Created on Jul 8, 2015

Update Feature ID when moved to another product

When you create or copy a feature, its ID is automatically created based on the product code. The ID is a combination of the product code and an auto number (and that is perfectly fine). But when you change the release reference to a release of another product, the feature ID should get a new ID, based on the new product it is attached to. Otherwise, it is confusing when looking at a release or any report/view for people who are across multiple products - features from 1 product seem to belong to the wrong product.

  • ADMIN RESPONSE
    Feb 19, 2016

    Thanks for the note. We can understand potential confusion when looking strictly at the Feature ID but this is done for good reason.

    If the Feature ID were to be changed, this would break any existing links to the feature (from emails, integrations, etc.). In order to keep all links working properly and to ensure traceability, the Feature ID will need to remain the same.

  • Attach files
  • Guest
    Reply
    |
    May 1, 2020

    I recon it would be more appropriate to say "the RoI for this request is not aligned with our strategy". FWIW, what everyone (I believe) is asking, is to change the label that represents a feature ID ("CAT-55"), not the real feature ID in your database (which surely, is not exposed to users, and rightfully so).

    If you built your database properly, which I'm sure you did, you will find that there is a unique internal identifier that is not meant for human or external consumption. The label we see ("CAT-55") is just a label that is manipulated by your application logic.

    That idenfier should never change. All that needs to change is that label. Changing the label should impact no relations to other constructs. Granted, that's not a zero effort.

    If you did build your database around labels then this one is the least of your problems ;).

  • Guest
    Reply
    |
    May 1, 2020

    I recon it would be more appropriate to say "the RoI for this request is not aligned with our strategy". FWIW, what everyone (I believe) is asking, is to change the label that represents a feature ID ("CAT-55"), not the real feature ID in your database (which surely, is not exposed to users, and rightfully so).

    If you built your database properly, which I'm sure you did, you will find that there is a unique internal identifier that is not meant for human or external consumption. The label we see ("CAT-55") is just a label that is manipulated by your application logic.

    That idenfier should never change. All that needs to change is that label. Changing the label should impact no relations to other constructs. Granted, that's not a zero effort.

    If you did build your database around labels then this one is the least of your problems ;).

  • Guest
    Reply
    |
    Jan 29, 2020

    This seems like a pretty weak response.  If you treat the feature ID as an attribute and decouple the unique identifier of the item in the back-end from the label, you'd be able to maintain links while supporting this idea.

  • John Barry
    Reply
    |
    Dec 13, 2019

    Because this doesn't update, I have to reject the feature and copy it and start a whole new feature under the other product.  This should be handled better by AHA

  • Guest
    Reply
    |
    Jun 24, 2019

    The admin response to this should say "This is a shortcoming of the way it's currently implemented, we can't change the feature id because we directly use it for links".  As pointed out by other commenters, other products do this and so can aha, you just need to change the way you're using the ids so that linkages don't depend on something externalized, like feature IDs, and instead rely on internal ids that you manage behind the scenes.

  • Guest
    Reply
    |
    Aug 14, 2018

    The admin response above is not justification enough. Other systems support redirects (Salesforce, JIRA, etc) and update IDs when moving between backlogs/queues/etc. 

    Not updating the ID leads to inaccurate reporting & ownership confusion. 

  • Guest
    Reply
    |
    Apr 3, 2018

    Dear Admin: you could do like JIRA internally does and keep a history of the old values of the ID that points to the same feature. Then it would not break integrations right?

  • Guest
    Reply
    |
    Nov 30, 2017

    Ideally changing feature Id would update links. Jira works in similar way if you change project, the key and associated links are updated.

  • Florian Leray
    Reply
    |
    Nov 10, 2015

    Or at least we should be able to update the feature ID manually...

  • Guest
    Reply
    |
    Jul 8, 2015

    Apparently, it works when you copy a full release, but not when you duplicate a feature on its own.

3 MERGED

Update the ID of a Feature or Requirement when you change the Release it is associated with

Merged
Overview At the moment the way IDs are managed in Aha! is not dynamic like it is in JIRA. Backgorund If you move a bug in JIRA to another Project, the key is updated when the issue is moved and JIRA keeps track of where the issued has moved fro...
Guest about 7 years ago in Features / Releases 0 Future consideration
7 MERGED

If a feature is moved to a different product, then it should inherit that product's prefix

Merged
If a feature is created in one product and then moved to another (let's say the person created the feature against the wrong product), then the feature does not inherit or change to that product's prefix. This not only looks strange but is confusi...
Guest over 6 years ago in Features 1 Future consideration
8 MERGED

If you move a feature to a different product, why can't the feature become the next number in that products sequence?

Merged
Less confusion. Keeps things consistent. Less work to delete the feature and recreate it in the proper product which may not always be possible.
Guest over 6 years ago in Features 0 Future consideration
2 MERGED

Enable Epic reference numbers to be renamed

Merged
I want the ability to move an Epic from one workspace to another and need the Epic to adopt the Epic reference # prefix for the workspace I'm moving it to. Or I'd like the ability to rename an Epic's reference # prefix
Lou Giambalvo almost 4 years ago in Application 1 Future consideration
4 MERGED

Update Record Key when moving across Product

Merged
It's very confusing when you move a record from one product to another but it still keeps it's old key. If the ticket is in a new product/queue, the key should reflect that. Every other development system I've used does this. ie.: It's very confu...
Guest over 5 years ago in Features 0 Future consideration
3 MERGED

Need a way to move a feature from one workspace to another and have the prefix change to the new feature

Merged
When entering features, we are running across times that the ticket is put into the wrong workspace. It would be nice to have a way to "move" the feature to the correct workspace that will also change the prefix to the new workspace. Currently, we...
Jennifer Lange about 1 year ago in Features 0 Future consideration