Maximo Open Forum

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

Nice solution Jade!

There's also a way to do this without having to modify the menu options. If you create your automation script with the OBJECT.DUPLICATE name (in your case JOBPLAN.DUPLICATE), Maximo will automatically fire the script whenever a Job Plan is duplicated. Within the script there will be two implicit variables: 1) mbo, which represents the record being copied, and 2) dupmbo, which represents the newly copied record. You should then be able to trim the script down to something like:

from psdi.mbo import MboConstants## after DUPLICATE, dupmbo represents new recorddupmbo.setFieldFlag("SITEID", MboConstants.READONLY, False)  ## undo read-onlydupmbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True)   ## make required

Hope this helps,

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

Hi Alex!

I did try the JOBPLAN.DUPLICATE approach first because it is far more elegant--but for reasons unknown to me, the screen did NOT refresh (i.e. the Site field remained read-only).

:o) Jade

Nice solution Jade!

There's also a way to do this without having to modify the menu options. If you create your automation script with the OBJECT.DUPLICATE name (in your case JOBPLAN.DUPLICATE), Maximo will automatically fire the script whenever a Job Plan is duplicated. Within the script there will be two implicit variables: 1) mbo, which represents the record being copied, and 2) dupmbo, which represents the newly copied record. You should then be able to trim the script down to something like:

from psdi.mbo import MboConstants## after DUPLICATE, dupmbo represents new recorddupmbo.setFieldFlag("SITEID", MboConstants.READONLY, False)  ## undo read-onlydupmbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True)   ## make required

Hope this helps,

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

Was looking for something like this, thanks, Jade.

One point is that we need to set the ORGID flag as well, since it gets updated when you select a new site. 

But other than that, works a treat. 

Also tried the OBJECT>DUPLICATE method, but fields remained read-only. 

------------------------------
Dirkjan van Rooy
Naviam
------------------------------


Original Message:
Sent: 06-15-2023 09:52
From: Jade Warren
Subject: Duplicating a Job Plan (Site field is READONLY)

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

------------------------------
Jade Warren
Great River Energy
------------------------------

Job Plans are the most complex functional area. If you override business rules, you will break Job Plans for your instance-a mess you do not need to deal with ever.

Job Plans are defined at the Set, Org, and Site, I believe. If a job is not defined at the site level, duplicate the Job Plan and assign a site ID to revision 0. This solves your issue forever.

In Maximo: 

If a Job Plan has a site ID, it's a site-level record. 

If a Job Plan does not have a site ID but has an Org ID, It's an Org-level record. 

If a Job Plan does not have a site ID or an Org ID, it's a Set-level record. 

Adding a site ID to an organization-level Job Plan violates business rules due to misalignment, causing the misclassified record to remain in that state for its lifetime until the correct business process to remediate the violation is executed. 

It's better to err on the side of caution.

Best,
------------------------------
Fredrick Ndwaru
Perpetual Ignition
------------------------------


Original Message:
Sent: 08-13-2026 04:16
From: Dirkjan van Rooy
Subject: Duplicating a Job Plan (Site field is READONLY)

Was looking for something like this, thanks, Jade.

One point is that we need to set the ORGID flag as well, since it gets updated when you select a new site. 

But other than that, works a treat. 

Also tried the OBJECT>DUPLICATE method, but fields remained read-only. 

------------------------------
Dirkjan van Rooy
Naviam
------------------------------



Original Message:
Sent: 06-15-2023 09:52
From: Jade Warren
Subject: Duplicating a Job Plan (Site field is READONLY)

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

------------------------------
Jade Warren
Great River Energy
------------------------------

Job plans are complex and the risk of duplicating and changing the site are all the child/related records that are also tied to the site.  If the job plan has materials related to a storeroom, changing the site on the duplicate version can impact that.  Similarly duplicating job plans across organizations can impact associated labor records.  It is possible, but you do need to make sure any scripting that is allowing for change of org or site on the new record properly accounts for updating any related records as well.  We built a custom action that allows users to copy a job plan to their site; in that instance it allows them to find an existing job plan, copy it setting the site id to their default insert site, and then checks all child records and removes/updates as needed to maintain data integrity.

Amy

Job Plans are the most complex functional area. If you override business rules, you will break Job Plans for your instance-a mess you do not need to deal with ever.

Job Plans are defined at the Set, Org, and Site, I believe. If a job is not defined at the site level, duplicate the Job Plan and assign a site ID to revision 0. This solves your issue forever.

In Maximo: 

If a Job Plan has a site ID, it's a site-level record. 

