microsoft / microsoft/ALAppExtensions
Add OnBefore Event Publisher for Approvals Mgmt. PreventInsertRecIfOpenApprovalEntryExist
Nobody has claimed this yet.
- Dominant language
- AL
- Stars
- 988
- Forks
- 692
- Avg merge
- 49m
- Merged PRs (30d)
- 1
Description
Why do you need this change?
Hi!
Our customer is not using Worfklows and Approvals. Therefore we do not need to perform unnecessary checks when we insert new General Journal Lines (e.g. for performance reasons). There is no possibility for us to skip these checks. And even if our customer was starting to use Approval logic, we would like to be able to control the program code before runtime errors are raised if open approvals do exist.
Best regards,
Johannes Gritsch
Describe the request
A possible Event Publisher would look like
OnBeforePreventInsertRecIfOpenApprovalEntryExist(Variant: Variant; var IsHandled: Boolean)
and would be implemented at the very beginning of procedure PreventInsertRecIfOpenApprovalEntryExist() with
OnBeforePreventInsertRecIfOpenApprovalEntryExist(Variant, IsHandled);
if IsHandled then
exit();
Furthermore consider to restructure the code so that procedure CanCancelApprovalForRecord() is only called once in the current function.
Thanks!
Internal work item: AB#606350
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate PreventInsertRecIfOpenApprovalEntryExist and CanCancelApprovalForRecord in the approvals-management code; first read how General Journal Line insertion reaches that procedure. Done means the OnBeforePreventInsertRecIfOpenApprovalEntryExist publisher can set IsHandled to bypass the checks, and CanCancelApprovalForRecord is called once while existing approval behavior remains unchanged.
Written by the indexing model from the issue text.
Assessment
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100