As a Problem Process Owner, I do not want users to create a problem using this problem.do

[Aparna45]

We follow the out-of-the-box Problem Management process, where problems must be created only from incidents. However, accessing problem.do allows users to bypass this and create problems without an associated incident.

Proposed Options:

1. Prevent access to problem.do

2. In the “New” state, make First Reported By editable and mandatory. After moving out of the “New” state, this field should become read-only. Also ensure that only one problem can be created per incident.

Any guidance or suggestions would be greatly appreciated.

[Ankur Bawiskar]

@Aparna45 

My thoughts

1) prevent users access to problem.do

-> you can't control this as user can type this in left nav

-> try to use onLoad client script on problem table and see what's in URL, if it contains particular pattern then use this script to make all fields readonly and use DOM manipulation to hide the Submit button.

2) New state and 1 problem per incident

-> use UI policy to make field editable and mandatory based on State field

-> use before update/insert BR on incident table and see if the problem_id currently present is already associated with some other incident. if yes then abort the operation

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Ankur Bawiskar]

@Aparna45 

Hope you are doing good.

Did my reply answer your question?

💡 If my response helped, please mark it as correct ✅ and close the thread 🔒— this helps future readers find the solution faster! 🙏

[Dr Atul G- LNG]

Hi @Aparna45 

Being a BPC, I will say don't create technical debt for this.

Lets understand that problem record only created by ItIl user or problem specify user only and

.do

.form

.config are some kind of short tricks to navigate in platform quickly. If a user create prb via .do nothing big going to happen even though it saved clicks.

So don't make or restrict user to use .do.

Now second part that making field editable that is UI policy you can check and make changes.

Third part only 1 prb for 1 incident that possible via BR. You can check ootb logic in incident table to create change from incident UI action that allows only 1 change for 1inc. Same logic you can add in create problem UI action.

[Dr Atul G- LNG]

Hi @Aparna45 

did you check my answer?