If a Job Plan does not have a site ID but has an Org ID, It's an Org-level record. 

If a Job Plan does not have a site ID or an Org ID, it's a Set-level record. 

Adding a site ID to an organization-level Job Plan violates business rules due to misalignment, causing the misclassified record to remain in that state for its lifetime until the correct business process to remediate the violation is executed. 

It's better to err on the side of caution.

Best,
------------------------------
Fredrick Ndwaru
Perpetual Ignition
------------------------------



Original Message:
Sent: 08-13-2026 04:16
From: Dirkjan van Rooy
Subject: Duplicating a Job Plan (Site field is READONLY)

Was looking for something like this, thanks, Jade.

One point is that we need to set the ORGID flag as well, since it gets updated when you select a new site. 

But other than that, works a treat. 

Also tried the OBJECT>DUPLICATE method, but fields remained read-only. 

------------------------------
Dirkjan van Rooy
Naviam
------------------------------




Original Message:
Sent: 06-15-2023 09:52
From: Jade Warren
Subject: Duplicating a Job Plan (Site field is READONLY)

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

------------------------------
Jade Warren
Great River Energy
------------------------------

I totally agree with Amy and Fredrick. There is so many related data to a Site specific Jobplan which can become inconsistent if you manage to change the SiteID on the duplicate. Having had the requirement of copying existing Jobplans into a new site quite some time ago, I was thinking about a loopback interface concept:

1. Add a non-persistent Field "NEWSITE" to the Jobplan Object, make it available somewhere in a dialog (to manage permissions)
2. An Action triggers a Publish Channel with the content of the Current Jobplan
3. A xslt replaces the SITEID on the generated XML with the value provided in the non-persistent "NEWSITE"
4. The resulting xml will be processed by an Enterprise Service. If this Enterprise service is able to "digest" the XML - the data is fine, if not it fails for a reason, but it won't create inconsistencies.

Just as an idea/approach for a technical solution, if entering the duplicate manually isn't reasonable.

Job plans are complex and the risk of duplicating and changing the site are all the child/related records that are also tied to the site.  If the job plan has materials related to a storeroom, changing the site on the duplicate version can impact that.  Similarly duplicating job plans across organizations can impact associated labor records.  It is possible, but you do need to make sure any scripting that is allowing for change of org or site on the new record properly accounts for updating any related records as well.  We built a custom action that allows users to copy a job plan to their site; in that instance it allows them to find an existing job plan, copy it setting the site id to their default insert site, and then checks all child records and removes/updates as needed to maintain data integrity.

Amy

Job Plans are the most complex functional area. If you override business rules, you will break Job Plans for your instance-a mess you do not need to deal with ever.

Job Plans are defined at the Set, Org, and Site, I believe. If a job is not defined at the site level, duplicate the Job Plan and assign a site ID to revision 0. This solves your issue forever.

In Maximo: 

If a Job Plan has a site ID, it's a site-level record. 

If a Job Plan does not have a site ID but has an Org ID, It's an Org-level record. 

If a Job Plan does not have a site ID or an Org ID, it's a Set-level record. 

Adding a site ID to an organization-level Job Plan violates business rules due to misalignment, causing the misclassified record to remain in that state for its lifetime until the correct business process to remediate the violation is executed. 

It's better to err on the side of caution.

Best,
------------------------------
Fredrick Ndwaru
Perpetual Ignition
------------------------------




Original Message:
Sent: 08-13-2026 04:16
From: Dirkjan van Rooy
Subject: Duplicating a Job Plan (Site field is READONLY)

Was looking for something like this, thanks, Jade.

One point is that we need to set the ORGID flag as well, since it gets updated when you select a new site. 

But other than that, works a treat. 

Also tried the OBJECT>DUPLICATE method, but fields remained read-only. 

------------------------------
Dirkjan van Rooy
Naviam
------------------------------





Original Message:
Sent: 06-15-2023 09:52
From: Jade Warren
Subject: Duplicating a Job Plan (Site field is READONLY)

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

------------------------------
Jade Warren
Great River Energy
------------------------------

Agree with all of the above, for duplicating and actual Job Plan, the risk is too high. 

In our instance, the Job Plan object was repurposed for another feature, with limited child objects, all of which are site and org independant. 

We validated that all child objects save with the new and correct SITE and ORGID values.

For duplicating an actual Job Plan, much more care should be taken

------------------------------
Dirkjan van Rooy
Naviam
------------------------------


Original Message:
Sent: 08-17-2026 08:32
From: Johann Rumpl
Subject: Duplicating a Job Plan (Site field is READONLY)

