• • In the approval workflow scenario, when the default "reject" interaction (rejection method, rejection node, pop-up copy, jump instructions, etc.) fails to meet business demands, the display and behavior can be enhanced by mounting logic before/after the "reject" rendering through the approval details plugin. * *

Typical scenarios include:

• Reject pre-pull process data and determine if tasks are allowed to be completed directly
• After rejection, customize the pop-up title, comment box title, rejection to the specified node/end process, etc.
• The mobile side hides or supplements the rejection method and node before rendering the rejection method list and the rejection task list; customize the title text such as "Jump to the current node after processing"

Applicable scenarios

Applicable to scenarios where "the Approval Detail page already exists, but the method selection, node scope, pop-up window and description copy in the rejection link need to be customized according to business rules"; specific event parameters and examples are subject to the reference manual.

# Applicable Pages

• Approval Detail page - Rejection action triggered pop-up
• To-Do approval process - Rejection action triggered pop-up

# When is a rejection enhancement appropriate?

If you're experiencing any of these needs, it's often a good idea to prioritize pushback enhancements:

• Business judgments need to be inserted after the user clicks "Reject", before the pop-up window or list rendering (if the task can be completed directly)
• Need to override the rejection pop-up title, comment title, rejection type options area, or instructions for “Assign node to process/resubmit”
• Need to control the rejection method hidden on the mobile side, the list of rejectable nodes, or customize the "Jump to current node" class title

# Development Ideas

Rejection enhancements can often be broken down into three steps:

1. Make it clear whether you want to enhance the “before rendering” or “after rendering” behavior, and the runtime (web/mobile)
2. Register the corresponding event (web) or hook (mobile) in the approval details plugin, call the API in the callback or overwrite the list data to complete the customization
3. Publish the plugin and complete configuration and validation in the Target Approval Detail Scenario

DEVELOPMENT WORKFLOW

1. Identify scenarios and access points

Before you begin, confirm the following questions:

• Logic needs to be executed before or after rejecting UI drawings (web for approval.reject.render.before/approval.reject.render.after; mobile for each hook below)
• Does it involve the ability to directly complete tasks, a list of rejection methods, a list of rejectable tasks, title copy, etc.
• Whether the mobile operation list complies with the requirements of the reference manual (such as transparent id can not be changed at will)

2. Create approval details plugin

Create a * * Approval Details * * type plugin in the background (Web/Mobile according to the actual terminal selection), and align it with the Web Approval Details Plugin Description ] or Mobile Approval Details Plugin Description ] documents.

3. Select events or hooks and write logic

• • Web-side * *: Register the event in the plugin apply, use the api method provided by the document within the callback (such as getting process data, setting the pop-up title, customizing the rejection options area and the list of rejectable nodes, etc.).
• • Mobile * *: Register a Hook that matches the scene, process rejectWayList, taskList in functional, or return a custom title copy, etc.

4. Joint Coordination and Validation

• Override different rejection paths such as "Reject to specified node", "Reject and end process", etc.
• Check list screening, style customization and return values against reference manuals

5. Launch and go-live

After the development is completed, release the plug-in, enable it in the corresponding approval detail scenario, and return to the rejection path on the real process task.

# Recommended entrance

Frequently asked questions

Q: Which should be the before and after of the web?

before is more suitable for branching and intercepting class logic before the rejection interface is finally presented; after is more suitable for display class customization after the rejection UI is ready (title, each rejection option area, list of rejectable nodes, etc.). The two can be used in combination, subject to the division of competencies in the reference manual.

Q: What do I need to pay attention to when refusing a mobile action/task list?

The reference manual emphasizes that the transparent id cannot be changed at will, otherwise it may be invalid; the data contract needs to be retained when doing splice, push and other operations on the list.

Next

• Approval Content Area Enhancements: View Approval Content Area Enhancements
• Distinguish between components and plug-ins: View the Components Guide vs. Plug-ins Guide