Clarity

Hi,
On our project records, we have 2 OBS linkages that we call Benefiting Group and Executing Group.  The Benefiting Group the Department OBS and the Executing Group is the Operating OBS (renamed to make sense to our people).

I would like to be able to filter by Project Department OBS and/or Operating OBS on the Status Report Listing portlet, so that a manager can see "all status reports for projects in the X group" for example.  Out of the box, this doesn't seem to be possible.  I have a couple of ideas for how this might work conceptually, but I'm not sure what direction to go in:

1) Try to update the query (or more likely make a copy of the portlet and query and edit those so as not to mess up the out of the box stuff) to pull in the OBS information from the project record.  I took a quick look at this but it's a little difficult because the OBS fields aren't discreet database columns.

2) Create two hidden or read-only attributes on the status report for Benefiting and Executing.  Then create a process that copies the values from the Project to the Status Report on create.  This is kind of like manually creating virtual attributes I guess.  I tried to create them as actual virtual attributes from the master object but they weren't available to select.

Any thoughts on how to proceed with this?  The Core requirement is to be able to filter by project OBS on the status report level.

Personally I would take a copy of the portlet/query and code in two user-parameters for the 2 different OBSs - i.e. your option 1 - the logic to walk-down an OBS structure looks a bit ugly but is relatively easy once you get the hang of it - some (very old) discussions on how that NSQL code would work here ; OBS (Units and descendants) Project NSQL Options

(worth a quick note to say that the way that we can associate OBSs with objects changed a little in a recent release (13.2/3?) and I'm not up-to speed on any data-model differences that that might entail).

Your option 2 would work too, just seems a little over-engineered for what you are trying to do.

Thank you David!  I'll look into what you've linked.  The second option was more an alternative because I couldn't figure out how to write the code, but hopefully this helps.

Hi Clare. I agree with Dave - building an NSQL portlet with your OBSes is the best approach today.

Similar to you we run two OBSes as well (we call ours Executing and Requesting). Our PMs love their Object based Status Report portlet they can do direct updates in, but again, like yourself we really wish we could get to the 'Parent OBS' (the Project's OBS) in this portlet (as well as all other sub-object portlets!) to easily apply OBS filtering. To get your voice heard for getting this in the box, please vote up the idea Major Parent Investments & OBS on Object Based Data Providers.

Thanks!

Voted!  Your writeup completely gels with my issue above; we would really benefit from that enhancement.  My above issue is just one application of where it would be useful.  Thanks.