search

vjekob / al-objid

Manage object IDs in multi-user environments with mind-boggling simplicity.
MIT License
29 stars 17 forks source link

Suggest ID from multiple ranges #11

Closed kaspermoerch closed 2 years ago

kaspermoerch commented 3 years ago

Scenario

You are working on a project where you have multiple id ranges in app.json. This could be e.g. if you code your app and tests in the same app and then remove the tests in a build pipeline or maybe you have multiple ranges assigned to your app.

The problem

When assigning a new id AL Object ID Ninja suggest the first available ID. If I want to assign an ID from another range, I need to do that manually and then synchronize with AL Object ID Ninja backend.

The solution

AL Object ID Ninja should suggest the first available id from all the ranges in app.json.

vjekob commented 3 years ago

This is probably going to be a configuration setting where you can switch this behavior on or off. If on, it would offer you multiple IDs and it would only commit the one from the range you choose.

What would you have it do when for example you explicitly choose a number from a range, but by the time you select that number in the dropdown list it is already unavailable (assigned to someone else) and there are no more numbers left in that sub-range?

kaspermoerch commented 3 years ago

If it is possible intellisense should be rerun and then there would be no suggestions from the depleted range.

Alternatively it should do the same as when a range is depleted when you only have one range in your app.json (I haven't encountered this situation yet, so I don't know what it does in this situation).

fvet commented 3 years ago

This option would open up some possibilities to start using Object ID Ninja for ALL our apps, especially those legacy apps with overlapping ranges between object types - including our largest Base Application - and could eliminate the need for App Pooling for most of our apps.

Some background:

In the past, we assigned id's to tables from range 1, mixed with codeunit id's from range 2 for feature A. Plus we assigned table id's from range 2, mixed with codeunit id's from range 1 for feature B.

In an attempt to move functionality into separate extensions, we ended up with extension A (for feature A), containing range 1 (for the tables) and range 2 (for the codeunits). Plus another extension B (for feature B), also containing range 1 (for the codeunits) and range 2 (for the tables). These cannot be managed by Object ID Ninja up to today, maybe with App Pooling we'll be able to manage these legacy cases.

I was thinking of keeping the idranges (1 and 2) in the app.json files for both apps, to still support the legacy objects (because they are required for MS), but not use these ranges for new object id assignments. If I would be able to assign a new range 3 in extension A and a new range 4 in extension B, and use these range as preferred / dedicated / mandatory range for any new objects, I could start with a fresh range for both apps new objects and avoid picking id's from legacy overlapping ranges.

If you would add a configuration setting, you might consider adding an option to 'block' a range (in the Range Explorer, right click on a range and select 'block / disable') from allowing new object id reservation (I don't know if allowing the developer to choose from multiple ranges if (s)he gets a proposed id, is the right thing to do, since the developer really does not care which range to choose from)

PS: For new extensions, we always assign a dedicated range, so these are fully managed via Object ID Ninja.

vjekob commented 3 years ago

No need to explain why this is needed :) I'll definitely add this, don't worry!

vjekob commented 2 years ago

This feature is now released in 2.4.0.

More details: https://github.com/vjekob/al-objid/commit/49119425cf935306b031b7551685b533d1927c01