When you have items linked from JIRA to AHA (example STORY->FEATURE, EPIC->MASTER FEATURE), the items deleted in JIRA should be deleted in AHA
We intentionally do not delete any records based on updates from integrations.
The reason is very simple: there is too much risk of users inadvertently deleting data, especially when they are just getting started. For example, if you send all of your records to Jira and then decide you do not want them there and delete them, this would delete them in Aha! -- which is probably not what you wanted.
If you want to follow the Aha logic the integration-data should be updated.
Reason given sounds to me more like a deflection.
what makes more sense:
If Jira Ticket is deleted, remove in Aha the integration link.
or clean delete
Agree, one of two things would make sense to add:
1) Admin option to allow this for those orgs OK with the risks invloved
2) Clearly distinguishing the objects in Aha that have been deleted in JIRA/TFS to let the user know that extra follow up might be required. Also to be able to pull all of these items uniquely out in a report.
If Aha gets a notification from Jira that the story has been deleted, it would be wonderful to have a record of this, potentially doing some of/all of:
Removing the Jira link
Setting a tag or other field
Triggering a comment
Setting a state
Basically… something to help people working in Aha know what's going on without manually reconciling the two systems.
I also disagree with Aha! on there approach. As customer I want to manage my risks, and be dictated to on how I manage my project processes. As result this add more overhead as I have to implement a complicated manual process to delete a record. There should be way to choose if you want Aha to delete the record is its deleted in Jira.
I agree with Carlos... this argument does not hold. We use Azure DevOps and Aha!. Some people clean up features in Azure DevOps, sometimes in Aha!. If a story or epic is deleted in one system it must reflect in the other.
I'm just getting started with Aha!, and for a tool that collects ideas it just plain wrong that you mark something important like this as "Will not implement". Don't take ideas so literal, find out what is the root problem. and solve that problem.
E.g. as a minimum, you must make a feature that makes it possible to find all features & epics in Aha! that is no longer linked to Azure DevOps and allows for manual bulk delete. Or you might make a feature that disables unlinked features & epics and require reactivation to allow continued work.
At least move it to "Future consideration" or even "Unlikely to implement" instead of turning the idea flat down :)
That is argument is lame. If someone deleted in JIRA then we should reflect it in AHA.
We have a feature that is syncing both systems except for some conditions.
If you want to avoid it, at least implement the feature with an "option" to update on DELETE.