editoast: add 'locked' to the schema definition of rolling stock

[woshilapin]

In the schema definition in Python, the field locked exists. However, it doesn't exist in the corresponding editoast implementation.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.

Project coverage is 37.07%. Comparing base (a5e9ca2) to head (c5b693a).
Report is 18 commits behind head on dev.

Files with missing lines	Patch %	Lines
editoast/src/models/rolling_stock_model.rs	50.00%	1 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff            @@
##                dev    #9024   +/-   ##
=========================================
  Coverage     37.07%   37.07%           
  Complexity     2241     2241           
=========================================
  Files          1262     1262           
  Lines        115972   115974    +2     
  Branches       3277     3277           
=========================================
+ Hits          42994    42995    +1     
- Misses        71024    71025    +1     
  Partials       1954     1954           

Flag	Coverage Δ
core	74.79% <ø> (ø)
editoast	72.38% <50.00%> (-0.01%)	⬇️
front	15.16% <ø> (ø)
gateway	2.22% <ø> (ø)
osrdyne	2.57% <ø> (ø)
railjson_generator	87.49% <ø> (ø)
tests	86.46% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[leovalais]

LGTM.

However I'm not sure it makes a lot of sense to have a locked field in the schemas at all. The field (which also exists for infrastructures) exists to prevent modification of the resource. When the permission system will be up these fields are likely to disappear since they're functionally equivalent to a share at the READ privilege level. That's why from a separation of concerns perspective I'm not sure we want to expose our current lack of resource control in the schemas. Maybe @flomonster has a better overview of the subject.

In any case, there shouldn't be any mismatch between osrd_schemas and editoast_schemas one way or the other.

[flomonster]

However I'm not sure it makes a lot of sense to have a locked field in the schemas at all. The field (which also exists for infrastructures) exists to prevent modification of the resource. When the permission system will be up these fields are likely to disappear since they're functionally equivalent to a share at the READ privilege level. That's why from a separation of concerns perspective I'm not sure we want to expose our current lack of resource control in the schemas. Maybe @flomonster has a better overview of the subject.

You are right, the locked field will disappear with the permission system.

The reason we did not expose this field is because the RS editor does not permit to edit it. It is only used during the import.

[woshilapin]

Does that mean that in the meantime, we're ok with the difference between osrd_schemas and editoast_schemas, until permission system appears and then, we'll remove it everywhere from osrd_schemas?

[flomonster]

Does that mean that in the meantime, we're ok with the difference between osrd_schemas and editoast_schemas, until permission system appears and then, we'll remove it everywhere from osrd_schemas?

I prefer to merge this PR and try to make osrd_schemas match editoast_schemas.