Suggest ID from multiple ranges about al-objid

[vjekob]

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

[vjekob]

This feature is now released in 2.4.0.

More details: 4911942

[vjekob]

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]

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]

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.