Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lvlOverride logic adjustments #1740

Closed
anti-the-social opened this issue Oct 26, 2022 · 6 comments
Closed

lvlOverride logic adjustments #1740

anti-the-social opened this issue Oct 26, 2022 · 6 comments

Comments

@anti-the-social
Copy link
Contributor

anti-the-social commented Oct 26, 2022

Moi :)

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

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)

image

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

And this is the reference to the place where its hardcoded:

overrideLevel:

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}]

@dolanmiu
Copy link
Owner

Hello :)

Hmm yeah I see what you mean, may require significant change in API you reckon?

@anti-the-social
Copy link
Contributor Author

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
Copy link
Owner

Do you have time to make a PR on this?

@anti-the-social
Copy link
Contributor Author

anti-the-social commented Oct 27, 2022

Which way we want to go?
I might do PR, but wouldn't promise it to be fast 😅
Lets see how critical that would be to the project I am working on.

@dolanmiu
Copy link
Owner

Sure thing

Maybe something like this could be cool:

const concreteNumbering = new ConcreteNumbering({
    numId: 0,
    abstractNumId: 1,
    reference: "1",
    instance: 0,
    overrideLevels: [{
        num: 1,
        start: 1,
    }, {
        num: 2,
        start: 1,
    }, {
        num: 3,
        start: 1,
    }],
});

So turn overrideLevel into overrideLevels breaking change? Then release 8.0.0

Also, what is your project/company? Mind if I add it to the README?

@dolanmiu
Copy link
Owner

Closing as fixed by #1823

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants