odoo/o-spreadsheet#6602

Created by BI, Rémi Rahir (rar)

label

odoo:master-change-load-order-rar

head

3196858a0a4a8385dea3b5fd4b2b6546dd154322

	odoo/o-spreadsheet
master	#6602 missing statuses missing r+

[FIX] Model: change load order of rangeAdapter

RangeAdapter is an esential component of the core plugin operation as it allows to change the internal ranges of all plugins with a generic transformation.
However, the current situation is not ideal as it will handle all the commands before any other plugin, including the SheetPlugin.

This is an issue because we have a 2-side approach for treating ranges:
1. the Range object which are basically a zone and a sheetId, which seems enough information to work with
2. the xc, which do not hold the sheetId information but rather the sheetName

The RangeAdapter only handles ranges which means it is not designed to react to, let's say, a sheet name change.
the opposite is true as well, XC does not care about change of sheetId.

We could think that the range needs to know the sheet name and react to such a change but the design decisions up until now were not in that favor, we designed several flows, notably commands, that rely on the information of a Range (sheetId + Zone) the migration willbe a nightmare, we'll have to transform lots of stuff but feasible.

This fix is trying to keep the current situation "a range only needs to know the sheetId and zone;, the sheetName can be handled outbound"

With this moto in mind, the problem we face is that RangeAdapter handles the 'rename_sheet' command which is sooooo specific to sheetPlugin before sheetPlugin handles it, ahd the range transformation (since the range don't know about the sheetname) cannot react properly to that change.

-> solution: move rangeAdapter elsewhere in the stack of plugins, more specifically, it be loaded just before another plugin that needs range adaptation.

NOTE

the fix suggested here does not work because we implemented some tuff in SpreadsheetPivotCorePlugin that actually relies on the fact that the transformation did not occur yet.
So on one hand, we want it to occur, for the string transformation,
on the other hand, we don't want it for the _rangeData transformation.

The real solution should probably be to force every internal structure representation to ranges? which probably means keepng some sort of compiled formula instead of formula strings

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