Replies: 5 comments
-
But LC0011 does not enforce access = internal. It just warns if access is not defined at all. You can set method codeunits to the default value and there should be no warning |
Beta Was this translation helpful? Give feedback.
-
I had first enabled LC0011 and made it result into a warning. Then - to be as safe as possible for AppSource - I put 'Access = Internal' as the default value, which is fine for most codeunits, but not for those exposing events. I want to prevent developers from adding new events into these Internal codeunits, which would result in the events not being available for other extensions (if they did not verify the codeunits access property) |
Beta Was this translation helpful? Give feedback.
-
I agree, you typically do not want integration events in codeunits with |
Beta Was this translation helpful? Give feedback.
-
Seeing it got a lot of votes and I think it is useful, I implemented the rule with PR #194. |
Beta Was this translation helpful? Give feedback.
-
Sorry for the long delay of things here. I had some private things going on that took my attention. But I hope to be on track again now :) This is now deployed to prerelease for you all to test! |
Beta Was this translation helpful? Give feedback.
-
Scenario
We started applying rule LC0011 on most of our objects (especially codeunits) and decided to put all on Internal in a first step.
However, lots of our codeunits use the pattern below (~ method codeunit pattern)
If we set the Access to Internal on codeunit level, all provided integrationevents become useless (except for internal codeunits that are used within our own apps, which receive access through the InternalVisibleTo property. For those, we can add a #pragma to skip the newly requested warning).
Requirement
Please add a new rule that verifies if an IntegrationEvent is part of an object that has been marked with Access = Internal and raise an Error.
Beta Was this translation helpful? Give feedback.
All reactions