TS Implementation for Sheet Indexes

[Ellord207]

Context:

My team is working on creating features to facilitate the production of 2d drawings and sheets for users using iTwin.js. To do this, we need to be able to insert Sheet Indexes and their relational elements into the iModel. Since there are no Sheet Index TS implementations, we took the initiative and started creating them ourselves.

I have created an accompanying Discussion Post as a more appropriate place for this discussion.

Description

After discussions, I am intending this PR to include the basic implementations for the Sheet Index. This including backend Classes, common props, Codes, and tests.

After more discussion, future PR(s) will follow to answer the following questions:

• How to ensure a consistent order of the Sheet Index Entries during editing, specifically including when using SheetIndexReferences among other scenarios.
• How to automatically generate and update sheet labels/page numbers during editing.
• Enforcing the 1 SheetReference per Sheet rule.
• And possibly other limitations to ensure consistency across the platform.

[Ellord207]

Is this necessary? This steps feel like it should already have happened. Is this what was meant by, "Ensure the new codes are included in pre-existing iModels"?

[diegoalexdiaz]

I'll defer to @aruniverse to investigate and confirm this question.

[pmconne]

Built-in code specs are registered in native code when creating a new DgnDb by DgnDb::CreateCodeSpecs.
That function notably does not register sheet index-related code specs.

[pmconne]

CodeSpecs use server-issued Ids. There is some attempt to prevent conflicts between briefcases. I think you will need to make your createCode functions ensure that they register the relevant CodeSpec if not already present in the iModel. You may wish to add documentation to your new BisCodeSpec members indicating that they are only created in an iModel on first use.

@khanaffan should we consider a DgnDb schema upgrade that adds these code specs if not present?

[Ellord207]

Updating the iModel indirectly seems like a side effect we should avoid, but I'm not sure if there's an instance where a user would want to create a code an not immediately update the iModel with a new element. Plus, I can't think of a more elegant way.

Implemented as suggested

[khanaffan]

Yes we can.

[khanaffan]

Though feel like we should have different approach where its like define in custom attribute in BisCore. So we do not have to add them via profile version change instead biscore can be modified to add builtin code that will exist in seed file or upgraded file. So we can tie it to biscore rather then runtime.

[pmconne]

@khanaffan can you ping me sometime today to clarify your suggestion please?

[pmconne]

Please link to the Sheet Index section of docs/bis/domains/drawings-sheets.md where people can learn what a sheet index is.

[Ellord207]

Added a URL to the doc site. I wasn't sure if there's a better way to do that or not. If there is, I couldn't find an example of it in the repo.

[ben-polinsky]

You can use $docs to reference the base url without hard coding a specific environment. Something like: [SheetIndex]($docs/bis/domains/drawings-sheets#sheet-index)

[Ellord207]

Thanks for the suggestion. Updated

[pmconne]

Too many args here and in insert, same for SheetIndexFolder and SheetReference methods. Consolidate into an "arguments" object so people can't screw up the order of the 4 string arguments.

[Ellord207]

Refactored