Clarity

My question is,

If you create a portlet from a NSQL query, any fields you get from the query are not editable. Meaning when I place these fields in a portlet I cannot click on these fields and change the values. Is that correct?

Secondly I can do this with a portlet that is created from a object. I can then click on a field in the portlet and update that field.

My issue is I want to be able to create a grid portlet that I can update and have a calculated fields in the same portlet. I know you can create a calculated attribute but a calculate attribute within the object has limitations. I need to be able to do the calculation of two fields with SQL.

Is there a way of combining a object grid portlet and a NSQL grid portlet to have the best of both worlds. One of the calculations I am trying to create in my portlet is shown below. I don't think I can do this calculation in a object calculated attribute

Round(((eh.nlopecost - lag(eh.nlopecost) over (order by eh.id)) / lag(eh.nlopecost) over (order by eh.id)) * 100)||'%' OPEV_Cost

Any help would be much appreciated. (I am using Clarity PPM 13.3)

Thanks.

Hi Chris.

   Here's how we meet your requirements above. The limiting factor here is the capability of calculated attributes. Our solution is to use a GEL script to 'offload' the calculation to SQL/Java/GEL/ ...whatever one needs. Conceptually this can be applied to about anything.

Requirement: Editable Object based portlet with read-only attribute(s) to hold/display calculated values as a result of object(s) data, that can update, as appropriate, from changes to the calculation's source data.

Solution: Create a read only attribute, execute calculations via GEL & XOG data onto a read only attribute via process attribute update event.

   In the video below, Total Allocation is a custom read-only attribute. As the user changes data and saves, an update event process runs & does the necessary.

Pro: On-Premise & On-Demand Safe.

Con: User has to 'refresh' to see the result.

   GEL script in the example above is here. Conceptually this can be applied to about anything. Set an onChange event on any of the attributes in the calculation and when something changes run the script that does the math & sets the value. We originally tried this as an ACA but it didn't perform.

If I can dream...

• The limiting factor here is the capability of calculated attributes. Some kind of JSON/Java/Javascript/Groovy/...etc attribute would be awesome (if it performs, can persist & can handle calculation order).
• I'd love it if there was some OOTB ajaxy capability here to automagically refresh that enumeration, but until then this is the best supported solution I've got. 
• In the specific use case shown above I'd love to not have to do any of this. Please vote up Allocation Summary Data on Idea Object Data Providers.
• Always open to other ideas/solutions/enhancements.

   HTH,

      Rob

We use this appropriate for Risk Ratings which don't fit in the OOTB Risk Matrix.

Note though, if you have the 'read-only' attribute shown on an Edit screen, the process runs in the back-ground and updates the attribute (on the database).  However, if the user has the Edit screen open and makes changes and saves, the Edit screen will push back the 'read-only' attribute original value.  To resolve this limitation, we have use a calculated attribute (eg read_only + 0, if the attribute is numeric).  The calculated attribute is shown  on the Edit screen.  This has been reported to CA and still happens in V15.2, so we are still using the calculated attribute to resolve this issue.

Great solution Roland. Yes, read only 'destination' attributes are needed. Please vote up Allow Null Read-Only Attributes to simplify this for us all. Our current solution is half way down the page on the idea.