Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would…
Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site’s lifecycle. A vendor belongs to no site, so vendors are moved by type or all together.
p_type_id is the register’s own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. p_mapping names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with p_dry_run false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in.
Headers
Preference
params=single-object Body
Move the open records of one lifecycle into another, within a site or business unit and a type, or say what that would do. Work orders, work requests, maintenance plans, inspections, contracts, vendors, purchase requests, purchase orders and assets move; maintenance rounds do not, because each new round is born into its site's lifecycle. A vendor belongs to no site, so vendors are moved by type or all together.
p_type_id is the register's own type: a work order type, a work request category, an inspection type, a contract type, a vendor type or an asset category, each with the types filed under it. p_mapping names a status of the new lifecycle for each status of the old one, by id. A dry run, the default, answers with every status holding open records in the scope, how many, where each is mapped, the status of the new lifecycle with the same code, and what the product reads off the status that would change for those records. Confirmed with p_dry_run false, every status holding records has to be mapped and a reason given, and the move runs as a bulk job: each record is re-filed into its new status without walking any move, so no guard, rule or notification fires, and its history records the change with the reason. Finished records stay in the lifecycle they finished in.
Response
OK