13
Hi Team,

It would be beneficial for the system to have the ability to override a certain trigger on a table or a page.
Also adding a priority would be useful.
I will write an example with an architecture of how the platform should handle this below, for one blunt event such as OnAssistEdit on a page field, but this should extend to all similar events:

pageextension 60000 "Extend Job Card" extends "Job Card"
{
layout
{
modify("No.")
{
trigger OnAssistEdit(60100,True)
begin
Message('CustomEvent');
end;
}
}
}

where all the triggers should have two new parameters:
1. OrderOfExecution - integer
OrderOfExecution would allow different extensions to set an order of execution.
The trick is that the OrderOfExecution should be validated against the App.json permitted range and should be part of that range.
I am open to comments and suggestions for this one, but the idea is that you can have extensions that would trigger in the order of their assigned object range so generally we would have some sort of order of execution between extensions.
For instance the custom range 50000-99999 would be executed after standard ones by default, but before published apps.

2. SkipStandardTrigger - boolean

SkipStandardTrigger = true: it should only execute triggers with a higher priority than 0
* base app trigger code in the system don't need to change by default should be considered (0,false) and always executed before all the other triggers unless there is an extension that calls SkipStandardTrigger = true.

3. (Optional) SkipCustomTrigger: Integer
This one is the nicest: if set, it will allow the current trigger to disable another one in a different extension.
However to use it you will need to be able to add the other one as a dependancy and obviously to know(if the vendor is willing to share it with you for a certain customer), or be able to see it's ID.


Please vote for the idea if you find it useful.

Cheers,
Robert Bulugea
Category: Development
STATUS DETAILS
Needs Votes
Ideas Administrator

Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future.

Best regards,
Business Central Team

Comments

R

One obvious simple solution is to only allow it for 50000..99999 range, but I don't settle for that.

Another more complex solution I am thinking now is that any app that needs to use some of these triggers for some changes allow others to see that trigger code without exposing all the rest of their business logic.

*This can be easily achieved with a blob field in that table I mentioned that is crawling the code to gather the modified triggers when you first register the app.

+++A total different approach to this would be sub-triggers for the events.
- in other words each event could have a trigger before and after and this could be tapped into also by a parameter of that event call.
++++ Also another idea I had last night was having all the standard event code tested for a flag which skips the standard code if set on the event.
- this would allow to override the standard behavior in some scenarios and remove the messy clutter of going around in all the apps we have.

Overall, any solution we adopt we've got to remember that the registered apps are always approved by Microsoft in the first place, so there are checks of those codes in place upfront.
One of the reasons why I think it would pay to make these subscribers visible to others is that in that way, no-one will be determined to put all their business logic in such events, but only use it for certain scenarios where it is more elegant to change the behaviour this way.
There is always a balance between developers common sense and system restrictions, but at the end of the day, it is something that should be possible, overriding some standard event triggers.

Category: Development

R

Further to this, on the MS side of things I would suggest that when an extension is published/unpublished, the code is analyzed and these properties are used to populate a table/view in the backend tenant SQL.
That table can be easily used as an intermediate step before the current event execution logic in the platform.
I know this sounds like a major redesign, but it doesn't have to be...

Adding to that, as one of my dear colleagues advised, it can be scary to disable standard code.
I agree with that, but I also agree that writing any code can make a system totally unstable.
This ability, as the ability to write any AL code should be attempted only by AL developers who should know what they are doing.

Cheers,
Robert

Category: Development