The cache currectly fails to correctly invalidate relational fields that depend
on a non-relational field. Two passes of invalidation are done, to reflect
dependencies on both the old and the new written values. In the first pass
only relational fields are considered, as explained in the comments:
> It is best explained with a simple example: consider two sales orders SO1 and
SO2. The computed total amount on sales orders indirectly depends on the
many2one field 'order_id' linking lines to their sales order. Now consider the
following code:
>
> line = so1.line_ids[0] # pick a line from SO1
> line.order_id = so2 # move the line to SO2
>
> In this situation, the total amount must be recomputed on *both* sales order:
the line's order before the modification, and the line's order after the
modification.
The written values can be seen as the roots of a dependency forest (a
collection of dependency trees). Before this commit all non-relational roots
and their corresponding trees were filtered out during the first pass. However,
this approach is wrong, as relational fields can also depend on non-relational
fields. Instead, the complete dependency forest has to be traversed, skipping
invalidation for non-relational fields during the first pass.
The test that was previously included accidentally succeeded because of a
separate and unrelated bug in the orm domain parser: in certain one2many or
many2many leafs the domain parser would not take into consideration the domain
included in the definition of the field. As a result, the test still passed
by accident, because the records that no longer matched the domain after the
write were still invalidated during the second pass.
The problem can clearly be demonstrated, however, when the dependency is
generated by a compute function.
closesodoo/odoo#101038
X-original-commit: d4a5827b42d80f0f830455dcd2056701eb09aed1
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Nodes like
<attribute name="t-on-dragenter.stop.prevent">() => state.dropzoneVisible = true</attribute>
should not be exported in the translations files but
<attribute name="string">Hello World</attribute>
should be kept
It was already the case in the xml processing method for server side
templates.
Since 16.0, client side QWeb views also use the same inheritance
mechanism than the one on the server side so the exception needs to be
replicated.
X-original-commit: e05d1192481935b2cd7aae7e939f98e60e002899
Part-of: odoo/odoo#101053
The test was running by luck because the event and all talk pages
contains the needed elements. The favorite was checked randomly on
other pages because those steps are way faster than loading the page.
This test will fail in rare case if the page loads faster and the step
checking if the "favorite is on" occurs when the talk page is finaly
loaded.
This commit adds some step to try to ensure the page are loaded before
doing anything else.
Also enable ticks on freezetime so that we have an idea of the steps
durations in logs for easier investigation.
X-original-commit: 8405104b14624f27df4d95e21738b253d048063f
Part-of: odoo/odoo#101050
Remove sorting rules arrays from the functions that wrap them as they
are unnecessary noise.
closesodoo/odoo#101039
X-original-commit: b37baf8996d65d639f0178651a7be0206d0679d0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit fixes some wrong usage of the bootstrap class `col` & `row`:
- POS: Missing the child `col` on `row` parent;
- Survey: Using the class `col` to center the node on the parent div;
closesodoo/odoo#101046
X-original-commit: acacf52d40a41b53aa78967748602cb3b1e62261
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the inputs (radio, check and select types) on
`focus` state wasn't visible due to the override rules in Bootstrap:
```scss
/* Example of rule for checkbox */
.form-check-input:focus {
border-color: $form-check-input-focus-border;
}
/* Default config of Bootstrap 5 */
$component-active-bg: $primary !default;
$input-focus-border-color: tint-color($component-active-bg, 50%) !default;
$form-check-input-focus-border: $input-focus-border-color !default;
/* Our override in Odoo */
$component-active-bg: $gray-200 !default;
```
This commit, sets the `$o-brand-primary` color (`#71639e` in community,
`#017e84` in enterprise) on the border in focused state.
Note:
before Bootstrap 5, this bug was not present as custom-checkbox was a
custom pseudo-element (`::before`), and so it was not possible to be on
a `focus` state on this pseudo-element.
closesodoo/odoo#101044
X-original-commit: fba258e738d6b629bb79fb5d7d9c9585733d72b1
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit properly removes the Many2ManyTagsField and
Many2ManyTagsAvatarField's placeholder when at least one tag has been
selected.
Steps to reproduce:
- In Contacts, open a partner's form view
- Edit and set at least one "tag"
- The placeholder is present next to the selected tags
Note: the placeholder was already present in previous versions.
Reported by FP.
closesodoo/odoo#101042
X-original-commit: 5976e19a31b9b0edaefc1079541514810d12b240
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closesodoo/odoo#101012
X-original-commit: 9ec7aa9b89bc929af15473d0cc29084fd831cf94
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, when exiting a record in any way, the validity of
each of the fields was checked, even if not dirty. This means that the
user would be locked on a required field if that field got an invalid
value from the server, even with no given input.
In this commit, switching the mode on a record ("readonly" | "edit")
will not go through validation if the record was not dirty.
closesodoo/odoo#101000
X-original-commit: 8a8241503e41486e79ca19f9ca16f413cfabb08b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When generating an invoice for a SO with 2 SOL that have a timesheet service
(1 SOL is timesheeted in August, the other is timesheeted in September) and
we request the invoice for the period of August only, the SOL for September
is incorrectly set to state "Nothing to Invoice", instead of staying in
state "To Invoice".
This is due to the fact that when we inspect the SOL to invoice, those that
are not in the domain (here the SOL in September is not in the time domain
of August), we set it's qty_to_invoice to 0, so it doesn't get invoiced, but
this is a computed field, which sets the line invoice_state to "Nothing to
invoice".
The proposed fix is to reset the invoice_state of the lines that are not validated by the domain to the state before setting the field qty_to_invoice to 0.
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- master
opw-2969641
closesodoo/odoo#100978
X-original-commit: 50b81adb3ea13db33bf1375b7038b6cc3546ec86
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
- In `unlink`, since https://github.com/odoo/odoo/pull/66938
modified is called on self for each batch of 1_000.
But it should be called on the batched records.
- In `write`, remove useless `records_to_inverse`
(there from ORM refactor but never used)
- make `_modified_triggers` more deterministic by
changing a `set` into `OrderedSet`.
closesodoo/odoo#100472
Signed-off-by: Raphael Collet <rco@odoo.com>
So far the vat_label was missing in res_country_data.xml.
This defines the official name for the local Tax ID (called "RUC").
closesodoo/odoo#100650
X-original-commit: 53b0ff01535c10d31102e9087d9e5196fa261630
Signed-off-by: Laurent Smet <las@odoo.com>
Longpolling port is replaced with gevent port and is deprecated
This commit avoid saving the value.
Not really usefull but when saved the value was None leadind to an error
when casting to int. The default value should be an int.
closesodoo/odoo#100991
X-original-commit: adac9a9ceaa173c0181a4fc57d0ea83b7a37fc71
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
They tend to come in the way of very obvious things in the UI, repeat
the same stuff that the label, etc.
Titles attributes are not good for a11y, so if needed I prefer replacing
them with an aria-label which:
- doesn't mess up the UI
- works properly with screen readers
I've kept them on nodes that have no text (e.g. icons), otherwise
they're not needed - text needs not be labelled.
closesodoo/odoo#100990
X-original-commit: 1c52c649f99d831de98d349d1ffbc6abc95a93ae
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Currently, When we create an invoice from a sale order containing some notes or sections.
The analytic account from the sale order is set on the invoice/move line.
During the creation of analytic lines, a line is created from the section/note line.
This commit makes no analytic line is created for section/notes.
closesodoo/odoo#100989
X-original-commit: a1bff32113bb0b551cd62efea5030c8f3bd4d1de
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.
Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
one with values:
- Product: Table Top
- Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
finish time) even though its expected duration is 2 hours
Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)
Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning
opw-2893622
closesodoo/odoo#100988
X-original-commit: 2515482d5a706c65a7d8e27028f43987f17e6e67
Related: odoo/enterprise#31720
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, in a list view, the context set on a m2o field
is not used when you edit the field to create a new record.
How:
- Go to a list view with a m2o field containing a context
<field name="m2o" context={"test":1}/>
- Edit the field the m2o field
- Click on "Create ..."
Before this commit:
The name_create method call does not contain the context defined
on the <field/>
After this commit:
The call to the name_create method contains the context defined
on the <field/>
closesodoo/odoo#100987
X-original-commit: dd1e7fab585ed5a691456632c20097ce443d9d69
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit moves the inline handlers of the `useSortable` hook
calls in the list and kanban renderers to proper class methods.
This allows said handlers to be overridden in child classes.
closesodoo/odoo#100986
X-original-commit: ec5ab1d389a0bdfb37c8b2c6766b6be1330085a7
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit implements the "name_get" method in the sample server.
This is required for m2o fields with the "always_reload" option.
How to reproduce?
go to an empty list view with sample="1" containing a m2o field with the
"always_reload" option
Before this commit
We have a crash because the "name_get" method does not exist.
After this commit
The view is rendered correctly with the sample data.
closesodoo/odoo#100985
X-original-commit: 4e53f92caf2527b15439eae041fcd238e2ed8145
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The placeholders were rendered as empty string in the web version of the
mailing (accessed through the "view online" link in the email). This fixes the
problem.
Technical note: we cannot use mail_mail.body_html (which contains already the
rendered placeholder for the specific user) as it is marked for deletion so we
render it from mailing_mailing.body_html.
Task-2954282
closesodoo/odoo#100984
X-original-commit: 6b2d5db762ef198e9f07af95116c166b027eb383
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Indonesia officially added new province. Papua Selatan, Papua Tengah, Papua Pegunungan.
closesodoo/odoo#100980
X-original-commit: 9d047bfac876f814f46cf212d2be44614a8e7a71
Signed-off-by: Jérémy Kersten <jke@odoo.com>
The move line list js has a set thread method that tries to
get the move_id from the list view.
But in the list view, the move id was now missing so it
couldn't find it when a filter on journal entry was set.
This adds it again so that the code can get the information
again.
closesodoo/odoo#100974
X-original-commit: 8857d31bfa6f2e330d296ab6f3ed9223e228f54e
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
A crash would occur when creating new records as the code did not take
into account the possibility of having empty "base" data.
closesodoo/odoo#100973
X-original-commit: 497db878fa3f9303ce33035d5737352289c4f97d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Currently, if we create an activity for user other than logged in one and
create a calendar event from the activity, it automatically changes the
attendee on the event and re-assigns the activity to the logged in user
instead of the one originally assigned to the activity during creation.
It happens because default attendees are not passed while creating the
event from activity. ALso, when editing the calendar event, the sync
mechanism changes the activity user to the organizer of the event, which
by default is logged in user.
This commit improves the behavior by passing the appropriate default
values so that the calendar attendees and organizer matches with the
user to whom the activity is assigned initially.
task-2920631
closesodoo/odoo#96943
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit
The method `updateValue` was updating value constantly
because `value` was a string and `this.props.value` a Markup.
Now
Update only when necessary
closesodoo/odoo#100965
X-original-commit: 45d4ac14f65c53dcde56592715d50169bde116ad
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
This commit adapts the x2many as first notebook tab's child selector to
the DOM of its OWL implementation, restoring the correct padding in this
case.
Steps to reproduce:
- Open Product form view
- Select the Variants notebook's tab
- Tab shouldn't have padding when the first child is a one2many
closesodoo/odoo#100912
X-original-commit: 74875dcc0b84236c0911b117666fc6deb41ed432
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
After this commit, fields from models framework are stringified to
follow the presentation ModelName/fieldName.
Task-2992286
closesodoo/odoo#100845
X-original-commit: d645bf2c708f67ff27d004b79754926f3086c58b
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Steps to reproduce:
- in Barcode > Inventory Adjustment
In the quantities add a decimal numpad
Issue:
Traceback
Cause:
The field is from type=number. This kind of field does not accept methods such `selectionStart()` or `selectionEnd` which causes an error: https://html.spec.whatwg.org/multipage/input.html#do-not-apply
Solution:
When of type=number, just return.
On Chrome, numpad won't be possible for regions such as Portugese - BR. They would have to use the keyboard key `period`, code '.' in order to be able to put a decimal via the keyboard.
In Firefox, HTML is parsing the input correctly if the browser settings are set to the right localization. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input#localization
opw-2956481
closesodoo/odoo#100953
X-original-commit: d95fbd80f63efbb47c9635e299f6ac417c5cb4c2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Currently the web.ReportAction component instantiates an iframe with 100vh of
height, while it should be instantiating the iframe with h-100. It assumed the
only component that would be rendered was the iframe, but we also need to take
into account the control panel and etc.
Also, the ReportAction component wasn't taking into account the height of the
control panel to set the height of the `.o_content` div. This also caused the
iframe to be rendered with the wrong height. This commit fixes this by adding
a flexbox column wrapper before the layout component.
closesodoo/odoo#100938
X-original-commit: 26cb2e1f659597311a06e46a84d7a0a9c3df6f74
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Before this commit, when scrolling in the emoji grid and there's still
2 rows of emojis before a category section, this category was
mistakenly considered as active.
This commit fixes the issue, so that the category is considered active
only when the 1st visible row is in this category.
Task-2992589
closesodoo/odoo#100934
X-original-commit: 5eea0b5480f1e45b0b05bedc21689d35178490b7
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since commit odoo/odoo@0afe6fbda5
the `$card-cap-bg` was set to `white` to avoid inconsistencies in the
design. But the original value is `rgba($black, .03)` (3% of opacity of
black, almost transparent), this allows to customize the card color
using the utilities classes (e.g. `bg-danger`) but since the header of
the card is not more transparent, this behaviour is not working anymore.
This fix restore the original behaviour to avoid to break Bootstrap.
Steps to reproduce:
* Make an Odoo database without demo data
* Install an app
* Go to Settings
* Click on "Load demo data"
* A modal is open with a Bootstrap Card
* The title of the card has a withe background, not a reddish one => BUG
closesodoo/odoo#100932
X-original-commit: a1c7e3ac1b42beeb5de94307fb1bb5f09c869167
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
What is done in start should be undone in the destroy.
closesodoo/odoo#100904
X-original-commit: a221342ca18db892153bbf4139c0bee7cd1e9bde
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The notification_alert component can now be registered as a view_widgets directly
closesodoo/odoo#100898
X-original-commit: 4f91758d1aefb6e459ccf02220bf4cf27f3a2ff2
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit makes all sorts unconditional, which would allow us to get
rid of the functions that wrap the sorting rules and use arrays directly
instead.
This will allow us to lighten the syntax and to perform some
optimizations in subsequent PRs.
Task-2992581.
closesodoo/odoo#100895
X-original-commit: 4d15ca0f6883fb089e8d7514c4e639b86cedbd45
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Since the merge of Bootstrap 5, some data attributes was non converted
to the new syntax for Bootstrap 5 (data-interval -> data-bs-interval).
closesodoo/odoo#100935
X-original-commit: bb9f7542b9dd481c363b593aa97d4a6f2d5ecd1f
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
In mass mailing, a button allows you to see selected records. In some case the
displayed view of selected records allows to alter records (ex.: cancel
attendee in event) which then affects the number of selected records. This fix
forces the recompute of the number of selected record when closing the view so
that it takes into account the potential modification done in the selected
record view.
In mass mailing, in the selected records view, the button is called "cancel"
but any action performed in the modal will still be applied. This fix renames
that button to "close".
Task-2921762
closesodoo/odoo#100933
X-original-commit: be4e409ec1c23f64e11796b05643e424a93aba9e
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The method `_clean_leave_responsible_users` is also called from the
write method in hr.employee, however not anyone can remove users from
groups.
Fix of the fix in odoo/odoo#100591closesodoo/odoo#100923
X-original-commit: 129e4799b04210f107185ba96b5c1845d943cf8b
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit avoid to have a dict by reference that will be global.
Now get_default_session return a new dict each time for the context key.
From this way the session.context['lang'] is not shared between several
users on the same worker.
To reproduce the bug, restart the server with 2 workers, make request in
lang A on these 2 workers. DEFAULT_SESSION['context']['lang'] now is set
to this lang A.
Now, make request to an url without lang in path and without cookies and
withtout session, you should be redirected to lang B (preferred lang
from the request header) but you will be redirect to lang A due to the
dict session.context that is shared for the worker...
When we initialize the new Session, we get the wrong lang A as value for
context.lang, so we don't recompute the expected lang for the end user.
X-original-commit: 62179de74862210fe2a055d15b367b1850c24263
fwd-port of #100102closesodoo/odoo#100910
X-original-commit: 42e46b2d89dde276f796b980f29e33cc216e7cb2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Steps to reproduce the bug:
- create a new product “p1”
- Create a purchase order with “P1” → confirm it
- Click on “Purchase history”
Problem:
No purchase order is displayed for this product, whereas we have a
confirmed PO.
Because the partner id is formatted as a string and added to the domain,
so when the `web_search_read` function is executed, it will return an
empty result because the id is supposed to be a number instead of a
string: https://github .com/odoo/odoo/blob/master/addons/web/models/models.py#L62
Solution:
The filter on the vendor can be removed because it's already added when
calling the action: https://github.com/odoo/odoo/blob/678bc958fafd5502a61ce54069b13160ad37d2d4/addons/purchase/models/purchase.py# L1240
opw-2976152
closesodoo/odoo#100892
X-original-commit: 9431adc5bfce525bd3a9ec4c3f7215f2ee312841
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Replace the old "shortcuts" cheat sheet with opening the command
palette, which displays these shortcuts (and all of them, not just the
common ones) and also will display a tip regarding how to make the
shortcuts overlay appear.
closesodoo/odoo#100941
X-original-commit: e2625d7bc0c10d7b96912e06bcffe7074cfe6962
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit ports the custom implementation of the view form for the chatbot
scripts to the new OWL framework.
The goal is the same as the base customization, which is mainly to correctly
assign a sequence to every step and save the form in-between every new steps.
This is necessary to allow the end-user to easily configure its script, since
steps can depend on each other.
More details in https://github.com/odoo/odoo/pull/84000
In addition, we slightly adapt the CRM bridge to enable no_open for the sales
team field.
This avoids issues when the user tries to open modals on top of modals.
Task-2981969
closesodoo/odoo#100940
X-original-commit: 68d5da02642d22551603e4c6b5583755b2f4fc2d
Related: odoo/enterprise#31688
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Christophe Monniez