Product Idea

Expand all | Collapse all

Synchronization doesn't handle deleted items

Kristina08-27-2015 14:11

  • 1.  Synchronization doesn't handle deleted items

    Posted 03-16-2015 14:18
    We have a use case where we desire viewing multiple projects in a single view (for traceability between projects).  To solve this, we created a master project in which we synchronize multiple projects to.  

    Any time we make changes to a project, we then synchronize that project with the master project.  This works fine for changes and additions, however if we delete an item, Jama cannot appropriately synchronize.  It thinks that new items were created on the master project.  Jama should be able to recognize that the item deletion was more recent and propagate the deletion across the synchronized project.  This seems like a bug to me.



    I proposed this to support@jama.com and their response was as follows:
    the idea behind it is to prevent involuntary deletions and make sure that any deletion is a conscious decision.

    This still doesn't make sense to me.  If I'm synchronizing between projects, I'm making a conscious decision to have my projects mirrored.  This means that if I change something on one side, I expect the behavior to be the same on the other regardless of deletion, addition, modification, etc.  Jama provides the ability to revert changes, so why would this be a problem?  

    I'm wondering what the community thinks about this.  Does anyone else have this use case?


  • 2.  Re: Synchronization doesn't handle deleted items

    Posted 03-16-2015 16:12
    I don't have this use case, but your logic seems right on!  Completely understand what you are saying and the behavior you would expect or want seems valid since you are already making the conscious decision to sync and propagate the changes.


  • 3.  Re: Synchronization doesn't handle deleted items

    Posted 03-16-2015 19:59
    Container synchronization is a tough one.  We don't run into your case quite as much, but we do run into instances where we only want to sync some of the items in a set or folder into another project.  If you reuse the source project's hierarchy, you're left with a situation where the container is always out of sync even if that's what you intended to do.  And there's no way to clear that condition like you could with a suspect, so it's always on the out of sync radar.  The only thing we can do as a result is not use the source project hierarchy and only reuse containers if they can be reused in their entirety.  Different issue than the one you described, but it comes back to the challenges of container synchronization.

    In principle, I agree... it should be possible to delete items through sync.  But I'll also say that merge logic can get to be fairly complex behind the scenes, and I don't think the sync feature is doing a full-on merge.  The interesting thing here is that we know a container sync isn't using a brute force overwrite method either, since you can selectively add new items via sync.  Ultimately, it could very well be that the source and destination projects don't have enough info stored in the container to know how to reconcile the riskier or more complex merge scenarios.   Adding new items is inherently less risky than deleting existing ones (even if you can restore items), which may be why those work but not deletes.


  • 4.  Re: Synchronization doesn't handle deleted items

    Posted 03-16-2015 20:39
    Thanks Angela, Mark.

    Mark- I did run into your problem as well.  We had a few reuse items that we were sharing across multiple projects, however when I tried to synchronize full sets I encountered the same out-of-sync problems that you saw.  My solution was similar - just don't reuse those small items.

    There might be some complexity under the hood, but that's really for Jama to solve.  I feel like this could be much simpler if the concept of re-use was only applied in a pointer/reference fashion.  In other words, don't create a separate entity that constantly needs syncing - just provide the item as a reference.  This way, edits are made in one location and you never have to worry about merging, syncing, updating or any other 'ing'.  Deletions come just as easy in this case.

    All in all, I guess I'm just frustrated.  The end goal is really to be able to create a bird's eye view of the different projects I have - for traceability and project status perspectives.  It doesn't matter to me if it's achieved via syncing; perhaps that's not even the best approach to accomplishing my task - but as of now I don't see an alternative solution available.


  • 5.  Re: Synchronization doesn't handle deleted items

    Posted 03-18-2015 10:26

    I agree.  It’s a technically complex but solvable problem.



  • 6.  Re: Synchronization doesn't handle deleted items

    Posted 03-18-2015 11:01
    By having a single item 'entity' and pointing all sync'ed items to it you'd get an automatic update / ripple / cascade after updating. For some projects (like a master project) you'd want this, for others you might not. So this approach would need appropriate options for behavior.

    Each modification to an item bumps its revision number. I've just check our database and deleting an item also bumps the revision so syncing for a deleted item could work as requested.


  • 7.  Re: Synchronization doesn't handle deleted items

    Posted 04-01-2015 18:02
    Hi Mike,
    I wanted to let you know that I've been talking a little bit with my Product team about this particular quandary. From the sounds of it we have plans to provide a better cross-project view, however, that work is still in an early design phase so I can't tell you what it might entail, much less give you a time frame for it.

    What we're not quite grasping, though, is why you're using reuse and sync for traceability and project status. I can understand the technicalities of the issue—you expect deleted items to be removed from the destination when synced—but I'm not sure how this affects the bird's eye view, which is your ultimate concern.

    If you provide me some greater context to this they can understand the true issue you're trying to solve and will consider that when working on this area.


  • 8.  Re: Synchronization doesn't handle deleted items

    Posted 04-01-2015 18:49
    Hi Kristina, thanks for the response.

    In short, we need an interface between projects.  We presently have multiple projects, represented at different layers in our requirements hierarchy.  We want to have tracing between these layers, so we need a view where we can analyze everything in the same place.  This will allow us to: assess change impact analysis, update and review item traceability, etc.  

    When we first attempted to solve this problem, it seemed like the best way to accomplish this was through synchronization.  This is because the trace tree has no scope outside of its own project.  We don't really need a second copy of these items, we just need the reference to them - so that any changes that are made are reflected in the main project.  If there's an alternative way of approaching this, I'm open for it.  It seems like it's either sync all items in a all-project-view project or to keep everything in a single project, which is not an attractive alternative to us.

    Hope that helps clarify.


  • 9.  Re: Synchronization doesn't handle deleted items

    Posted 04-02-2015 17:10
    So your "bird's eye" project contains a copy of everything in your entire instance? At this point, what features do you use to manage traceability?

    The PM I was discussing this with asked why you wouldn't combine use of the Coverage Explorer with cross-project filters. I think the biggest road block with that is that the CE can be used only for downstream traceability, so if you want to see literally everything, you'd have to have some sort of master item that everything is related to. But if you were open to doing it by the main item types for traceability, it seems feasible. Creating a filter "All requirements" that pulls from All Projects and using it as the first column in the CE would allow traceability down to Test Cases. Of course, you have other important traceability pieces to consider you might have to utilize multiple save Coverage Explorer Views.

    We're interested in finding the best workaround for you in regards to this "birds-eye" view, and if we can't find a solution, at least we'll fully understand your needs. I think work on cross-project visibility is going to come before changing the behavior of Reuse & Sync.


  • 10.  Re: Synchronization doesn't handle deleted items

    Posted 08-27-2015 13:05
    I TOTALLY GET what you are trying to do here! I have the exact same scenario where we have a master project and reuse and sync back and forth from it.  We also need the ability to delete items in reused/synced projects and have those deletions reflected when syncing back to the master!

    I hope Jama provides this capability as well, as this will get very messy having to work between both!


  • 11.  Re: Synchronization doesn't handle deleted items

    Posted 08-27-2015 13:08
    Kristina, in regards to this original issue, we have the same need to be able to sync back to a master project and items that were deleted from the secondary project need to be deleted upon syncing back to the master.


  • 12.  Re: Synchronization doesn't handle deleted items

    Posted 08-27-2015 14:11
    Thanks for the added vote!


  • 13.  Re: Synchronization doesn't handle deleted items

    Posted 11-18-2015 20:14
    Yes, this messes with our expectations too.

    We're using reuse and sync to maintain copies of the same block of specifications in two different products. Because they share a block it's necessary that they share an identical copy at all times of the spec. So we've designated one as the master copy and one as the slave copy. Whenever we change a few things in the master we run the sync. A bit manual and cumbersome, but should work in theory.

    Deleting an item means that a feature will not be present in the implemented block, and this needs to be reflected in the slave. Right now it shows that the block is out of sync, but we can't do anything about it from the sync window, we need to go back to the slave block with a list of differences and manually do the deletions.

    It is really bothersome, especially as the ability to sync all changes shows so much promise for other types of changes. But often what you don't include is just as important as what gets included.

    We've considered using embedded links as a workaround, so instead of reusing the block we just have an item with a link "click here for all the shared stuff", but this really fragments the readability of the spec.


  • 14.  Re: Synchronization doesn't handle deleted items

    Posted 11-20-2015 14:07
    Ed, thanks for adding this color. "But often what you don't include is just as important as what gets included." is a really good point that can often be forgotten.
    I just saw the road map today and it's focused on expanding and enhancing coverage, baselines and traceability, so I don't think we'll see a change in Reuse soon. But I'm glad we're tracking these needs.


  • 15.  Re: Synchronization doesn't handle deleted items

    Posted 11-24-2015 00:19
    I would also find this functionality very useful -- quite cumbersome to come back and delete items in the "child" project by hand...


  • 16.  Re: Synchronization doesn't handle deleted items

    Posted 11-24-2015 13:54
    I hear you, Joe. Thanks for chiming in on this thread.


  • 17.  Re: Synchronization doesn't handle deleted items

    Posted 11-30-2015 13:58
    Since this is obviously a key need for users of Jama reuse, when can we expect this functionality to be incorporated?


  • 18.  Re: Synchronization doesn't handle deleted items

    Posted 11-30-2015 18:55
    It is not on the roadmap at this point, Maria. Our priority right now is improving traceability.


  • 19.  RE: Re: Synchronization doesn't handle deleted items

    Posted 06-23-2017 18:04
    Kristina, is there any progress on getting this feature on the roadmap?  I see this as a need for us.

    ------------------------------
    Jeffrey
    ------------------------------