Hello Community -
Thanks for taking some time to read this thread. Some context; my organization conducts 'risk assessments' to assess inherent risk on each initiative we engage. We've created a Risk sub-object (Project master object):
which is basically a table of predefined risk rows and columns to which PMs fill out and SMEs validate/confirm (it is a sub-page in classic):
If I create a process using the risk assessment as the primary object, I can lock individual rows however am unable to count the number of rows inserted so cannot rely on this to account for every scenario, thus need code..
Respectfully requesting code (GEL, etc, whatever works) to embed in a process which counts the number of rows in the table above (there might be more than what's shown, so it'd probably have to count until, i.e., remaining rows=0), then locks each row to prevent users from editing per # of rows counted. Bonus points if you may also be an amazing person and include code to Unlock the counted # of rows using the same logic as above.
This would be a life-saver as I am a newer user of Clarity and coding, and my organization is undergoing a project management transformation. Thank you in advance for your help and/or input. Any and all information is welcomed.
I think there are 2 ways to achieve this, depending on your requirement.
First, if you don't want users updating the records at any time, just don't give anyone Edit rights over the records (except Admins, of course). If they only have View rights, they can see but not update.
Secondly, if you want to lock the fields when a risk reaches a certain stage you can write a process that fires on the Update event of the object, and have a step in your process to Lock All Attributes. (You'll need a second process that will Unlock All Attributes).
Screen-shot attached is the action that fires on the Start step when a user submits a timesheet in our organisation
Slightly off topic, but, why did you build a separate Risk module, when there already is an OOTB Risk module on the Project?
We modified the OOTB Risk module to include attributes to track 'inherent risks' where these attributes are locked on entry (aka enter-once). Only challenge is when users incorrectly enter the data first time, then then attribute must be periodically switched back to allow it to be updated.
But to answer your question, the only way you can lock attributes as identified by Alistair, is by the process being run on the Risk Record. If you want this lock facility to be run external from the Risk Record (ie when Project has X risk records), then there will need to be two processes, first runs when Project has X risk records which updates a hidden attribute on the Risk - this will have to be a GEL script which does the update by XOG. The second process will automatically start when the hidden attribute is update and this process will just Lock All attributes (as per Alistair's screen shots).
There can be a second process (potentially restricted to PMO) which can be run manually on the Risk Record to unlock the record when required.
Thanks for the replies Alistair and Roland.
To answer your initial question, Roland, we created a separate risk sub-object apart from the primary risk module as these are two separate processes in my organization. We have project risks (primary risk module) and a separate process that's conducted for every initiative which assesses the inherent risks to the organization as a whole (not the project) - such as regulatory, legal, compliance, etc.
I understand using a process to lock all attributes works, however only for an individual row - I'm looking for something that locks every row in the table at once, instead of doing each one incrementally. Our implementation consultant from CA developed a GEL script to accomplish this, but unfortunately, it's encountering errors and I'm unable to debug.
Thanks in advance for your help.
Please re-read my previous post, where I detail how this would able to be achieved using two processes.
You could also use 'secure pages' where the general staff only have 'view-only' access to the page, so from their perspective, the record is 'locked'.
Have you considered sharing the GEL script and what the errors are? There are non-supported ways (eg database inserts into the 'locked attribute table') which the previous consultant may have written (not saying they did, but I can't see how else it would be achieved using a master process). Seems weird that you are not exploring this option when it previously worked.
Unfortunately, I do not have the expertise or knowledge to debug/update the GEL Script, which is why we aren't using this currently - if someone else could update to fix it, that'd be awesome. I'd be happy to share the code however unsure how that works with CA Guidelines (I've read that sharing custom code is prohibited?). Please let me know.
Regarding your suggestion of the two processes, pretty much the same situation as the above - I do not have the ability to create the GEL script as mentioned. This sounds like it could work but unfortunately out of my league...
Have you considered contracting someone who has the required skills to either review the original code, or to come up with alternatives? There are several on this forum, including myself, who have these skills.