RELATED IDEAS
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 RESPONSEFeb 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.
3
MERGED
Update the ID of a Feature or Requirement when you change the Release it is associated with
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 from a...
0
Future consideration
7
MERGED
If a feature is moved to a different product, then it should inherit that product's prefix
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...
1
Future consideration
2
MERGED
8
MERGED
4
MERGED
Update Record Key when moving across Product
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 confus...
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
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...
0
Future consideration
© 2024 Aha! Labs Inc.•All rights reserved
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 ;).
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 ;).
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.
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
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.
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.
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?
Ideally changing feature Id would update links. Jira works in similar way if you change project, the key and associated links are updated.
Or at least we should be able to update the feature ID manually...
Apparently, it works when you copy a full release, but not when you duplicate a feature on its own.