EWM 7.1 - HTTP Filtered Value Set Provider for Project-specific attributes
Hi,
I'm curious about how I could use the HTTP Filtered Value Set Provider to provide project area specific values for certain attributes.
We use one project area as a central shared process area, but we want the ability for individual projects to have some level of customisation... for example a Project A might have a list of key clients or stake holders and we want to be able to attribute work items to those project specific stake holders which are different to the stake holders in Project B.
So let's say that I have two project areas which are both using a shared process from a "Master" project area. Let's call them PROJECT A and PROJECT B.
In the master shared process area, I create two attributes both of type "Category" (see note 1 below), lets call these attributes "Stakeholder" and "Charge Code" which should have project-specific values to select from.
In PROJECT A, I could have two top level categories, one called "Stakeholders" and another called "Charge Code" and then I add project specific values underneath them...
Stakeholders/Client 1
Stakeholders/Client 2
Stakeholders/Supplier 1
Charge Code/ABC123.01
Charge Code/ABC123.02
I do the same for PROJECT B but use different values...
Stakeholders/Client A
Stakeholders/Client B
Stakeholders/Supplier A
Charge Code/ABC321.01
Charge Code/ABC321.02
I want a value set provider that uses the categories from the Project area where the Work Item is being created to show a filtered list of "Stakeholders" or "Charge Codes"... So for example, if I create a work item in PROJECT A, when I go to select the "Stakeholders" attribute, I only see "Client 1, Client 2 and Supplier 1" as options. In PROJECT B, I only see "Client A, Client B and Supplier A" as options.
Selecting the option saves the category value to the attribute.
I have tried testing a HTTP filtered value set using a REST API call...
https://{our server}/ccm/rpt/repository/workitem?fields=workitem/category[projectArea/itemId={projectID}]/*
How do I get this projectID into the query for the "XML data source URL" in setting up the value set provider?
How do I limit this to just the qualifiedNames that start with "Stakeholders"?
Do I need to do this with a script instead?
Will this work with attributes as type: category?
NOTE 1:
Technically, this could be a string but saving it as a category type has some benefits when it comes to having a hierarchy in a plan view, for example with group by "Stakeholder" for example.
NOTE 2:
I have already done everything here up to the filtered value set provider... and my work around at the moment is to use a "Default Value Provider" however, we have a lot of categories in some projects and at the moment, there isn't really anything that prevents a user choosing, for example, a charge code for the stakeholder attribute. It's a bit messy, but a filtered list using the PA's categories solves the problem, I just need to know how to do it.
2 answers
You can definitely do this sort of thing, but I'm still not 100% sure I understand your use case - specifically what attributes you want to populate?
If you use categories then they are going to appear in the Filed Against attribute, which may be a perfect way to classify your work items, but then that has implications in terms of Team Area ownership too.
Or are you saying you will create some sort of master list in one project area, and then get the data from there for other project areas and attributes?
Comments
Thank you for responding, I've edited my question for clarity
OK - you have a bunch of questions here!
- unfortunately you can't pass in the name or ID of the project when you use an HTTP Filter, for that you would need to use a Scripted Value Set
- I would use [projectArea/name=""] instead of ID for simplicity, but you're still stuck with getting that into your URL in the first place
- you can use workitem/category[starts-with(qualifiedName, 'Stakeholders/')]
- for this to work with category type attributes, you'd need to return the qualifiedName as the value, but you can display one thing and return another
A better approach, given you want to actually use the category as the Filed Against in order to work with plans etc., would be to either
- use a Filtered Value set to only show the Stakeholder level values for the Filed Against field, or
- make the Filed Against read only on the form. Then add a string field for Stakeholder, use the Filtered Set as above, and use a calculated field to set the Filed Against from the selected string value
In either approach, you would then use the selected value to pull the specific charge codes and create another filtered set for the charge code attribute
Hi,
I think your first option is what I'm after... but Iv'e tried several approaches but can't get them to work. How would you go about this?
The big problem with the first option is that you need to attach the Value Set customisation to the Filed Against attribute, which then means it then becomes the Value Set for all your work items, not just the one you want. This is why I ended up doing the extra step for option 2, because the calculated field customisation can check whether the custom attribute exists for that work item and just return what was selected if not.
But, for the first option, your value set would look like this:
XML Data Source URL: https://<server>/ccm/rpt/repository/workitem?fields=workitem%2Fcategory%5BprojectArea%2Fname%3D%22<project name in URL encoded form>%22%20and%20archived=false%5D%2F%28name%7CqualifiedName%29&size=200
Row XPath Expression: workitem/category[starts-with(qualifiedName, 'Stakeholders/')]
Column XPath Expression: ./qualifiedName|./name
Column identifiers: Qualified Name|Name
Entry Label Format: ${1}
The first column will be returned as the value but the second is displayed
AFAIK the HTTP Filtered value set needs to be defined in the attribute customization (add value set). You need to specify the xPath etc, so that the value set really works. I do not think the value set know about the project area and I am not aware you could customize it further in other project areas, unless you overwrite the process inheritance for attribute customization.
