When validating a picking from location A to B, location A's quant.quantity
may be updated to a quantity != 0 with _update_available_quantity.
This is because the quant value is written as quantity - float_round(quantity).
As a result, the consistency check would find two existing quants, and raise.
Therefore the picking cannot be validated.
opw 2040091
closesodoo/odoo#35913
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, a channel in mobile with option "Send messages
by email" had no composer when opening in mobile.
This issue happened because channel views in mobile are in fact chat
windows. Chat windows with such channels do no display any composer,
which is intended in desktop.
This commit fixes the issue by enabling the extended composer for
chat windows with email channels, just for mobile.
opw-2059468
closesodoo/odoo#36120
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The color picker in snippet options has two way to set a color: have a
data-color attribute => it is used, or have a o_custom_color class and
the background-color is set directly on that color.
In the case where we select no background color (transparent), it would
work in preview, but when applied the opaque color of the transparent
button (since opacity is not copied) is set which is wrong and
unexpected.
opw-2053636
closes#36131
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This reverts 0164c9dfcb
Have exchange rates:
Domestic - Domestic: 1.0
Domestic - Foreign : 1.113900
Make an invoice: 480 Foreign
Make a credit note: 140 Foreign
Make a payment: 287.20 Domestic
Reconcile all this with a writeoff: 18.04 Domestic
Before this commit, the first invoice was not fully paid
this was due to wrong summing of the partial lines that applies to it
account.partial.reconcile are made between only 2 move lines at a time
Whatever the amounts they hold, it has been computed at creation
and it makes no sense to aggregate their rounding error when computing
their impact on a move line (because, the information is already lost)
After this commit, the use case works, all invoices and payments are fully consumed and reconciled
Note that this is a simple use case, no dates or exchange rates involved
OPW 2057845closesodoo/odoo#36087
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Commit 54d30d5194 introduced `lastmod` and `priority` on sitemap locs.
This was broken with 4ecbacaf59 which introduced `website.page` model as it
removed the `PageConverter`.
Before website.page:
1. PageConverter returned records with `__lastmod`
2. `enumerate_pages` loop on converters would remove the prefixed `__`
After website.page:
1. code to remove `__` was still there but the pages would be found and looped
on after that code, making it useless.
With this commit:
1. The code to remove the `__` is moved after searching the pages.
Following #36090
Related to #35464
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Enable work orders, routings, and track components by lot numbers or serial.
Create an MO for a certain X quantity of finished products and plan work orders.
Only complete a partial amount Y of the overall X amount.
Specify the lots for the consumed tracked materials equal to the Y amount.
Then, return to the MO and click "Post Inventory".
An error is raised because the lot is missing.
This is because when processing workorders temporary lines
are created without lot/serial for tracked component products.
This is a limitation that require a task to be removed;
in the meantime we remove the button, in true bugfix fashion.
opw 2049806
closesodoo/odoo#35731
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
There is an open issue on the tempusdominus lib:
https://github.com/tempusdominus/bootstrap-4/issues/223
It occurs when there is a valid value in a date(time) field, and
the user unsets it by setting an invalid one.
This rev. fixes the issue in Odoo by preventing to reach the buggy
piece of code in the lib. In a few words, when the user sets an
invalid date, we reset the previous valid date (which is what the
lib tries to do anyway).
Task 2057009
closesodoo/odoo#36211
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
### [FIX] bus: background slave tabs should not loose notifications
Slave tabs missed some notifications in case the local storage
event's `newValue` did not match actual value in local storage. This
happens when master tab overwrites a value that slave tabs did not
take the time to read. Slave tabs should now always handle all local
storage events.
Task-ID 2044231
### [FIX] bus, mail: correctly synchronize document chat windows
Cross-tab synchronization of document chat windows resulted sometimes
with an infinite loop. This happens due to tabs relying on actual
value in the local storage and all document chat windows state being
set as a single local storage entry. Cross-tab communication of
document chat windows now is relying on event's `newValue`, and each
document chat window has its own local storage entry. Changes from
local storage no longer writes again in the local storage, so that
it no longer makes an echo (= infinite loop).
Task-Id 2034997
closesodoo/odoo#36177
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, there could be an infinite loop when changing
the chat window state of a document chat window.
This is caused when mutiple tabs overwrite the chat window state
with a different value everytime, resulting to an infinite loop.
Accross multiple tabs, `setItem` and `onStorage` are not synchronous.
That's why tabs should communicate through local storage events
instead of actual value in the local storage.
To illustrate the issue, suppose there are 2 tabs (T1 and T2) with
one document chat windows (C) and the following user interactions:
- T1 and T2 both have C open
- on T1, user folds C
- on T2, user folds C
Now let's add an example of local storage (LS) logics that could
apply from above example:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
[3] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[4] T1 detects 'C folded' in LS (from [2])
=> T1 writes 'C folded' in LS
[5] T1 detects 'C folded' in LS (from [3])
=> T1 writes 'C folded' in LS
[6] T2 detects 'C folded' in LS (from [4])
=> T2 writes 'C folded' in LS
etc...
This scenario could have been easily prevented by not writing on
local storage when the chat window state has not changed. However,
this wouldn't fix this scenario that also introduces an infinite
loop:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
- on T2, user unfolds C
[3] T2 writes 'C unfolded' in LS
[4] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[5] T1 detects 'C unfolded' in LS (from [3])
=> T1 writes 'C unfolded' in LS
[6] T2 detects 'C unfolded' in LS (from [5])
=> T2 writes 'C unfolded' in LS
[7] T1 detects 'C folded' in LS (from [4])
=> T1 writes 'C folded' in LS
[8] T2 detects 'C folded' in LS (from [7])
=> T2 writes 'C folded' in LS
[9] T1 detects 'C unfolded' in LS (from [6])
=> T1 writes 'C folded' in LS
etc...
This commit fixes the infinite loop issue:
- by turning local storage read during cross-tab communication into
local storage event read instead. This should prevent race
conditions based on read/write operations in local, since their
order is not guaranteed accros tabs.
- by isolating document chat window state to their own local
storage entry. This should prevent a tab from notifying a chat
window state that it didn't change, which may also result in
an infinite loop.
Some tests were adapted from the changes above. Also, some tests did
pass thanks to local storage being mocked by a ram storage: the
handler `_onStorage` should have been called, but it didn't because
it was registered on the actual local storage instead of the ram
storage. In order to make tests pass again, the following additional
changes were required:
- Cross-tab bus service now exports the unique tab ID with
`getTabId`.
- document thread entries in local storage now track the tab ID, so
that self-tab ignore their own local storage writes.
Task-Id 2034997
Closes#36177
Before this commit, some notifications may be lost while forwarding
them between browser tabs by means of the local storage (i.e. from
the master tab to slave tabs).
This happened when some slave tabs are in the background and are
throttled by the browser: the master tab writes twice in the local
storage (to notify slave tabs of new notifications), and slave tabs
drops the 1st notification. This is caused by the mismatch between
the new value in the local storage event and the actual value in the
local storage. For example:
```
t(0) - Master tab receives `message` notification;
t(1) - Master tab writes notifications (= `message`) in local
storage;
t(2) - Master tab receives `message_seen` notification;
t(3) - Master tab writes notifications (= `message_seen`) in
local storage;
t(4) - Slave tab detects new notifications (= `message`)
from local storage event, but drops it since it does not
match actual local storage value (= `message_seen`);
t(5) - Slave tab detects new notifications (= `message_seen`)
from local storage event, and handles it since it
matches actual local storage value (= `message_seen`);
=> Notifications received + handled:
- master tab: `message`, `message_seen`
- slave tab: `message_seen`
=> Slave tab lost "message" notification.
```
This commit fixes the issue by letting all tabs handle any local
storage events, regardless of the actual value in the local storage.
In the example above, this means the slave tab will not drop the
notification `message` at t(4).
Task-ID 2044231
Closes#36177
Backport from 12.0 to 11.0
When using barcode to change the customer to a customer with a different
pricelist than the pos default, the customer pricelist was not
automatically selected.
This is a fine-tuning on 5603b778f6
opw-2047070
closesodoo/odoo#36050
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
When uploading an attachment from a chat window, the label
"Uploading..." was not visible. This comes from attachment preview
being too small, thus cutting entirely the filename and the upload
progress bar.
This commit fixes the issue by increasing the size of attachment
previews in chat window, so that it takes 50% width. It also provides
more space for labels on attachment preview while uploading, by
removing the right padding for the animated "unlink" feature that
works only for uploaded attachments anyway.
Note that this commit does not entirely solve the issue: half the
width of a chat window being enough to display the icon, the file
extension, and sometimes the label "Uploading..." completely. The
width of the icon and text extension combined is always the same,
but the label "Uploading..." changes with the locale. The extra space
from the padding removal makes this label fully visible in English,
but not necessarily in other languages. The proper fix requires
re-designing the style of attachment preview, which will be done in
master.
Task-Id: 1978640
closesodoo/odoo#33638
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
- Create a new tax, using the 'Python Code' tax computation
- In 'Applicable Code' field, use a field only available on the
`product.product` model (e.g. `product.code`)
- Attach this new tax to a product that is available in the eCommerce
- Access the eCommerce, search for the product if not displayed.
The template `website_sale.products_item` crashes at rendering because
`code` is not available on a `product.template`.
`product` is supposed to be a `product.product` recordset. However, the
method `_get_combination_info` of `sale` is made in such a way that we
can fetch the information of a template, not a product. Utlimately,
methods `compute_all` and `_compute_amount` are called with the wrong
object.
We fall back on the first variant in this case.
opw-2056722
closesodoo/odoo#36134
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When a COA is installed being loaded for current company, the
translations of taxes, account name, ... (in l10n_be, l10n_ca, l10n_ch,
l10n_sa) are copied from the templates to the accounting records.
This is done in `post_init_hook` which is correct since then
translations are available to be copied.
But when an accounting localization is already installed and we set it
to a company, the translations are not copied.
eg. install l10n_be for company1: accounts name are translated in
french and dutch, set company2 to belgian accounting: only original
language is available.
With this changeset, the translation copy is also performed when an
accounting localization is loaded for a company after it has been
installed.
note: if we install language for first times after setting accounting
localizations, chart of account are translated in that language.
opw-2047013
closes#35985
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
usecase to reproduce:
- Set the warehouse with manufacturing 3 steps
- Create a BoM with a Components that use a Sub BoM
- Set Both product MTO + Manufacture
- Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO. So the solution would be to
add a condition to _assign_picking and don't merge moves if they come
from different MO, at this point the field created_production_id would
fit. However this solution is not robust if a customer creates a
new rule that add a 4th steps to the production process.
opw-2055688
closesodoo/odoo#35915
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>
Let's assume an action with 'create': 0 in the context, and a non
inline subview in the form view. Before this rev., the 'create': 0
was applied to both the form view and the subview.
This rev. applies the same logic as what the server does for inline
subviews: the rule is applied to the subview iff its model is the
same as the one of the form view (with key 'base_model_name' set
in the context).
Task 2035653
closesodoo/odoo#36109
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- In stock, create a new transfer (stock.picking);
- Enter a source location ('A'), a destination location ('B') and an
operation type;
- Add product (whit out packaging);
- Change the source ('C') and the destination ('D') location;
- Hit save.
Before this commit, when opening the details of the move, the source and
destination location where setted as 'A' and 'B', the locations that
were setted before adding the product.
Now, the source and destination location of the move line are 'C' and
'D', the current location at the time we save the picking.
opw-2058240
closesodoo/odoo#36089
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Display your website in Right To Left
Go see the phone number of the company
Make that number in the form
```
123[space]456[space]789
```
Before this commit, the blocks of that number were inverted
(intra-group order did not change)
Leaving us with
```
789[space]456[space]123
```
After this commit, we introduce a little class to force Left To Right
display
OPW 2059917
closesodoo/odoo#36115
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Product category: FIFO (real_time) / Automatic
- Product: storable, nvoicing based on delivered quantity, FIFO category
- Receive 3 units @ 30
- Create and confirm a SO for 1 unit
- Deliver requested qty to customer
- Unlock the picking, update the qty done to 3, lock.
- Invoice delivered qty
In the journal entry of the customer invoice, the COGS entry is 180
instead of 90.
The root cause of this is the incorrect price unit on the modified stock
move, which equals to -60 instead of -30.
The price unit should compute the weigthed average of the already
delivered quantity with the extra quantity.
opw-2047719
closesodoo/odoo#36065
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the code that was supposed to close the dropdown in the
navbar when scrolling was not working anymore.
Indeed, it would removes the `show` class from the `nav-item dropdown`
(dropdown menu entry) but not from the `dropdown-menu` (dropdown content).
Fixes#35320closesodoo/odoo#36069
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When pasting from clipboard, the editor filters the nodes to paste.
Among other things, it removes `meta`, `style` and `script` nodes. It
did so using `jQuery`'s `not` method but that method has a side effect:
it removes text and comment nodes as well if you pass it a `jQuery`
selector. As a result, unwrapped text nodes could not be pasted. This
commit fixes that by using `each` to remove the targeted nodes instead
of using `not`.
closesodoo/odoo#36012
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Since implementation of repartition lines on tax in accounting, the
amount on the tax is not always the effective amount to apply on price
of a product. You can have a tax with amount of 20% for example, and two
repartition lines of 100% and -100%, that will lead to have to apply 0%
on the tax.
So we are computing the effective amount on the tax by multiplying the
amount of tax by the sum of repartition lines factor.
closesodoo/odoo#36140
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
1) Suppose a tax of 21% intracomm +100%, -100% applied on 100.0.
The computed price_excluded was 121.0 instead of 100.0 because the
assumption was made the sum of repartition lines factor was always 100.0%.
After this fix, the amounts are always multiplied by the sum of repartition lines factor
in order to reflect correctly the impact of each repartition lines.
2) The rounding is now working for any kind of repartition lines and the consistency
of tax amount regarding the repartition lines is always ensured.
See use cases described by the tests for more details.
closesodoo/odoo#36082
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, a field selection which was required
did not have an empty option
ref: 4dfabb8f7a
This is fine, but overlooked the fact that modules can modify
the required attribute, or even views can do it
So, we may end up in a situation where the field is required but set to false
This configuration is problematic, at least for the timezone selection field
(see OPW)
After this commit, the empty option is just not visible
note that `disabled = True` would not work because val is not accessible
Because of commits:
- 4dfabb8f7a for the selection feature
- d77ce4c2a9 overriding the required attribute of tz in res.user form
OPW 2057913
closesodoo/odoo#35989
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
It is an important information as it is different that the domain.
The users computed with the domain are added to the list, never removed.
closesodoo/odoo#36033
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If a goal definition with a target goal of 0 and "higher the better",
instead of dividing by 0, set a progress of 0% (it is not possible to
compute the progress)
Task id: 2057898
It should be possible to open the view form of a goal from the
"Related Goals" action. This is an easy way to set progress for manual
goals.
Task id: 2057898
The users are always happened when matching a domain, never removed
(which is a feature, so you can manually add people).
If you made a mistake in your domain (e.g. start large and refine),
there was no way to remove them afterwards.
Task id: 2057898
Open the Lunch kanban view
Before this commit, the counts for each product were the counts
across all location
This was before the location domain from the lunch widget was not sent
After this commit, the counts displayed on startup are the ones
of the right user location
OPW 2053044
closesodoo/odoo#35976
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Let's assume an editable grouped list view with a <groupby>
node containing subfields, and an onchange. Edit a row to trigger
the onchange. Before this rev., it crashed because the onchange
specs was incorrect: it followed the relation of the many2one
and thus included its subfields (whereas it should only follow the
relation for x2many fields).
For example, go to Accounting > Accounting > Sales and edit the
label of a move line.
Task 2044187
closesodoo/odoo#36001
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Removing elements from a list while iterating over it isn't a good
idea. As a consequence, the MockServer didn't support list archs
with a <groupby> node containing several <field> nodes, or a
<field> node precedeed by a text node.
When you are offline, and you validate an order with an invoice, the
rejection of the Promise is not well handled and propagated which lead
to enter in a resolve even if it has failed.
We are now correctly propagting the rejection of the call to the server.
closesodoo/odoo#35974
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Create a vendor payment by check
- Remove the amount in words
- Confirm
It is impossible to set the amount to print the check.
We add an action button to recompute the amount in words. It is only
visible when the amount is not set.
opw-2046339
closesodoo/odoo#35968
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
A sanitize fields by default remove all attributes outside of a
whitelist (if sanitize_attributes on field is not set to false).
This prevent to use parallax widget in Html sanitized field since
attribute "data-scroll-background-ratio" define parallax effect speed
but was not in whitelist.
note: also keep data-interval for gallery widget
opw-2053983
closes#35961
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, when having the field "id" in the graph view
it was selected to group by on it.
This doesn't really make sense, and triggers an sql error anyway
After this commit, we filter out that field from the groupbys
OPW 2053444
closesodoo/odoo#35958
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Doesn't focus hovered option in the searchbar
Before this commit:
When typing in the searchbar while having the cursor right under it,
the selected option was automatically the one hovered by the cursor.
Now, the default option is the first one (typically name search) and the
cursor hovering only takes effect when moved for the first time.
Task 2058656
closesodoo/odoo#36099
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Fix missing js_class attribute on the calendar xml validation file
Make possible to create new custom views based on the calendar view
Was already done in master at 496920a8f5 but was not present in 11.0
Closesodoo/odoo#26750Closesodoo/odoo#31679Closesodoo/odoo#36156
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
currently widget selection is not working in m2o in editable list view and
to fix this issue it need a lots of changes to make it work properly,
i.e. make '_fetchSpecialRelation' use correct domain for each record,
batch requests as much as possible, also make all '_fetchSpecial...'
work in the list case.
So to avoid major changes remove supportedTypes from selection widget
so user can not tempted to apply selection widget on many2one field.
task-1871698
closesodoo/odoo#33485
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Florent de Labarre