6

with the way id ranges currently work there's no appreciation for the lopsided way in which different object types are consumed. For example in one extension I may consume 100 codeunits and only 2 reports, but in another extension i may consume 60 reports and only 2 codeunits - this is particularly painful when using a partner app source object range as it doesn't really allow a good way to manage these object ranges so some external id logging tool has to be used and looked up every time an object is required.


if idRanges allowed something along the lines of below it would allow much more efficient use of object ranges.

"idRanges": [
    {
      "types":"all",
      "from": 50000,
      "to":50010
    },
    {      
      "types":"Table","Codeunit"
      "from": 50011,
      "to": 50200
    },
    {
      "types":"Report"
      "from": 50011,
      "to": 50030
    }
  ],

if we make the default value of types "all" then this is not a breaking change.

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

G

Yes please!I like that app.json represent the assigned ranges.Have a customer who has bought 40 tables and 100 pages. When I expand the idrange, because the first 40 pages are in use, I get no warnings to update license when table 41 is created.Or just drop the whole objectid thing ;)

Category: Development