Skip to content

Conversation

rrahir
Copy link
Collaborator

@rrahir rrahir commented Oct 8, 2025

Description:

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

Task: 5103728

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
Copy link
Collaborator

robodoo commented Oct 8, 2025

Pull request status dashboard

@rrahir rrahir force-pushed the master-lock-sheet-rar branch 6 times, most recently from 0942103 to 8dd025f Compare October 17, 2025 11:45
@rrahir rrahir force-pushed the master-lock-sheet-rar branch 3 times, most recently from 731be9b to feb52da Compare October 17, 2025 15:08
This revisions adds a (naive) protection for the full sheet.
The ability to block specific modifications (style, grid structure, etc)
is not strictly compatible with our collaborative approach as the server
is never aware of the current state of the spreadsheet.

Task: 5103728
Currently, a failed dispatch can only be caught be the original caller
as it appears in its result. This means that every individual caller
needs to handle the dispatch result if needed (see all the `interactiveX`
helpers we already added).

This works well with specific commands with specific rejections that
only concern them (paste, merge, sort), that is if there is a kind of
one-to-one relation between the dispatch and a given allowdispatch.

Considering the new addition of the `LOCK_SHEET` command, there is no
one-to-one relation. Pretty much any core/sheety command can be rejected
by the SheetLockPlugin allowDispatch and if we wanted to handle this
rejection of command, each dispatch done in the UI should handle the
specific command result of a locked sheet, which adds a ton of
maintenance.

In the past, we already faced that issue and we introduced the `UIActions`
inside the plugin to allow the plugins to send a generic signal to the
UI which could then be handled.

After consideration, the current solution seems too limiting.
For each new specific behaviour we want to introduce, we need to add
another eventType to the bus, we a limited interface so the plugins
cannot have completely random communication with the UI. It works for
limited and contextless notifications but that is it.

This commit introduces yet a new eventType on the bus that will return
failed dispatchResults, with their context of execution (the root
command) which will allow every UI component to react as they want to
any sort of scenario.

Task: 5103728
Components can now react to the model rejecteing specific commands.

With this revision, the component BottomBarSheet will capture the
commands rejected because the sheet is locked and will trigger a
specific animation to catch the user attention if they want to unlock
the sheet.

Task: 5103728
@rrahir rrahir force-pushed the master-lock-sheet-rar branch from feb52da to 2c1224f Compare October 20, 2025 08:23
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