lvlOverride logic adjustments

Moi 😃

Currently concrete numbering related to overwriting starting value is applied to one level only.

Sometimes users want to start next concrete numbering with other level, than first one, but if we keep “overrideLevel” logic as it, numbering would be continued. Here is how it looks like: (pref 1.2 meant to be pref 1.1 since its restarted)

In order to fix this behaviour we have to be able to generate similar xml to this:

And this is the reference to the place where its hardcoded: https://github.com/dolanmiu/docx/blob/563e10fa92d206fdad897f243994386a5437e8a0/src/file/numbering/numbering.ts#L214

Potentially we can just propogate override for all levels with number 1, if instance has changed…But that would not be flexible e.g. you would be able to start with 10.1.1 after reset, but wouldn’t be possible with 10.1.10

The best way, I guess, is to give extensive control over which level has to be actually reseted e.g. [{lvl: 0, start: 1}, {lvl:1, start : 10}]

[anti-the-social]

Yep, it does sound to me as a quite a break changes. instance at IConcreteNumberingOptions seem to be not enough to be “as flexible as possible”

Nevertheless, we have an option where instance would just set all levels to 1 and optional overrideLevel.start would modify first level only. That might stay compatible with old versions…

[dolanmiu]

Closing as fixed by https://github.com/dolanmiu/docx/pull/1823