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

lmr: front: pre-fill the total weight, length, and max speed of the consist when selecting traction engine and towed rs #9712

Closed
8 tasks
axrolld opened this issue Nov 14, 2024 · 11 comments
Assignees
Labels
area:front Work on Standard OSRD Interface modules kind:enhancement Improvement of existing features module:stdcm Short-Term DCM

Comments

@axrolld
Copy link
Contributor

axrolld commented Nov 14, 2024

Description

Note

Missing (compo code; max speed) map for now

Pre-fill the total weight, length, and max speed of the consist when selecting traction engine and towed rolling stock.

AC

  • Selecting the traction engin pre-fills the total weight, length, and max speed of the consist.
  • Selecting the towed rolling stock updates the values
    • Length = length of traction engine + length of towed rolling stock
    • Weight = weight of traction engine + weight of towed rolling stock
    • Max speed = minimum between speed of traction engine (if not 0) and speed of towed rolling stock (if not 0).
  • Changing the traction engine or the towed rolling stock also updates the values.
  • The value of the max speed must be updated when changing the composition code (requires a map of (compo code; max speed))
  • The values manually set by the user must never be overwritten by the logics above.
@axrolld axrolld added area:front Work on Standard OSRD Interface modules kind:enhancement Improvement of existing features module:stdcm Short-Term DCM labels Nov 14, 2024
@SharglutDev
Copy link
Contributor

Note

Missing (compo code; max speed) map for now

Does it mean we don't take care of the compo code / max speed AC ?

@axrolld
Copy link
Contributor Author

axrolld commented Dec 11, 2024

Leftover work in this issue #10016

@maelysLeratRosso
Copy link

We don't close the issue since the expected behavior is not clear for the update of values. For now, the value are NEVER updated after one changes it, but it is too restrictive.
However, the expected behavior is not clear : when should we update the values and when should we not ? We (with @Arthur-Lefebvre ) think we need the opinion of @thibautsailly

@SharglutDev
Copy link
Contributor

We still miss a work in progress feature from @Wadjetz. Maybe with it, this will be a little different ? (@maelysLeratRosso @Arthur-Lefebvre)
Expected behavior : even though the user entered a max speed of 200, if he changes the rolling stock for one limited to 120km/h, the input will display a warning and will block the simulation button while its displayed.

@maelysLeratRosso
Copy link

maelysLeratRosso commented Dec 19, 2024

The warnings will improve what we can explain to the user, yes.

Here the question is : if the user writes something manually in one of these fields (length, weight, max speed), in which case do we authorize this field to be automatically updated if the default value changes (new traction engine for example) and on the contrary, when do we keep the value manually written by the user ? What we proposed with @thibautsailly is :

Imagine a value is manually written for a field. Then this value can not be automatically updated UNLESS we are in one of these cases:

  1. The page is refreshed (so the whole form can be automatically filled again)
  2. The user clicks on "New request) (so the whole form can be automatically filled again)
  3. The user erases the value in this field (for example, if the user empties the length field, then changes the traction engine, then the length field can be pre-filled again)
  4. The user makes a change on another field which makes his manual value inconsitent. For example, the manually written length is 100m. Then the user chooses a new traction engine of length 120m. So the 100m length is inconsistent, so it can be automatically pre-filled to 120m again.

Of course you can call me to see examples if the text is not clear enough :)

@axrolld You can veto if needed 😄

Note : For case 4, the warnings can later explain why we changed the value

@SharglutDev
Copy link
Contributor

1, 2 and 3 make total sense to me :)

For the 4., my understanding after some discussions with @thibautsailly (but maybe it was before yours) is that we don't want to erase an input that the user deliberately filled (and that's how we understood the issue for autofill). That's why we went for the warning option with @axrolld.

@thibautsailly
Copy link

You should not erase a value entered by the user as long as it's a coherent value.
Case 4 happens when the entered value is not. It should not happen very often (you have to declare a mass and/or a length smaller than those of the updated traction engine), and we also recommend the use of an "information" message on the field.

The message could be, for example, "the value 15m was not compatible with this traction engine, so we updated it".

Not replacing the value would mean getting an error message after clicking the simulation button, which is less helpful to the user.

@SharglutDev
Copy link
Contributor

Understood. Could you create an enhancement for that behavior ? :) We should have the time to deal with it before January 15th.

@maelysLeratRosso
Copy link

I can create an enhancement. The information message, from what I understood, may come in a second part since it is not designed yet. But we can prepare the 4 cases and once we are ready for the information message, we add it ?

@SharglutDev
Copy link
Contributor

SharglutDev commented Dec 20, 2024

We just discussed the information message with @thibautsailly, it's gonna come soon on the mockup and will probably be designed in this osrd-ui PR from @Wadjetz.

@maelysLeratRosso
Copy link

The enhancement for the new behavior : https://github.com/osrd-project/osrd-confidential/issues/903

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:front Work on Standard OSRD Interface modules kind:enhancement Improvement of existing features module:stdcm Short-Term DCM
Projects
None yet
Development

No branches or pull requests

6 participants