View item's folder name in Grid View?

Jonathan Andree
edited September 2016 in
Is there a way to display an item's folder name along with the item in a grid view?

When using a hierarchy of sub-folders, if I view the top-most folder to see all items I lose the context of what folder each item is in. I have worked around this by adding a Context field to the item type, but then I have to edit the value.

Comments

  • Kristina King
    edited June 2016
    Hi Jonathan! You probably figured this out, but there isn't a way to view the location of an item in List View. The only hierarchical signal you can enable in List View is the Heading.
  • swoo Woo
    edited September 2016
    Kristina is correct. However, at our company we have an expensive workaround involving a script that runs once a day to populate a folder path field.
  • Jonathan Andree
    edited June 2016
    Thank you for the responses. Are there plans to add such a feature?

    I do have a workaround using a field and batch edit. The issue is remembering to update the data and training other users. It would certainly be better if this were built into the system.

  • Bob Dilly
    edited September 2016
    Hi Jonathan-

    I've wanted this information at times as well, but I've generally tackled it in an Excel export.  As Kristina points out, the header is close to what you want I believe, and I've leveraged that in Excel.

    Part of the "trick" I used was to write a filter that lists both the item of interest and the folders in a project.  I believe if you sort on heading (often the default), as you scroll through the list you'll see the folder(s) before the content of each.  Of course if each holds many items, or the tree is deeply nested you're signing up for a lot of scrolling and possibly paging ... at it doesn't concatenate the whole path of course.**

    Have you seen the "Find Me" function?  It is described in the online help for Item Functions, about a third of the way down.  I've shown it to some surprised users who hadn't noticed it on their own.  If the user just wants the context for a particular item or two, this works well.

    Hope there's some value here as workarounds...
    Bob

    ** In Excel a lookup was done on the header notation to, in effect, render it as a "path."
  • Jonathan Andree
    edited June 2016
    Thanks for the tip. I had not noticed the Find Me option. That is great.

    I am fine with the workarounds and tricks. They work for me. I am trying to get adoption from a wider user community and I know those users will not use the workarounds.
  • Bob Dilly
    edited June 2016
    I usually think about Jama users as falling into one of several categories:
    1. Casual users - typically consumers of Jama data
    2. Testers, BAs, reviewers
    3. Project Leads
    4. (Organizational) Administrator
    Each level needs to know more about the working of Jama.  The dashboard is the main entry point for casual users as I think about it, but as they drill into the detail behind the charts, they get more into the second tier.  I'd like that to be less of the case than it seems to be practically.  A rich text widget on the dashboard can have a list of tips, or a link to a "Dummy's Guide" to Jama specifically for casual users.

    Hard problem in a way, to support such a wide range of users!

    Bob
  • Kristina King
    edited June 2016
    You said it, Bob. At its surface level Jama seems easy-to-use, but there enough complexities (and quirks) that it's hard to create help/tricks for the various tiers of users, let alone communicate workarounds.

    Jonathan, I'm curious about the importance of location. Why does it matter what container an item lives in? (I think the reason this isn't a field/isn't emphasized in Jama is that we assume that context is provided via Relationships, not location.) I would appreciate knowing more about your use case...I know our UX team is working on categorization and taxonomy, so this is a fitting conversation to be having right now.
  • Jonathan Andree
    edited June 2016
    A folder hierarchy gives a default relationship for free. An item's home within a hierarchy is a form of relationship - I would say the primary relationship. A good hierarchy yields a lot of information with minimal effort.

    Additional relationships (as built-into Jama) provide additional dimensions by relating to other structures and data types, but these relationships need to be created. 

    In this case we did a story mapping exercise. The top folder is for the June story mapping exercise. Sub folders are created for each high-level topic with a set of items in each. This allows me to point users to a specific topic without using a filter or have a user responsible to refine each folder. But if someone looks at the parent folder or we run a review, the context of each item is lost. I could run a review of each folder, but that is extra overhead. Or what I have done is add a field to the type called "context" and then I do a batch edit. 
  • swoo Woo
    edited September 2016
    Kristina, I agree with Jonathan. Another use case is when we allow enterprise re-use within the same project. We could have items that have the same golbalID that live in multiple configurations/folders. Having a folder path allows us to see the hierarchical relationship more easily.
  • Kristina King
    edited June 2016
    Jonathan, thanks for spelling that out for me! It makes sense.

    Swoo, good call. I hadn't thought about how hierarchal designations impact reuse.
  • Bob Dilly
    edited June 2016
    My $0.02 from a test management perspective ... IF the hierarchy / tree reflects the architecture of a software project, and you know only a small lower-level function/feature or two were changed, you could focus testing on one or two sub-trees of test cases ... at least initially.  Of course you can do that in test group creation or with filters.  But the hierarchy does carry information in my experience.

    Indeed, when we evaluated Jama, we were concerned that the test case hierarchy was flattened when creating a cycle (which I think has been mentioned in other threads).  It might be the one thing we gave up in the tool we migrated from, so it garnered a lot of discussion.

    Bob
  • I too would like to be able to have a "Location" item field in List View(s) that automatically populates to show the hierarchy of folder(s) where the item(s) are located.  Just like at the top of an individual Item (See highlighted below).

    Example of Folder Hierarchy "Location"

    In our case, the folder name(s) indicate the requirement Subsystem/Module/Component location. This location is very helpful when relating Tests to Requirements. 

    It would make it so much easier to relate if the List View could show the Folder Hierarchy without having to open each item.
  • I end up making very long test case names that partially replicate the hierarchy. Otherwise, when executing a test cycle, I can't easily gather the related test cases so that I'm not jumping from one thing to another unrelated thing. So, this would be very helpful.