[Feature / Fix request]: Allow standalone environment to be an effective write OR read mode

[louisgreiner]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Request type

Request for enhancement of a component

Functionality

Description

Currently, the standalone environment is read mode by default. This doesn't allow to work with restricted actions on network graphics. Also, standalone environment can be seen as a hack or a bug, as it works by using read mode, but still allowing changes from user.

What we currently have:

• Write mode
  • Normal environment (used by SBB internal + Flatland demo / non archived + write access) : all functionnalities, back-end included
  • Standalone environment (not used) : impossible (standalone environment is read-mode by default)
• Read mode
  • Normal environment (used by SBB internal + Flatland demo / archived + non write access) : all functionnalities but changes not allowed, back-end included
  • Standalone environment (used by OSRD integration + GitHub Pages demo) : all functionnalities, back-end excluded

For standalone environment, we also need to disable the ability to make changes to a network graphic (= just visualize and move through loaded network graphic).

For this, we need to be able to set write or read mode for the standalone environments too.

Acceptance criteria

• standalone environment remains working without running back-end
• an instance of standalone environment can be set as write mode (= current functionnalities of the standalone read mode)
  • all functionnalities allowed
  • still no persistance
• an instance of standalone environment can be set as read mode (= same functionnalities as an archived variant)
  • create, update (drag nodes included) not allowed
  • still no persistance

Proposition

• The authorization mode (write / read) could be set as a global setting in the netzgrafikDto not great
• or, as sbb-root global attribute ?

The framework implemented for setting write or read mode is difficult to work with (let's say, i.e., here). Perhaps this feature might lead to a refactor ?

Link to design proposal file

No response

[aiAdrian]

General Behavior / Requirements Implemented

User Rights

The Netzgrafik-Editor allows for managing user rights on a project basis. This means decisions are made regarding:

• Whether a user can view a project.
• Whether they have write or read-only access.

This rule is central to the functionality of the application.

Version Control

A user's write permissions are checked using the getVariantIsWritable() method of the versionControlService. This ensures that only authorized users can make changes to the Netzgrafik projects/variant.

Backend Settings

In the environment, it is specified whether the application has a backend. If a backend is not present:

• The auto-save mechanism is disabled.
• The authentication service is set to passive, meaning the user does not have to log in.

User Interface

In the user interface, the view of versions is removed when there is no added value for the user. This helps improve the user experience by hiding unnecessary information.

What Can Be Done (Refactoring)

Disabled Backend (Standalone)

If the application doesn't have a backend, the read/write permissions should not be controlled through this flag.

Read/Write Mode

Variant 1

If the application has a backend, the version control should remain unchanged, allowing full control through the backend. If the application has no backend, the environment should determine whether read or write mode is enabled. This requires a new variable in the environment.

Variant 2

It doesn't matter whether the application has a backend or not. If the backend exists, it controls the read/write permissions of each user. However, if the environment has a boolean variable that globally removes write permissions, then no user will have write access; everyone will only be able to view the project, provided they have the required rights (read or write). If there is no backend, this variable will take full control of the read/write permissions.

Next Steps

• Variant Decision: Determine which variant needs to be implemented to fulfill all the requirements. Variant 2 may offer more flexibility.
• Analyze and review the requirements again.