Project table state change issue

[Prasad_1362]

Hello All,

We had a requirement to add the 'On Hold' state to the Project table. This has been implemented, along with the necessary changes in the dictionary attributes.

Currently, when we change the project state from 'On Hold' to any other state, the system prompts to change the Project Task states as well. Please check the below attached image.
We understand this is an OOB functionality, but the client would prefer to avoid this behavior. Is there any way to prevent it?

Any help would be appreciated.

Thank you.

[Hayo Lubbers]

Hi @Prasad_1362,

The message comes from the AjaxProjectUtil, thanks to the PlannedTaskStateUtil.

The PlannedTaskStateUtil is an extend from the TaskStateUtil, which manages the states for tasks.

More info on the (Planned) TaskStateUtil : https://docs.servicenow.com/bundle/xanadu-api-reference/page/app-store/dev_portal/API_reference/Task...

Please check if you can configure it properly in the dictionary override, before changing the script include!

Hope this helps,

Hayo

[Prasad_1362]

Hello @Hayo Lubbers,

As part of the initial requirement, we renamed the state from 'On Order' to 'On Hold,' keeping its backend value as 9. The changes were applied to the Override dictionary for the Planned Task table. (please refer to the attached image).

Now, based on your suggestion, do we also need to create a new Override dictionary entry for the Project table to ensure everything functions as suggested by you? As per that we have created new entry for pm_project table with state column in which where we can add our on hold backend value 9 in state bucket?

Looking forward to your guidance.

Thank you!

[Hayo Lubbers]

Hello @Prasad_1362 ,

If you have the state renamed for the Project Table, you need to change the override for the project table. The system looks at the best matching override (or dictionary definition in the end).

So a business rule looking at the state for the Project table, needs to be specified on the Project dictionary override.

If there would be no dictionary override, it would take the planned_task and if there would be no dictionary override there, it would take the task definition.

So, the answer is basically: yes. You need to specify your on hold state. Probably as an additional pending_state.

Hope this helps,

Hayo

[Uncle Rob]

It can't be understated how dangerous it is to meddle in SPM state model and the code that governs it.
I *wish* it were as flexible as other modules, but it isn't.

I've only done 1 net-new SPM implementation.  All other implementations were "help!  We destroyed this thing"
And in almost every case, core components were customized because "client didn't want that".  They were almost never made aware of the risks.  And I've never ONCE seen even a lick of documentation about SPM customizations.

If you want to do this
WARN your customer that this is a very very very VERY bad idea.
Document EXACTLY what you did, and why, and give that document to the customer.