Optional actions on CrashManager #41855
Conversation
With this commit, it is possible for the CrashManager to propose actions
to the user(s) concerned by the crash/error.
If whatever triggered the exception properly wraps the exception with an
`action` attribute, the web client will display an extra button
in the error dialog, which will then launch an action programmed
by a developer.
This action can be anything, from a server action, to a view action, to
a redirect action...
This `action` attribute is essentially a list of dictionaries containing up to 4
entries, those that are required are marked with (*):
- label (*) : the label of the button displayed on the CrashManager
that will trigger the action
- action (*) : an action xmlid or a dict representing an action
- options : any additional context data for the execution of the action
- description : a message describing the action button to the user
This allows admins of databases to perform actions to fix problems on
their own or to fix their own customizations without external
intervention, it can also be used to provide support members a quick way
into the heart of a technical problem.
Task-ID: 1931559
Rationale: With base_automation, users can trigger custom code on standard workflows that will suit their specific needs (i.e. setting a field after confirming a SO). Sometimes, during these *simple* actions, an error can occur due to various variables, such as a recent migration, programming errors, module upgrades, etc., in such cases, it would be great to drop the custom behavior temporarily to restore the standard behavior, this would allow clients to keep doing business despite the reduced features. With this patch, if a base_automation triggers a crash, the crash manager will propose (to users of the base_system group) the ability to deactivate the infringing base_automation in order to continue their workflow without the need to wait for external support. Task-ID: 1931559
|
PS: I'm aware this is an IMP but it was requested for 13.0 ... |
| @@ -13,4 +13,39 @@ | |||
| <field name="active" eval="False" /> | |||
| </record> | |||
| </data> | |||
| <data> | |||
There was a problem hiding this comment.
Just realized this isn't doable in stable, we can get rid of this action and only keep the one that opens the form view of the automated action
|
I want to insist that this is just my opinion, trying to be as constructive as possible about possibilities and alternatives that could be considered to improve this feature. It might be a crappy opinion, do not take my words as the absolute truth. I was "dropped" in this task without knowing the discussions that may have already occured prior to my intervention, and I might say things that have already been discarded during these possible past discussions I am not aware of. In my opinion, things could be done to help the user to understand what happens. Currently, the buttons "Disable Action" and "Go to action" appears, and for a lambda, non-developer, user, I would say "magically":
Besides, as you figured out, this would never be able to land in stable (if we want to, as you stated, this is rather an improvement than an actual bugfix) because it relies:
I believe this would be possible to overcome both above problems by improving the JS/static Qweb template
It would be feasible to extend the static qweb template That way:
|
|
@beledouxdenis Don't worry there have been many differing opinions on this task and a lot of back-and-forth which is why the task was not merged despite it having been "ready" months ago, there's even opinions that dispute the usefulness of this feature and that it would bring more problems than it would fix :^) Idk if you're aware but the main goal of the task was to aid migrations: after the migration of a db with a lot of customizations, many different things can fail (automations, custom views, etc.) the goal was to provide something generic to disable these customizations on-the-fly so that business can continue. We thought injecting actions into the As for the explanation of what the button does, it already exists even though it is more subtle than what you suggest: the action dict injected into the exception can contain a 'description' key that will be displayed as a tooltip when you hover over the button. I think my original implementation did actually append the description to the dialog body but after a verbal discussion with @VincentSchippefilt we went for the tooltip (but my memory is not that great so I may be misremembering). Your proposal on using static xml templates makes sense for a stable but it'd mean reimplementing the whole shebang and Antony didn't want me working too much on this right now since there are other priorities (namely your branch on mapped optimizations). With all of that said, I think it's an OK compromise to just have the "Go to action" button and then add / refine in master, what do you think? |
|
I have written #42481 implementing what I suggested in my previous comment. During it I noticed there is an issue with the When I have the chance to talk with Antony, I will discuss with him how we should proceed, if we take your implementation strictly, or the one with my suggestions, or a mix of both. |
|
Closed with 8259039 |
This PR implements:
Actions to be executed in case of an Exception during a business flow (
except_orm) in the form of buttons.Two actions implemented in the case of an Automated Action that crashes:
- Disable the action (archive)
- Go to the form view of the action in edit mode (presumably to fix the action)
Crash during a business flow:
Opening the action form view in edit mode:
Disabling the action itself:
Supersedes (partially) #32876