Batch actions and refreshing should not collapse the explorer tree

Mike Donlon · June 2015

Hi,

I am using the Jama 2015.1 on-premise release and am running into a rather annoying issue.

As I imagine others would do, we take advantage of the ability to arrange records in a folder hiearchy in Jama. Sometimes the hiearchies end up being a bit deep.

As I browse through my hiearchy, I may see a couple of items which I want to delete. I go to the list view and check the items to delete, then go to the Actions menu and select Delete. Jama refreshes the List view, which is good, but then also collapses the Explorer view. Argh! Now if I want to get back to where I was, I have to re-open all the folders in the Explorer view that I was looking at! I know I can open an item from the List View and then go to Actions, Find Me, but that only opens the folder where that one item was... it doesn't open all the other folders I had open in the Explorer view.

On the other hand, if I go to the Explorer view, right-click one item, and select Delete, the Explorer tree is refreshed 'in-place'; the one item I deleted is removed and the rest of the structure remains open, the way I'd left it. The disadvantage is that I can only delete one item at a time.

Of course, the behavior I would expect is to have to be able to delete more than one item in the List View and to have the Explorer view update "in-place", without collapsing back down to the root level.

Thanks,
Mike

[Deleted User] · June 2015

Mike, in my testing the behavior is the same between 2014.1 and 2015.1, so I wouldn't consider this a problem (by problem, I mean bug). Deleting a single item from list view in 2014.1 (via select and Actions > Delete or right-click Delete) will not cause the Explorer Tree to refresh. Deleting a single item from list view in 2015.1 (available only via select and Actions > Delete) will not cause the Tree to refresh. However, deleting multiple items in either 2014.1 or 2015.1 will cause the tree to refresh due to the invoking of a batch operation.

That said, I understand where you're coming from—when you use hierarchies as you do, it can be a pain to find the location in which you were most recently working. Having the entire hierarchy collapse isn't something users expect to occur after performing an action in what is seen as a separate view. For these reasons I'm going to change this post to an "Idea" so that we can consider it as an update to make, since it's not a bug. (But I definitely hear you on the inconvenience it causes!)

Mike Donlon · June 2015

Hi Kristina,

That is a fair point... the 2014.1 did behave in a similar way. Maybe it was a bit less noticeable because in 2014.1 the only way to delete more than one item from the list was to use the Batch Delete approach, which opens another window on top of the Jama UI. But if you get down to it, the behavior is the same.

Thank you for changing the post to an Idea!

Mike

[Deleted User] · June 2015

There were some feature requests in the old community around the collapsing of the explorer tree. I know we were tied to some of those requests as having to find your place within the tree after it collapses (based on action) is a pain, especially on larger projects.

Kevin Mote · June 2015

I've had the same frustration. One possible solution (that would alleviate at least some of this problem) would be if we could specify an "automatic tree depth" that the E. Tree will always display, even after a refresh. So, for example, I would like to be able to set Tree Depth to 3, so as to display 3 levels of branches in the tree by default (i.e, the Tree would automatically expand all branches down to that level). I just learned how to do this in the Atlassian Confluence sidebar yesterday. Would love to do it in Jama Explorer Tree too. (Ditto for the Review Center TOC)

(Should I submit this as a separate Idea?)

[Deleted User] · June 2015

Good question, Kevin. I think your suggestion helps numb the pain of losing your spot in the hierarchy, so for that, I think it ought to stay in this thread. I'm sure there are performance or efficiency implications either way (e.g. if you had your tree display four levels of hierarchy, refreshing it could take a hit, but is that hit worth seeing where you were working? Probably so to many people.) if we consider this a separate idea.

But in terms of how we approach problems that customers have outlined, I think I'll keep this idea in this thread rather than branching it to a new one. We'll see the problem identified (losing the place you were working) and consider the shared "solutions" before coming up with the best one for the product. Identifying the pain is generally more impactful than just sharing the idea.

That said, thanks for sharing it—it's always interesting to know how other tools behave in similar situations, so thanks for bringing up Confluence.

Felix Knorr · January 2016

This reply was created from a merged topic originally titled avoid collapsing explorer tree when using the refresh button.

On refreshing
of the explorer tree via the refresh-button, all containers collapse. This behavior
requires many clicks to get the view from before clicking the refresh button...

When using the refresh-button, the explorer tree should not be collapsed.

[Deleted User] · January 2016

Hi Felix,
Thanks for sharing this Idea. I merged it with a similar one so we can better track demand. Ultimately it sounds like you would all like to see the explorer tree remain persistent after refresh or a batch action.

Brian Hair · February 2017

Echoing the frustration with the collapsing tree. We have users reporting trouble with this.

[Deleted User] · February 2017

Yep, me too. This is fairly reliably the first thing that new users I bring into the Jama fold will complain to me about.

[Deleted User] · February 2017

+1. Collapsing tree drives me crazy. I do need it to refresh automatically though.

Tom Green · April 2017

Our users are also frustrated with the currently implemented behavior. Please find a way to retain expanded tree structure through the various actions that tend to collapse it (like re-use, edit, etc.)

[Deleted User] · June 2017

Another vote for this change here. I've only onboarded a few people to Jama and, less than a week in, this is the #1 complaint.

[Deleted User] · June 2017

Our users also report collapsing trees in the project explorer being highly inconvenient in several scenarios.
We would wellcome such fix in Jama too.

[Deleted User] · June 2017

+1 (*50% of our user base)

[Deleted User] · June 2017

I also would prefer that the trees do not collapse.

Randy Dahlgren · June 2017

In general there are way to many clicks to get things done. Deleting and moving things resulting in the menu collapsing each time costs a lot of time and frustration. We get annoyed with the tool which takes our focus off the task at hand. Anything that can improve work flow around the tool would be GREATLY appreciated.

Cheers!
Randy

Tom Green · February 2018

In recent Jama versions, there seems to be an improvement to this behavior.

The following no longer collapses the Explorer tree:

Batch edit items in list view.
Batch transition items in list view.
Duplicate.

The following still collapses the Explorer tree:

Re-use item.
Drag-drop move item. Collapses originating location; expands destination.

Thanks for the improvements.

Batch actions and refreshing should not collapse the explorer tree

Comments

Categories