[FEATURE REQUEST] Validate requested object ID's in a pipeline about al-objid

[TeusV]

The main problem with the scenario I added above is that you might have object ids in use without them being reserved, which was not visible in any way when using an app pool. The new feature warning N0301 is great for tackling this; we can even promote this to an error and having pull requests fail on it. As you explained, not 100% reliable, but this happening should be rare and in most of those rare cases it is now detected before it becomes a problem. Thanks a lot again!🙏

[TeusV]

Another scenario for which this would be useful: when someone types over the intellisense suggestion instead of using autocompletion. (Which is in fact of course another way of not using AL Object Ninja ID)

[vjekob]

Another scenario for which this would be useful: when someone types over the intellisense suggestion instead of using autocompletion. (Which is in fact of course another way of not using AL Object Ninja ID)

I agree that this would be cool. However, can you create a separate issue for this so it can be tracked separately? It's not exactly the same request as proposed by Arthurvdv.

[vjekob]

And what if one developer in my team doesn’t want to use it? Well, then you are on your own. Back to Excel sheets, or yelling, or whatever works better for you.

The problem of the rogue employee, creating a object ID outside AL Object ID Ninja, is that the person behind him/her wil use this object ID again and wil have the problem on the merge of the pull-request.

It would be great to validate in a CD/CD pipeline to be sure the that all the object ID's are requested though AL Object ID Ninja. If not throw a warning, so the developer is forced to resolve that issue in the pull-request.

..if possible a nice-2-have would be that if the object ID that is created still is available it will automatically assign in AL Object ID Ninja

Thanks for your proposal, and sorry for my long absence here.

Anyway, I can see this from your angle, but how exactly would you propose I implement this? There is no clean solution that is 100% reliable.

Imagine this scenario: Developer A creates an object, ignores Ninja's suggestion and types the ID manually. Developer B creates an object and accepts Ninja's suggestion. At this time, both devs A and B have the same object ID. Dev A creates a PR. Your pipeline at this time checks for validity and sees that this ID has been assigned by Ninja and accepts it. Dev B then creates their PR, and this one fails because of ID collision.

The only way in which this kind of check would work is if dev B didn't yet assign the object ID by Ninja at the time dev A's PR is being processed by the pipeline.

The only way how I can see this happening is by adding extra artifacts to the repo, so when a dev assigns an object ID, this information is stored as a new file in some Ninja folder, so that the pipeline can validate that.

If you have any suggestions on the technical aspects of the enhancement you propose, please share them.

[vjekob]

I am adding the "wontfix" tag to this for now. If you provide a good idea on how to technically solve this problem, I'll gladly remove that tag.

I'll keep the issue open for a while to solicit comments from you or the others.

[vjekob]

No comments arrived on this. I am happy to reopen this feature in the future if I get good suggestions about how to keep track of which object ID assignments are valid, and which are not, from within a pipeline.

Take a look at Ninja v2.11.0 and the features it includes to help with managing unassigned and manually assigned object IDs.