Is there an "inexpensive" way to get the project area name during a Participant (from a work item)?
I have a participant that I want to use for multiple project areas. The logic is identical but the attributes available and IDs are different so having a single participant helps for maintenance.
So one of the first things I need to do is switch based on the project area. Right now, I am using the UUID by doing this: IProjectAreaHandle ipah = newWorkItem.getProjectArea(); String projectAreaId = ipah.getItemId().getUuidValue(); and then checking projectAreaId.equals(literal of my project area UUID) However, this causes me grief going from Jetty (local testing) to pre-prod, and into production, since all of the UUIDs is different. However, the project NAME would be the same in all 3 cases (in my situation). Is there an inexpensive way to get the project area name? It isn't available in the Handle (that I am aware of) and since I do this *alot*, I don't want to have an expensive/time consuming call. Susan |
Be the first one to answer this question!
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
My best guess is you have to resolve the handle. You can resolve it with a profile that contains only the Project area name to limit bandwidth usage.
Did you try
IProjectArea projArea = (IProjectArea) teamRepository.itemManager().fetchPartialState((IAuditableHandle) ipah, collection, monitor);
with collection containing IProjectArea.NAME_PROPERTY_ID
?
I would assume this would get you a lean solution with just the name so you can retrieve it from projArea.getName()
again, I would design this to NOT do this lookup every time.
use the names one time to get the ID. then compare ID's in memory during runtime.
1 time database lookup will be a LOT longer pathlength than any other work you need to do.
I would use a hashtable. if its empty on participant entry, use the configured project area names to populate the hash table with the their IDs.
then during run use the id to get the important switch value from the has table.
so the overhead is just once. and you can tune a hashtable lookup algorithm if u need to .. but probably wouldn't.