Edit in List - Mandatory Field

[Simon Ellis]

I need to add a new field to the Edit In List.  That's not a problem.  The problem is that at a form level the field is mandatory on the relevant detail form and to provide consistency I need to make it mandatory on the list form as well.  I dabbled in WSP by setting required = yes, but that didn't work for me.

 

In the list form I have the following specified for the field...

 

listEditField("affected_resource.name","Configuration Item");

 

and

 

<PDM_MACRO name=lsCol hdr="Affected CI" attr=affected_resource.name>

 

This allows the CI to be available and update able but not mandatory.

 

Any pointers?

[Anon Anon]

Have you tried this <PDM_MACRO name=lsCol hdr="Affected CI" attr=affected_resource.name required="yes" >

 

You can check the Advanced check box in the Properties box for the field in WSP to set it

[Anon Anon]

Actually I don't think this will work since the edit in list box that pops up when you click the button references in the form code

 

<pdm_jscript file=list_edit.js>

 

Which you would have to add a ListEditRequired function.

 

The List_cr.htmpl has this in it:

 

<pdm_jscript file=list_edit.js>

startListEdit(__search_filter);

listEditStartRow();

listEditReadonly("ref_num","Request #");

listEditField("status");

listEditField("priority");

listEditField("parent.ref_num");

listEditField("caused_by_chg.chg_ref_num");

listEditField("assignee");

listEditEndRow();

listEditReadonly("summary",4);

endListEdit()

I don't believe CA would support modifing the list_edit.js file

[Simon Ellis]

Yes, I did try that and as you say it didn't work for me...

[Grant Bruneau]

What about adding CI to the Incident/Problem dependent attribute control for the Resolved status? This way Analysts will not be able to close out an incident from the edit in list view unless CI is filled in.

[Simon Ellis]

From my understanding of the request they are not trying to resolve the request/incident, just change the CI.

[Legacy User]

Hi gizmo, if you modify your schema to make chg.affected_service a Required field, then it will become a mandatory field wherever it appears.

[Simon Ellis]

I have been looking at that making the field mandatory at the schema level but wonder where else that may cause an issue....

[Legacy User]

The only issue I can think of is that every ticket that was raised prior to the schema mod will require an affected_service to be added the next time it is edited.  But that will happen anyway if you find some other means to make it a mandatory field.  Is there a possibility that an affected service should not be required for some change types or change categories?

 

In the client's context is there a particular status at which the affected_service should be present?  I have clients, for example, who use a 'submitted' or 'approval in progress' status to flag that the change is ready to be approved, at which point it is reasonable to insist on particular fields having a value (such as type, priority, impact, scheduled start date and duration) - and going back to gbruneau's suggestion, you could add affected_service to a status transition if you can identify a transition where it makes sense.  Assuming your client has change transitions configured, of course!

 

If you don't want to do a schema update you could enforce the field by means of a POST_VALIDATE trigger against the chg object.  But practically speaking that will have the same 'side-effect' as the schema mod, in that 'old' tickets that were raised prior to the trigger being added will still have to have the affected_service added the next time they are edited.