6.6.2: Settings can't be changed by going back

[romefi]

Behavior:

• Set path, e.g. for a Geopackage in database configuration
• go to next steps
• when generate I get the error the path doesn't exist
• go back to the database configuration
• put in the correct path
• go to generate
• the old path is still used

So there's no way to change the path unless you close the wizard and start it new. This should be fixed.

[signedav]

Thanks. I can reproduce that. On already created "sessions" it does not apply the changed settings.
I need to fix that before the official release.

Not for myself: this has something to do with the _find_existing_session_widget. Should we keep already executed sessions? Should we keep the sessions created before?

[signedav]

I see now that you are talking about generating projects. I cannot reproduce the problem there.

What I can reproduce is on the import of models or transfer files, but I'm not sure how to solve it.
Of course the new setting should be considered for all the command-session that are not yet executed.
But what about the ones that are executed already? Should new command-sessions be created giving the user the possibility to start them (again)? And if so, should the finished ones still be visible?

I tended to go for the approach to recreate all the sessions, but this would lead to unexpected behavior when only a model changed. So I vanished this approach.

So first thing is to fix, that it does not update the settings. Then the behavior would look like this:

• I select db schema "kbs1"
• I select model "Kbs_LV95" and set basket_id on
• On "next": I see one unfinished session (db: kbs1, model: Kbs_LV95, basket_id on)
• I go back and turn basket_id off
• On "next" I see one unfinished session (db: kbs1, model: Kbs_LV95, basket_id off)
• I run it and I see one finished session (db: kbs1, model: Kbs_LV95, basket_id on)
• I go back and turn basket_id off
• On "next" I see still the finished session (db: kbs1, model: Kbs_LV95, basket_id on). This means I cannot run the command again with different settings
• I go back and back and choose db schema "kbs2"
• On "next" and "next" I see still the finished session (db: kbs1, model: Kbs_LV95, basket_id on) and no new one for "kbs2"
  This could be not what the user wants to see.

So there could be the approach to recreate the session when the db changed (but not every setting):

• I select db schema "kbs1"
• I select model "Kbs_LV95" and set basket_id on
• On "next": I see one unfinished session (db: kbs1, model: Kbs_LV95, basket_id on)
• I go back and turn basket_id off
• On "next" I see one unfinished session (db: kbs1, model: Kbs_LV95, basket_id off)
• I run it and I see one finished session (db: kbs1, model: Kbs_LV95, basket_id on)
• I go back and turn basket_id off
• On "next" I see still the finished session (db: kbs1, model: Kbs_LV95, basket_id on). This means I cannot run the command again with different settings
• I go back and back and choose db schema "kbs2"
• On "next" and "next" I see still the finished session (db: kbs1, model: Kbs_LV95, basket_id on) but as well a new unfinished session (db: kbs2, model: Kbs_LV95, basket_id off)

[signedav]

Hm... something I forgot in the description above.

Having Model "Kbs1" and "Kbs2" checked (1) -> next: run the session for "Kbs2" (2) -> back: "Kbs2" is now grayed out (because existing in the DB) (3) -> next: only session for "Kbs1" is visible (4)
This is IMO a good behavior.
But it should be fixed that when on on (3) settings are changed, they are considered in the session for "Kbs1" in (4)

What about skipped?
On skipping one and then going back and going on again, it's still skipped - even when the settings changed.
This is IMO a good behavior. But I suggest to not have it still skipped when the db changed - there it should be unskipped again.

So two fixes required:

• update settings in unskipped/unfinished sessions
• keep the skipped sessions on same db but not when the db changes