This commit reworks the way the edit mode is left, from the client
action. It does 2 things:
1/ It keeps the SnippetsMenu as long as the iframe is reloading. Once
everything is ready, the SnippetsMenu is removed with a transition.
2/ It prompts the "Discard your changes" modal when switching language in
edit mode.
1/ Before this commit, the WysiwygAdapter was dismounted before
reloading the iframe. It was simpler this way, because the OdooEditor
has set some listeners on the editable document, which will crash during
a reload of the iframe.
Now, in a leaveEditMode method, the WysiwygAdapter will make a copy of
the snippet's menu html element, and display that skeleton while the
editor is destroyed.
It will also check if the editable is dirty and prompt a
modal to the user if needed, as it was before.
Some of the code to display that "fake" snippets menu is shared with the
Editor component which uses it to unmount and remount the WysiwygAdapter
while reloading the iframe (in a _getDummySnippetsEl method).
2/ With that, the quit method, passed as a prop to the WysiwygAdapter,
and played in the new leaveEditMode method, is updated with two
parameters: an onLeave function that will be played when the component
is unmounted, and a reloadIframe boolean.
As the WysiwygAdapter listens to a new 'LEAVE-EDIT-MODE' event using
these parameters, it allows for any website component to request leaving
the edit mode, with a reload or not, and execute an action after that.
This fixes [1], which was leaving the edit mode without going through
the WysiwygAdapter, and so, without checking if the editable was dirty
or not (i.e. without prompting the "Discard your changes" modal).
Related to https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[1]: https://github.com/odoo/odoo/commit/11429329b8dea2dd0b2496dc8c1c8627751cccff
task-2687506
Part-of: odoo/odoo#97408
Before this commit:
Conversion of list element to paragraph block was not possible, as Text from
command-list was only changing the tag of a selected element, not the list tag.
After this commit:
Now list element can be converted to a paragraph block when the Text block is
selected.
Task-2826472
closesodoo/odoo#99325
X-original-commit: 96ac829e0dc512350f5a828702c20d44219cc933
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Non total order can lead to randomized order in some case, making some
test behaviour random and/or difficult to debug.
Adding some fallback 'id' order shouldn't hurt
closesodoo/odoo#99324
X-original-commit: 6e40e5fe775273a2d3a968ac113cbeb578318dd1
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
The new structure of X2manyField stores ListRenderer in its components.
PortalUserX2ManyField is not using that structure properly. Therefore,
PortalWizardUserListRenderer it is not found nor used correctly.
This commit correctly places that List Renderer in the components.
Task-2968411
closesodoo/odoo#99320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The test is currently disabled on runbot and breaks every night. Update the
counter to check if it is still random.
Task-2925606
closesodoo/odoo#99305
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the legacy implementation of FieldMany2ManyTags, we instantiated
a FieldMany2One with the attrs of the many2many field node. As a
consequence, the FieldMany2ManyTags honnored its own options and
all options supported by the FieldMany2One.
In the new implementation, before this commit, we lost the support
of the Many2ManyField's specific options, in particular "no_create"
and "no_create_edit". This commit fixes that issue.
With this commit, the FieldMany2ManyTags also takes into account
the "can_create" attribute that is automatically set to "0" by the
framework if the user hasn't the required access rights.
Note: Many2OneField options is a mess, it would be nice to
refactor and simplify them in the future.
closesodoo/odoo#99283
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
3c28be1b33ea18be7280d9372ebd53a54140da86 enforced readonly by default on
computed and related fields, but Activity/note was not adapted to be
readonly, leading the application to crash when editing a note.
This commit fixes it by introducing a new field to write on instead of
the computed one.
Follow-up of task-2955927.
closesodoo/odoo#99310
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
These are buttons that happen to be inside dropdowns so the
preventDefault must be done in that case otherwise the selection of the
user is lost and the edition command cannot work.
Steps to reproduce:
- Select some text
- Try to use the justify buttons that are inside the text alignment
dropdown in the toolbar
task-id 2964314
closesodoo/odoo#99300
X-original-commit: 8a124a9342fc0f7091b78b45d9b7fe13db472927
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
3c28be1b33ea18be7280d9372ebd53a54140da86 enforced readonly by default on
computed and related fields, but some fields were not changed to be
readonly, leading the application to crash when editing them.
This commit fixes that by introducing new fields to write on instead of
the readonly ones.
Follow-up of task-2955927.
closesodoo/odoo#99253
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Since odoo/odoo#96545 the number of half-days remaining were not
correct. It was showing the number of hours as days.
task-2964068
closesodoo/odoo#99055
X-original-commit: 8734ea55b4070fcc361d395923621bede94c1998
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
In some situation, Chrome "loses" an already loaded lazy-loaded image
when it is moved across nodes in the DOM. This typically happens when
wrapping an image inside a link.
Note that the DOM is actually correct: if the page is saved it then
displays it correctly.
This commit detects if this problem happens when adding a link on an
image, and forces Chrome to re-display the image by re-specifying its
`src` attribute. No alternative solution was found.
Steps to reproduce:
- Use a brand new incognito Chrome window. (Make sure you closed any
previously opened incognito Chrome window before)
- Drop a "Text - Image" snippet.
- Save.
- Edit.
- Select image.
- Press "CTRL+K".
=> The image was not displayed anymore.
task-2962619
closesodoo/odoo#98889
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when the website UI was moved to the backend, the edited page
is inside an iframe in Chrome. Conditions based on instanceof are not
reliable anymore: the element's type is specific to the document inside
which it was created. Because of this,
`targetEl instanceof HTMLElement` is `true` when the snippet was dragged
from the options menu - because both `targetEl` and `HTMLElement` are
the ones from the main document where the editor options panel is.
But it is `false` if the page was loaded because the `targetEl` is of
a type from the iframe's document.
We cannot use `targetEl.ownerDocument.defaultView.HTMLElement` because
the `ownerDocument` is the current one to which the target belongs - not
the one where it was created. So, a full condition would have to look
like this:
```js
(targetEl instanceof this.odooEditor.document.defaultView.HTMLElement
|| targetEl instanceof HTMLElement)
```
That is pretty verbose, so I check the `nodeType` instead.
Steps to reproduce:
- Use Chrome.
- Drop a "Text - Image" snippet.
- Save.
- Edit.
- Select image.
- Press "CTRL+K".
=> An `<a class="oe_edited_link">` is created instead of triggering the
image link tools - as if it was a text selection (except the text link
tool is not available).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2962619
Part-of: odoo/odoo#98889
Before this PR, disconnecting the websocket for a keep alive timeout
would skip the terminate method. When the loop would exit, gevent loop
will keep running and use the CPU up to 100%. This commit ensures the
termiante method is called when disconnecting due to a keep alive
timeout and solves this issue.
closesodoo/odoo#99308
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, the list view crashed when it was grouped if
there was a button column in between two "aggregatable" fields
columns. The reason is that "formatAggragatableValue" makes sense
only on field columns, and it crashes when called on a column of
another type. It was for instance the case in the Stock > Locations
list view.
closesodoo/odoo#99289
Signed-off-by: Georis François (fge) <fge@odoo.com>
Before the form merge we had
```html
<o_action>
<o_content>
<o_form_view oe_form_configuration>
</o_form_view oe_form_configuration>
</o_content>
</o_action>
```
now we have
```html
<o_action o_form_view>
<o_content>
<oe_form_configuration>
</oe_form_configuration>
</o_content o_form_view>
</o_action>
```
So we have to adapt form_controllers.scss to match this new structure.
closesodoo/odoo#99280
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After https://github.com/odoo/odoo/pull/78439 and before this commit,
the `activeRtcSession` was a field of `callView` which is the same view
for all channels. Which means that setting an `activeRtcSession` would
display it for any channel instead of only the channel that hosted this
session.
This commit fixes this issue by moving the field to the `Channel` model.
closesodoo/odoo#99270
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Have a quick create view in kanban that has a legacy many2one
field (not yet converted to the WOWL framework for some reason).
Click on that many2one to see the dropdown of propositions.
Click on one proposition.
Before this commit, the quick create got closed, because we clicked
somewhere outside of it (the legacy dropdown).
This is a known, quite common issue in some other part of the codebase
(see d3662d370c).
After this commit, the quick create works as expected.
closesodoo/odoo#99241
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Prior to this commit, there was no space between the author's name and
the message.
This commit fixes this issue.
closesodoo/odoo#99235
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Edit a domain in the debug text area of a domain field in debug mode
was possible but the value displayed in the text area was reset to the
value displayed in the part above. For instance, starting with a domain
field value like "[('id', '=', 1)]" then editing it in the text area to
be "[('id', '=', 3)]", the value for the domain field would be correctly
updated but the value displayed in the domain field would be the initial
value "[('id', '=', 1)]". We fix that by making the DomainSelector
component accept an extra prop "debugValue" to be displayed in the debug
area instead of the prop "value" if it is defined.
closesodoo/odoo#99207
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Setting [(1, "=", 1)] as domain in the debug text area would make crash
the DomainSelector component because the sub component ModelFieldSelector
would not accept 1 as a fieldName prop due to its props validation. We
fix that by converting 1 to a string.
Part-of: odoo/odoo#99207
Co-authored-by: Michael Mattiello (mcm) <mcm@odoo.com>
Before this commit, the required attribute has no effect on the x2many
fields. It will always be valid unless one of its records is invalid.
Problem:
In some cases, we would like to be able to make some x2many fields
required. For example, many2many_tags should be invalid if it contains
no records.
In legacy, if a field is required, then it has the responsibility to
evaluate if its value is valid. To do this, each field contained the
isSet function which returns true if the value is set.
In our new architecture, it is the model that evaluates if the value of
a field is valid based on the field type. It is therefore no longer
possible to customise the evaluation of the validity of a field based
on the FieldComponent.
Solution:
This commit will reintroduce the possibility to customize the evaluation
of the validity of a field based on the FieldComponent.
To do this, we add the possibility to define a static isSet function
on the FieldComponent. If this function is present, it will be used
to evaluate if the field value is set or not.
closesodoo/odoo#98873
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit:
===================
GST Treatment(l10n_in_gst_treatment) is not set when create invoice from POS.
After this commit:
==================
GST Treatment(l10n_in_gst_treatment) is set when create invoice from POS.
closesodoo/odoo#99131
Signed-off-by: Josse Colpaert <jco@odoo.com>
In form views, when wrapping <field/> nodes
within a <t/> node to set a group,
the web client no longer set the field labels before the field.
Therefore, remove these <t/> node before sending them to the
web client.
e.g.
```xml
<group>
<field name="origin"/>
<field name="date_deadline"/>
<t groups="stock.group_stock_manager">
<field name="analytic_account_id" groups="analytic.group_analytic_accounting"/>
</t>
</group>
```
closesodoo/odoo#99266
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Prevents calling `querySelector` on `undefined` on mousemove in document
because of failing to check for the existence of an object, makes sure
to restrict to the editable area, and that the table ui always starts
invisible.
closesodoo/odoo#99255
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Confirming a PO with a customer as delivery address does not work
To reproduce the issue:
1. In Settings, enable "Multi-Locations"
2. Create two products P_finished, P_compo
- P_finished:
- Add a vendor V
3. Create a bill of materials:
- Product: P_finished
- Type: Subcontract
- Subcontractor: V
- Components: 1 x P_compo
4. Create a PO:
- Vendor: V
- Products: 1 x P_finished
- Deliver To: Dropship
- Drop Ship Address: a customer
5. Confirm the PO
Error: a validation error is displayed: "[...] a mandatory field is not
set. [...] Model: Production Order (mrp.production), Field: Operation
Type (picking_type_id)"
When confirming the PO, we extract some values of the subcontracted SM
to create a MO:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L105-L117
However, because the SM is not created from the SO, it does not have any
`sale_line_id`. And, because its a dropshipped one, neither the SM nor
its picking type has a defined warehouse. As a result, `_get_warehouse`
does not return anything and we can't define the `picking_type_id` of
the MO. This is the reason why the error will be triggered on its
creation.
OPW-2922546
closesodoo/odoo#99223
X-original-commit: 28a20daab6a7097ecd26bf66eeb80b2f5ad294a8
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
This PR changes the way notification are displayed inside the a channel.
Currently, notification look exactly the same as a message send by the user.
task-2918956
closesodoo/odoo#98262
Related: odoo/enterprise#30732
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
**Template Access Issue**
Followup of odoo/odoo@1a3e713c99
Bug
===
If the user doesn't have the template editor, he cannot open the template
preview.
Technical
=========
The reason for that is because the web editor moves some CSS properties,
and so when the user tries to open the preview, an access error is raised.
1. Ideally, the template form view should not be editable if the access
rules do not allow it. But in `_postprocess_tag_field`, we only check
for access right because we don't have the record. So a user without
write access rules, but having write access right can edit the template
in the UI, and gets an error when saving.
2. Also, the web editor should not save the HTML value if no change are
made on the field (like all other text / char field).
To mitigate the issue in stable, we add a computed field that check the
access rules and make the body readonly if he can not edit the template.
So the web editor is not loaded, the CSS properties are not moved. Other
possible solutions are way to complex technically speaking (editor internals
to update in frontend, complex comparison of html blobs in backend, cache
usage making fields_view_get override not working in all cases, ... )
As the HTML body look weird in readonly mode, add the same border as the web
editor.
**Ir.Model Issue**
A user without administration right can not preview a mail template because
of the ACl on the <ir.model>.
Task-2845877
closesodoo/odoo#99256
Forward-port-of: odoo/odoo#99222
Forward-port-of: odoo/odoo#94418
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Bug
===
A user without administration right can not preview a mail template because
of the ACl on the <ir.model>.
Task-2845877
X-original-commit: 087875594daefe487a5988a56c298af844d21dfb
Part-of: odoo/odoo#99256
Followup of odoo/odoo@1a3e713
Bug
===
If the user doesn't have the template editor, he cannot open the template
preview.
Technical
=========
The reason for that is because the web editor moves some CSS properties,
and so when the user tries to open the preview, an access error is raised.
Ideally, the template form view should not be editable if the access
rules do not allow it. But in _postprocess_tag_field, we only check
for access right because we don't have the record. So a user without
write access rules, but having write access right can edit the template
in the UI, and gets an error when saving.
Also, the web editor should not save the HTML value if no change are
made on the field (like all other text / char field).
To mitigate the issue in stable, we add a computed field that check the
access rules and make the body readonly if he can not edit the template.
So the web editor is not loaded, the CSS properties are not moved. Other
possible solutions are way to complex technically speaking (editor internals
to update in frontend, complex comparison of html blobs in backend, cache
usage making fields_view_get override not working in all cases, ... )
As the HTML body look weird in readonly mode, add the same border as the web
editor.
Task-2845877
X-original-commit: dcf3ab5fb41aa9ef6e59b2155bfd192e551b6476
Part-of: odoo/odoo#99256
The constraint can crash if the zip is not defined.
Check that the zip exists to prevent the error.
closesodoo/odoo#99250
X-original-commit: bc9fb51b9b22419cda94d845ef51dbddd8878276
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Before this commit, when the portal user changes the stage of a task and
the new stage contains a rating template email, he got a traceback
saying he has no access to `mail.template` model.
This commit fixes the issue by sending the email in superuser when we
are sure the user can write on that task.
Steps to reproduce:
==================
1) Enable the rating feature in the settings of Project App
2) Create a Project A and edit it to enable the rating feature on that
project and select "Rating when changing stage" (if it is not already
the case)
3) Set a rating email template on a stage of the project
4) Create a new task and save
5) Change the stage of that task to the stage contained the rating email
template
Actual Behavior:
---------------
A traceback is occurred saying the user has no access to `mail.template`
model.
Expected Behavior:
-----------------
The stage of the task should be changed and the rating email should be
sent.
closesodoo/odoo#99248
X-original-commit: c5093988411e5697f49ca2a128e93203c2d6aac9
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Xavier <xbo@odoo.com>
The test `test_option_creation` makes sure the option uom is
well set once setting the product on the order.
But, the test doesn't add the group_uom to be able to see the uom
field within the view.
This is valid, the uom should nevertheless still be set correctly
automatically, but the assertion must be done on the saved record,
not in the form view itself, as the field is not displayed in
the form view in such a case.
closesodoo/odoo#99231
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
- Manufacturing app > Operations > Manufacturing orders > Create
- Set product to [FURN_7800] Desk Combination > Save > Confirm
- Click on scrap, choose any product > Done
- Edit the manufacturing order > set the quantity to 1/1 > Save
An error pops up: You cannot change the UoM for a stock move that has
been set to 'Done'.
This happens because the scrapped product has its destination location
wrongly set to the production location of the manufacturing order.
Because of this, it is considered as a component of the manufacturing
order. The scrap is also confirmed right after creation, so its state
is set to 'done'. Finally, when confirming a manufacturing order, all
of its component moves are also confirmed, hence the error.
This commit prevents the override of the scrap's destination location,
so that it is not wrongly considered a component anymore.
The commit also adds tests for the override method, added in
commit 0b247ab17ccc5be0c2058ef92ccf3502c97e0bb3
opw-2945182
closesodoo/odoo#99218
X-original-commit: 81820d4df5f23d9b6b2701e513ada89b528a865a
Signed-off-by: Adrien Widart <awt@odoo.com>
The TablePicker didn't take into account the position of its parent
iframe when positioning itself, and failed to bind its events on the
document in which it was attached. This led to wrong positioning and
interaction failures.
closesodoo/odoo#99208
X-original-commit: 3bb0aaaa0833e3d72fbb07e47e42441e293babb7
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Have a grouped kanban which display a priority field widget.
Quick create a record.
Click on any priority widget to change the priority.
Before this commit, the model was still considered in edition, preventing any change
in other record. Hence, the priorities did not change (at least, there was no write operation)
when clicked on.
After this commit, this flow works as expected.
closesodoo/odoo#99199
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When profiling an HTTPCase the only result will be the starting of the
browser and the ready/ok code. All requests are in other thread
and are not profiled.
HTTPCase profiler will now patch the _get_profiler_context_manager
in order to enable profiler on all requests during this time
closesodoo/odoo#99119
X-original-commit: 77d110de242c8b8e9b0f09dcecad25c203f32535
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit standardizes the API of orm service functions by adding
a "kwargs" parameter, s.t. one can always use those functions even
if the target model overrides the corresponding method to add the
support of a given kwargs. Furthermore, to simplify those function
API, and to close the gap between the js and python APIs, we moved
the "context" argument inside the kwargs.
closesodoo/odoo#99018
Related: odoo/enterprise#30830
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit changes the API of the "create" function of the orm
service to better reflect the API of the corresponding method in
models.py, which takes a list of record values in argument.
Before this commit, a call to "create" only allowed to create a
single record.
Part-of: odoo/odoo#99018
Before this commit, the "read" function of the ORM service didn't
allow to pass any kwargs. As a consequence, it wasn't possible to
call the "read" method of a model with "load" kwargs specified.
This commit fixes the issue, and adapts existing calls accordingly.
Part-of: odoo/odoo#99018
Before this commit, most functions of the orm service whitelisted
the kwargs to pass to the call of the python method. This would
make the service unusable on models that override those methods to
add the support of new kwargs. This commit removes the whitelisting
s.t. the service simply propagates all given kwargs.
Part-of: odoo/odoo#99018
Younn Olivier