Repository navigation
[Extensibility Request] issue 30420: add service post and send events - #10992
Marko Aleksandric (AleksandricMarko) wants to merge 4 commits into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Could not find a linked ADO work item. Please link one by using the pattern 'AB#' followed by the relevant work item number. You may use the 'Fixes' keyword to automatically resolve the work item when the pull request is merged. E.g. 'Fixes AB#1234' |
|
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 7fd29cf0-bf3b-4d3b-98f6-c1a286323ca8
Good Sense Reviewer - Round 1Recommendation: AcceptWhat this PR doesThis change adds two integration events to Service Post and Send. Subscribers can allow an additional service document type through confirmation, replace the standard posting call, and stop before sending when their posting path did not create a posted document. The standard invoice and credit memo path is unchanged when there are no subscribers. The new flags separate handling the posting call from deciding whether the send phase should continue, which supports the requested extension scenario without changing an existing public signature. Problem-solution fitFit: Strong The requested behavior needs extension control before confirmation and before posting. The two events are placed at those points and expose the service header plus the control flags needed to keep or replace the standard flow. SuggestionsNo suggestions. Risk assessment and necessityRisk: Low. With no subscriber, supported document types still confirm, post, commit, and send as before. Subscribers can change that flow, but the new surface is additive and does not break existing events or procedures. Necessity: The events are needed so extensions can use Post and Send for additional service scenarios without copying the codeunit. No test is required for the empty event publishers.
|
|
Pull request was closed
Predrag Maricic (PredragMaricic)
left a comment
There was a problem hiding this comment.
Requesting changes because SkipPost is currently honored even when the subscriber did not replace posting.
S1 - Honor SkipPost only for replacement posting. OnCodeOnBeforePost can set SkipPost := true while leaving PostIsHandled := false. The base app then runs Service-Post and immediately exits before OnAfterPostAndBeforeSend, Commit, and SendPostedDocumentRecord. This creates a posted-but-not-sent outcome and differs from the source request, where SkipPost is checked only inside the handled-posting branch.
Gate the early exit with PostIsHandled, or restore the requested nested flow: when PostIsHandled is false, always run standard posting and continue sending; when it is true, exit only if SkipPost is also true.
S2 - Add subscriber-contract tests. Cover base posting, replacement posting followed by sending, handled-without-posting exit, and the invalid PostIsHandled = false / SkipPost = true combination. This event controls a critical posting-and-send boundary and currently has no automated coverage.
The sole CI failure is work-item validation rather than a code or test failure.
Remove SkipPost and exit before standard posting and sending when the subscriber handles posting. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 206c3a8e-61b7-42ba-8b98-dba77dc957f2
fcb4161
Good Sense Reviewer - Round 2Recommendation: Request ChangesWhat this PR doesThe new commit simplifies the pre-post event from two control flags to one. A subscriber that handles posting now exits the codeunit before the existing send phase. Status of previous suggestionsNone - round 1 had no suggestions. New observations (commits since round 1)S1 (🔴 High): Handled posting can no longer continue to send Risk assessment and necessityRisk: High for the requested extension contract. A subscriber can either allow the standard posting routine or exit before sending, but cannot perform its own posting and continue through the standard send flow. Necessity: The event request specifically requires separate posting replacement and send-suppression decisions so extensions do not need to copy the codeunit.
|
alexei-dobriansky
left a comment
There was a problem hiding this comment.
Please review the suggestion.
Restore SkipPost and honor it only when a subscriber handles posting, allowing successful replacement posting to continue through the standard send flow. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 0a51aebd-dbfd-4a00-8fe7-6fb8c0812957
Good Sense Reviewer - Round 3Recommendation: Request ChangesWhat this PR doesThe new commit restores separate controls for replacing posting and stopping before send. It fixes the previous early exit, but the replacement Service Order path still cannot make the existing send routine send the posted invoice. Status of previous suggestions
New observations (commits since round 2)S2 (🔴 High): Replacement order still does not send Risk assessment and necessityRisk: High for the new Service Order contract. Replacement posting can create and commit an invoice, but the following send call can silently do nothing because its local ServicePost instance has no invoice state. The standard Invoice and Credit Memo paths remain unchanged when no subscriber handles the new events. Necessity: Supporting Service Orders without copying the codeunit is a valid need. The scope is small, but posting replacement and sending must work together end to end.
|
Summary
Service integrations need to use Post & Send for Service Orders without copying codeunit 5979 or being limited to the standard Service-Post routine. This PR adds extension points that allow additional document types through confirmation and let subscribers safely replace posting or stop before sending when no posted document was created.
Source issue repository: microsoft/AlAppExtensions; issue number: 30420
Changes Made
Service-Post and Send.Code()- added pre-confirmation and pre-post integration events so extensions can support additional service document types and substitute posting while coordinating whether sending should continue.Fixes AB#648196