Skip to content

Master remove UI stuff from model pro - #9473

Open
pro-odoo wants to merge 22 commits into
master-new-commands-getters-profrom
master-remove-ui-stuff-from-model-pro
Open

Master remove UI stuff from model pro#9473
pro-odoo wants to merge 22 commits into
master-new-commands-getters-profrom
master-remove-ui-stuff-from-model-pro

Conversation

@pro-odoo

Copy link
Copy Markdown
Collaborator

Description:

description of this task, what is implemented and why it is implemented that way.

Task: TASK_ID

review checklist

  • feature is organized in plugin, or UI components
  • support of duplicate sheet (deep copy)
  • in model/core: ranges are Range object, and can be adapted (adaptRanges)
  • in model/UI: ranges are strings (to show the user)
  • undo-able commands (uses this.history.update)
  • multiuser-able commands (has inverse commands and transformations where needed)
  • new/updated/removed commands are documented
  • exportable in excel
  • translations (_t("qmsdf %s", abc))
  • unit tested
  • clean commented code
  • track breaking changes
  • doc is rebuild (npm run doc)
  • status is correct in Odoo

@robodoo

robodoo commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

This PR targets the un-managed branch odoo/o-spreadsheet:master-new-commands-getters-pro, it needs to be retargeted before it can be merged.

@pro-odoo
pro-odoo force-pushed the master-new-commands-getters-pro branch from c4b8a0f to dd84037 Compare August 28, 2026 10:08
@pro-odoo
pro-odoo force-pushed the master-remove-ui-stuff-from-model-pro branch from 545d1a2 to 189ac13 Compare August 28, 2026 10:09
This commit also renames the EvaluationPlugin to CellEvaluationPlugin.

Task: 6428159
This commit introduce a new type of getters, called EvaluationGetters.
This type of getters contains all the core getters and the evaluation
ones. It's this type that should be used in the evaluation process, and
not all getters.

The aim is to ensure a clear and clean separation between the three layers:
- Core: data that should be persisted and that is the source of truth
- Evaluation: data that is computed from the core data, but that is not
  related to the UI.
- UI (stateful and feature): data that is related to the UI state.

Each layer should only depend on the layer below it, and not on the layer
above it.

The end goal of this separation is to be able to run the evaluation
process in another environment, such as a web worker, a server, etc,
without having to depend on the UI.

Note that this commit is not yet a complete separation, as some evaluation
plugins still depend on the UI. It will be fixed in future commits.
With this commit, comes a new (hopefully not for so long) registry:
`evaluationUIPluginRegistry`, which contains the UI plugins that are
used during the evaluation process. This is used to add the getters of
these plugins to the EvaluationGetters.

Task: 6428159
This commit introduces a way for EvaluationPlugin to dispatch evaluation
commands. This is useful for plugins that need to trigger evaluation
commands as part of their functionality, such as the GeoLoaderEvaluation
plugin which may need to load geo data and trigger evaluation commands
one the data is loaded.

Task: 6428159
This commit splits the geo_features plugin into two separate plugins:
geo_loader and geo_features.
The geo_loader plugin is responsible for loading the geo chart data,
which is needed for the evaluation.
The geo_features plugin is responsible for providing the geo chart stuff
for actions in the UI, such as the geo chart region selector.

Task: 6428159
…valuation commands

This commit introduces a new guard in the Model to prevent dispatching
non-evaluation commands while handling a **top-level** evaluation command.

This ensures that when an evaluation command is dispatched top-level, it
cannot create a revision or an history step.

Task: 6428159
Without this commit, the mock of Math.random() is not restored, which
could lead to error in other tests that rely on Math.random().

It's not visible now, but during the process to move the subtotal
evaluation to an evaluation plugin, the error was visible.

Task: 6428159
Before this commit, only typescript type checking was used to ensure
that plugins were added to the correct registries.
However, this was not enforced at runtime, which could lead to errors if
plugins were added incorrectly. (And of course it happened in Odoo).

Task: 6428159
This registry is not needed anymore since all the dependencies of the
evaluation process on UI getters have been removed.
The evaluation process now only depends on core and evaluation getters

Task: 6428159
@pro-odoo
pro-odoo force-pushed the master-new-commands-getters-pro branch from dd84037 to 283d82e Compare August 31, 2026 05:31
It's not a responsibility of the model to raise blocking errors to the UI.

Task: 6517821
notifyUser is a UI concern and should not be part of the model.
The way to go is to handle error at the UI level, outside of the model.

Task: 6517821
@pro-odoo
pro-odoo force-pushed the master-remove-ui-stuff-from-model-pro branch from 189ac13 to 5c5c960 Compare August 31, 2026 05:35
@pro-odoo
pro-odoo force-pushed the master-new-commands-getters-pro branch 3 times, most recently from f79e6c5 to 9b36588 Compare August 31, 2026 11:02
@pro-odoo
pro-odoo force-pushed the master-new-commands-getters-pro branch 8 times, most recently from 3b1f597 to fa9d03b Compare September 1, 2026 07:37
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

Successfully merging this pull request may close these issues.

2 participants