Restrict field edit on Project Workspace Planning console

[ShaidaC]

 

Hi Everyone,

I have a requirement in Project Workspace Planning Console where I need to restrict editing of a field based on certain validations. Since the Planning Console grid is not the usual UI, I understand that field level ACLs don't work in the Planning grid. I also tried using an onChange Client Script, but it doesn't seem to trigger when the field is edited from the Planning Console.

As a last option, I tried handling the validation through a Business Rule. The validation itself works fine and I can display an error message and abort the update but the Planning Console still shows the newly entered value. The old value is retained in the database, but the user continues to see the changed value until they manually refresh the page.

I'm wondering if there is a way to handle this from the server side so that when the Business Rule aborts the update, the Planning Console also refreshes the value to what is actually saved in the database.

This is the Business Rule I'm currently using:

(function executeRule(current, previous /*null when async*/) {

    gs.addInfoMessage('date check business rule is running');

    var gr = new GlideRecord('project_change_request');
    gr.addQuery('parent', current.parent);
    gr.addQuery('state', 2);
    gr.query();

    if (gr.next()) {
        return;
    } else {

        gs.addErrorMessage(
            'Changes in Planned End Date require a Project Change Request'
        );

        current.setAbortAction(true);
        action.setRedirectURL(current);
    }

})(current, previous);

[boteeuwen]

Hi ShaidaC,

I think I see the issue now.

The problem does not appear to be the requiredFields value or the backend value of the choice field, but rather the parent reference itself.

On pm_project_task, the parent field is a reference to the Task table. This means that parent.u_has_wip_project_change_request does not necessarily resolve to a pm_project record, which is where your custom field exists.

This also explains why the dot-walked example in the Script Include works. In the example, assigned_to.manager follows a valid reference path to a table where the manager field exists. In your case, however, parent does not consistently resolve to the Project table, so the framework cannot reliably evaluate parent.u_has_wip_project_change_request.

You would therefore need to use a reference path from pm_project_task that consistently resolves to the related pm_project record, and then evaluate u_has_wip_project_change_request through that reference.

I would first check which field or reference path on pm_project_task in your instance leads directly to the Project, and use that instead of parent.