I totally agree with Amy and Fredrick. There is so many related data to a Site specific Jobplan which can become inconsistent if you manage to change the SiteID on the duplicate. Having had the requirement of copying existing Jobplans into a new site quite some time ago, I was thinking about a loopback interface concept:

1. Add a non-persistent Field "NEWSITE" to the Jobplan Object, make it available somewhere in a dialog (to manage permissions)
2. An Action triggers a Publish Channel with the content of the Current Jobplan
3. A xslt replaces the SITEID on the generated XML with the value provided in the non-persistent "NEWSITE"
4. The resulting xml will be processed by an Enterprise Service. If this Enterprise service is able to "digest" the XML - the data is fine, if not it fails for a reason, but it won't create inconsistencies.

Just as an idea/approach for a technical solution, if entering the duplicate manually isn't reasonable.

------------------------------
Johann Rumpl
Naviam
------------------------------



Original Message:
Sent: 08-17-2026 08:21
From: Amy Tatum
Subject: Duplicating a Job Plan (Site field is READONLY)

Job plans are complex and the risk of duplicating and changing the site are all the child/related records that are also tied to the site.  If the job plan has materials related to a storeroom, changing the site on the duplicate version can impact that.  Similarly duplicating job plans across organizations can impact associated labor records.  It is possible, but you do need to make sure any scripting that is allowing for change of org or site on the new record properly accounts for updating any related records as well.  We built a custom action that allows users to copy a job plan to their site; in that instance it allows them to find an existing job plan, copy it setting the site id to their default insert site, and then checks all child records and removes/updates as needed to maintain data integrity.

Amy

------------------------------
Amy Tatum
Starboard Consulting LLC
------------------------------




Original Message:
Sent: 08-14-2026 15:32
From: FREDRICK NDWARU
Subject: Duplicating a Job Plan (Site field is READONLY)

Job Plans are the most complex functional area. If you override business rules, you will break Job Plans for your instance-a mess you do not need to deal with ever.

Job Plans are defined at the Set, Org, and Site, I believe. If a job is not defined at the site level, duplicate the Job Plan and assign a site ID to revision 0. This solves your issue forever.

In Maximo: 

If a Job Plan has a site ID, it's a site-level record. 

If a Job Plan does not have a site ID but has an Org ID, It's an Org-level record. 

If a Job Plan does not have a site ID or an Org ID, it's a Set-level record. 

Adding a site ID to an organization-level Job Plan violates business rules due to misalignment, causing the misclassified record to remain in that state for its lifetime until the correct business process to remediate the violation is executed. 

It's better to err on the side of caution.

Best,
------------------------------
Fredrick Ndwaru
Perpetual Ignition
------------------------------





Original Message:
Sent: 08-13-2026 04:16
From: Dirkjan van Rooy
Subject: Duplicating a Job Plan (Site field is READONLY)

Was looking for something like this, thanks, Jade.

One point is that we need to set the ORGID flag as well, since it gets updated when you select a new site. 

But other than that, works a treat. 

Also tried the OBJECT>DUPLICATE method, but fields remained read-only. 

------------------------------
Dirkjan van Rooy
Naviam
------------------------------






Original Message:
Sent: 06-15-2023 09:52
From: Jade Warren
Subject: Duplicating a Job Plan (Site field is READONLY)

One of our users asked about this this morning.  To provide the capability, did the following:

In Application Designer > Job Plans:

• add a signature option JP_DUP with the "UI action" flag set.
• update Select Action menu to replace the DUPLICATE option with JP_DUP

In Security Groups:

• Locate an appropriate security group (for testing, EVERYONE works usually) and grant the JP_DUP signature option for Job Plans

In Automation Scripts:

• Create an Action launch point JP_DUP and associate with a script JP_DUP
• Set the script code as follows:

from psdi.mbo import MboConstants;

## get context
session = service.webclientsession(); ## we need the session so we can get the app bean
appbean = session.getCurrentApp().getAppBean(); ## get the app bean

appbean.DUPLICATE(); ## call the DUPLICATE function as if the user would have

## after DUPLICATE, the screen is displaying the "new" job plan
mbo = appbean.getMbo(); ## pull that into 'mbo'
mbo.setFieldFlag("SITEID", MboConstants.READONLY, False); ## undo read-only
mbo.setFieldFlag("SITEID", MboConstants.REQUIRED, True);  ## make sure required is shown

Finally:

• Sign off / sign on (new security grants take effect)
• Test

------------------------------
Jade Warren
Great River Energy
------------------------------