An automation script sometimes needs to ask before changing a record. This example keeps it simple: ask the user whether to set a description, set it if they choose OK, and leave it unchanged if they choose Cancel.
Maximo calls this its Yes/No/Cancel interaction API, but it also supports OK/Cancel responses. The buttons configured on the message must match the response constants in the script.
Set up the action and message
Create a Jython script with an action launch point on an object with a writable DESCRIPTION attribute. Expose that action through a button or application action so a user can invoke it on the current record.
Use an action rather than an action event on DESCRIPTION itself: the example should ask before assigning the value, and assigning the value should not trigger the same prompt again.
In Database Configuration, create a choice message with:
| Setting | Example value |
|---|---|
| Message group | custom |
| Message key | setdescription |
| Message text | Set the description to "Confirmed by user"? |
| Buttons | OK and Cancel |
The group and key are example custom identifiers. Configure the message with OK/Cancel buttons rather than Yes/No.
The script
# Show the configured OK/Cancel message when there is no answer yet.
def askForConfirmation():
service.yncerror("custom", "setdescription")
# Apply the change only after the user confirms.
def handleOK():
mbo.setValue("DESCRIPTION", "Confirmed by user")
# Cancel requires no undo: this script has not changed the field.
def handleCancel():
pass # Leave the field unchanged.
# Map each response to the function that handles it.
responseHandlers = {
service.YNC_NULL: askForConfirmation,
service.YNC_OK: handleOK,
service.YNC_CANCEL: handleCancel,
}
# Ask for input only during an interactive user session.
if interactive:
# Read the answer; YNC_NULL means the question has not been answered.
response = service.yncuserinput()
# Run the matching handler, or prompt again for an unexpected response.
responseHandlers.get(response, askForConfirmation)()Replace the attribute and value in handleOK() with the change you want to confirm. Normal field validation and access checks still apply.
How the interaction works
On the first invocation, there is no answer yet. service.yncuserinput() returns YNC_NULL, so the script calls service.yncerror() to raise the configured choice message.
Maximo handles the dialog and makes the user's response available when the interaction is processed again. The script dispatches that response to the matching handler:
| Response | Behaviour |
|---|---|
YNC_NULL |
Display the confirmation message |
YNC_OK |
Set DESCRIPTION to Confirmed by user |
YNC_CANCEL |
Do nothing; preserve the existing description |
This is not a blocking Python input prompt. Maximo manages the interaction; the script supplies the question and the behaviour for each answer. IBM's choice-message example demonstrates this request-and-response pattern.
The fallback handler asks the question again for an unexpected response. If you configure Yes/No buttons, use YNC_YES and YNC_NO handlers instead of the OK/Cancel constants shown here.
Keep the change inside the OK handler
Putting setValue() before the prompt would change the field before the user has agreed. Keeping it inside handleOK() means Cancel needs no undo logic: nothing has been changed by this script.
There is no explicit save(). The value is set on the current MBO and persistence follows the surrounding application's save behaviour. Cancel leaves this field unchanged; it does not roll back other edits on the record.
The interactive guard skips the entire interaction for non-interactive calls. In that context, this example neither asks the question nor sets the field. Define separate behaviour if integrations or background processing should perform the action.
Try it
Use a non-production record with a recognisable description:
- Invoke the action and choose Cancel. Confirm the description is unchanged.
- Invoke it again and choose OK. Confirm the description becomes
Confirmed by user. - Save and reload the record to check persistence through your application's normal workflow.
No tested Maximo version is recorded for this example yet.
That is the whole pattern: ask, read the answer, and make the change only in the handler for the button that confirms it.