In following configuration:
- We have two companies: A and B
- We have a shared product X
- We set a BOM of type KIT for this product X for company B only (the field company on a BOM is mandatory)
- We set no BOM for product X for company A because in company A we sell the product as a regular product
When we sell product X in company A, as a normal stockable product, the invoicing behavior is the same as
when we would sell KIT products. This is because we don't check the SO company when searching the associated
BOM.
closesodoo/odoo#30927
Commit bfb0f1e2a5
did a very good job not seeing that the lines only used move[0],
and called move.field directly.
This could result, for certain BoMs, in traceback.
opw 1928677
closesodoo/odoo#30938
Backport of d9fed5381a78c19ce14ddc8b9233f60d53c65453
Before this commit, when opening the calendar view with a specific locale
in the "week" view
the days were translated but the date format was wrong and fell back to english
This was because the translated terms were passed explicitly, but the locale did not
get passed
After this commit, we do what it takes to pass the locale to fullcalendar
and the dates are formatted with the right pattern
Also, there may be a bug in fullcalendar, because just passing the locale in the options
won't work, it should be instanciated first in fullcalendar's "locales cache"
OPW 1922092
OPW 1934127
closesodoo/odoo#30909
Usecase to reproduce:
- Create a route with a warehouse_ids
- Uncheck warehouse_selectable on route
- Create a picking that use the route
It should fail since the route is not applicable.
It happens because _search_rule only check for route with warehouse_ids
but it do not check for warehouse_selectable. We can't fix _search_rule
since stock_warehouse.py creates multi step delivery and reception
routes without warehouse_selectable thus it would break existing configuration.
Instead create an onchange on warehouse_selectable that remove
warehouse_ids on route.
partial backport of commit a35df8d371closesodoo/odoo#30844
In the e-comerce, when the user try to add a new card in this payment
methods.
Before this commit, to validate the card, besides of the creation of the
payment token, an amount of $1.5 id charged and refunded.
During the refunded an error was raised. This error arrives because:
payments made via Authorize.net are settled and allowed to be refunded
only on the next day.
https://account.authorize.net/help/Miscellaneous/FAQ/Frequently_Asked_Questions.htm#Refund
<quote>The original transaction that you wish to refund must have a status of Settled Successfully.
You cannot issue refunds against unsettled, voided, declined or errored transactions.</quote>
This means, we can't refund directly after the payment.
Now, we only create the payment token. As Authorize.net verify the card
during the creation of the token, a new verification is not needed.
OPW-1927754
closesodoo/odoo#30905
Have a partner in French while you operate in English
Click on 'send by email' on a invoice/sale order/purchase order
Before this commit:
- The body of the mail is translated in the partner's language
- but the notification header/footer surrounding the body was not
This is because:
- mail templates apply to a model
- in the case of the notification header/footer, this model is 'mail.message'
- mail.message doesn't have a lang field
- at the notification rendering time, we don't have easy (and generic) access
to the "real" model or to the lang (let alone to which lang to apply) that we need
After this commit, the notification is translated but:
the lang to get is hardcoded, and is the one on the partner of the inv/so/po
and is un-coupled from the dynamic lang on the proper inv/so/po template
This patch is hackish at several levels, I suggest that a generic solution is found in master
If no other solution is found until then, then the patch may be forward-ported
OPW 1935091
closesodoo/odoo#30873
Activate multi-company, deactivate the common contact book.
Create a PO P with user U1 in company A. Switch to company B.
User U2 in company A tries to send P by email.
Rendering of the template fails, because it tries to access object.create_uid,
which breaks multi-company record rules.
The signature was not working because it used user_id, a non-existing field,
instead of create_uid.
opw 1930521
closesodoo/odoo#30868
In stock.picking, in mode show detailed operation, add a product with
unique serial number tracking.
Before this commit, a warning about the qty is raised. This warning,
must be raised only if the qty is different from 1.
However this is not the case,
the warning is raised at each modification of the line.
This issue occurs since the rounding given to the float_compare is 0.0,
because self.move_id.product_id is not set.
Float_compare with a 0.0 rounding always return different, hence the bug.
Now, the warning is only raised when the qty is different from 1.
OPW-1932044
OPW-1931378
closesodoo/odoo#30651closesodoo/odoo#30851
Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
meaning a return location in the warehouse
This commit now allows making return in all return location, even one
located in another warehouses.
closesodoo/odoo#30836
- Create a SO with 2 lines of the same product (set route as Drop Ship)
- At validation, both lines are merged into a single line in the PO
As a result, one SO line will be over-delivered, and the other
under-delivered.
Two lines should be kept in the PO.
opw-1928702
closesodoo/odoo#30800
- Create a product P with:
Costing Method Average Price
Inventory Valuation Perpetual (automated)
- Create a component C with, costing 10.
- Create a BOM for P:
1 Unit of C
- Create a MO for P, validate
=> a journal entry of 10 is created
- Modify the BOM for P:
2 Units of C
- Create a MO for P, validate
=> a journal entry of 15 is created
The journal entry should be 20.
opw-1928342
closesodoo/odoo#30766
Create a tax of type "group of taxes".
Put taxes in its children_tax_ids field.
Change the type to something else.
The view hides the field children_tax_ids, since it doesn't make sense anymore.
However it doesn't actually remove the children_tax_ids.
As a result the child taxes are use in the computation.
We add on onchange to avoid that unfortunate situation.
opw 1931089
closesodoo/odoo#30727
Through many design refactorings, the community caret position was
broken while the enterprise was not. This commit removes the breaking
rule to put it in enterprise only.
closesodoo/odoo#30799
Have a sales team with one or more orders to invoice.
Open the 'Sales Channels' report in Sales.
Before this commit, the 'Invoicing' progress bar of the report,
showed the number of order to invoice and not the sum of the
invoicing amount.
Now, the 'Invoicing' progress bar of the report shown the sum of the
invoicing amount; and the number of order to invoice are shown in their
own field.
OPW-1922438
closesodoo/odoo#30735
Before that, having a payment with amount_residual=0, but amount_residual_currency!=0 did not display it.
Also, 'outstanding credits/debits' label was displayed in case amount_residual was != 0 with an amount_currency=0 (and of course, a currency_id value was set on the aml). This could for example happen in case of partial reconciliation, were the amount_residual field is used to keep track of what will have to be written in the exchange rate difference entry when the reconciliation becomes full.
closesodoo/odoo#30362
This commit simplifies the code and improves the performance
of _compute_sale_order_count.
execution time from O(n^2) to pretty close to O(n)
Project : Performance Issues
Task : Geostaff : Success Pack 5 (100h) (opw-1912303)
With https://github.com/odoo/odoo/commit/ac8b0fcfc5299b5ea62543b8382cb419fed4868e,
the 'country_events' class was renamed to 'oe_country_events'. This was
done correctly for JS animations and snippets but not for the 'Country
Events' option in the customize menu. This made the option useless.
This commit solves the problem by supporting the two classes (as it
is a stable fix).
closesodoo/odoo#30662
In a pos session:
OFFLINE
make an order with invoicing , try to validate
The order stays there because it needs to be validated by the server
make another non invoiced order, validate
ONLINE
make another order
At validation, all orders will be pushed to the server
Before this commit, when trying to validate the invoiced order
the report download couldn't find the order id, and crashed
This was because the order in question was already pushed
but treated as a non invoiced order
After this commit, an "warning" message is displayed to the customer
saying he/she has to print the invoice from the backend.
In most cases it is enough and acceptable, since a customer would actually leave the premises
and come back later for the invoice
It is also safer in terms of data consistency to keep pushing all orders once the connection is back
OPW 1918044
closesodoo/odoo#30485
Before this commit, the web client had a naive strategy to handle lost
connections: it tried to poll the server every 2 seconds until a rpc
succeeds.
This works quite well from the perspective of the user, but may be a problem
from the perspective of the server. If a server is down for a longish period,
then each users active tabs will then perform a request every 2 seconds. This
means that the server will be progressively hammered by many requests, which
will clutter the logs, and make it more difficult to gracefully recover.
With this commit, we simply exponentially increase the delay each time, and add
a little jitter to give a better distribution.
Cherry-pick of 4a3f04bcc5closesodoo/odoo#30136closesodoo/odoo#30596
Have a tax that has a different account for refunds
make an invoice and its refund
Before this commit, the refund's tax is still in the old account
After this commit, the refund's tax is in the account for refund defined on the tax
OPW 1907950
closesodoo/odoo#30325
In case the discount product is misconfigured and therefore not loaded
by the POS, a traceback appears when applying a discount.
Add a comprehensive error message instead.
Closes#30574
opw-817527
closesodoo/odoo#30582
Use read_group is faster than the python equivalent,
and then don't push ids in ORM cache, which makes
the ORM faster later in the process.
Also unlink in batch.
For editing many2one fields (and partially many2many) most widget show
an autocompleting list of targeted records.
They thus have `autocomplete="off"` to prevent browser completion.
But chromium has an history of breaking `autocomplete="off"`, see:
- https://caniuse.com/#search=autocomplete
- https://crbug.com/468153
- https://crbug.com/587466
- https://crbug.com/914451
- https://crbug.com/923895
It seems that since chromium 71, the heuristic to ignore
`autocomplete="off"` has become more aggressive and for example if there
is at least 3 fields like an address in a page, chromium will ignore
`autocomplete="off"` for the fields like an address.
So for example the eidting the many2One field with placeholder "Country"
in a contact page now has a browser autocomplete menu that is:
- hidding the many2one autocomplete
- going to save empty country it appeared visually filled if the
autocomplete result was selected.
With this changeset, the placeholder in the many2one instance is
interspersed with U+FEFF charcters (ZERO WIDTH NO-BREAK SPACE) so the
browser does enable the autocomplete feature by force.
This should thus remove the issue (until it is fixed by chromium) in the
case of field named "Country" or matching other regexes in this file:
https://github.com/chromium/chromium/blob/cdb1b2073f12/components/autofill/core/common/autofill_regex_constants.cc
U+FEFF has been chosen instead of more recommended characters because
other have been shown erroneous for printing in some windows
configuration (see cb2a3afa7).
10.0 version of #30439
opw-1930588
closes#30439closes#30449
OPW 1929160
A filter prevented from selecting a partner in the reconciliation widget if it had a parent company but a company with a parent company should be selectable
closesodoo/odoo#30270
`product_price_update_before_done` may be called with a `forced_qty`
argument in the case of unlock: unlock a picking, edit a received/sent
move and increase/decrease the quantities. In this case, the formula of
the AVCO was wrongly applied.
Closes#30513
opw-30513
closesodoo/odoo#30730
Cherry pick of 0edd3ea5b4 in version 12.0
Have a Lead with the contact informations (Customer Name, Street,
Street 2, City, State, ZIP, Country) completed in the 'Followup' page.
Before this commit, when the base_adress_city module was installed, the
informations of the City, State and ZIP where lost when we try to create
a new Partner from the Lead.
Now, the informations are present in the Partner form; furthermore if
the country allows enforce cities, the information is also present in
the enforce city form.
OPW-1932018
closes#30644closesodoo/odoo#30713
Commit 9af941428880af8e1810dfd9feef494d7a745e98
made it so that the value_from function depends on a variable defined after
the function complete has been called, without any guarantee that this function
would be called after. Apparently this is the right OOP thing to do.
opw 1930523
closesodoo/odoo#30712
Because Python only runs signal handlers on the main thread, native
calls (IO or accept(2)) can delay these handlers running. This is
especially problematic when one such call is completely stuck and
we're trying to dump the stack to diagnose the issue.
By running the actual worker's processing in a sub-thread and leaving
the main thread sleeping, worker processes should always be able to
handle signals.
closesodoo/odoo#30688
- Set the OS in a timezone such as the current day is different from the
day in UTC (e.g. America/Nome before 10:00 AM or Australia/Melbourne
after 3:00 PM)
- Open any datepicker
- The 'little triangle' indicating the current day is wrongly set (one
day before or after)
Knowing that Odoo always creates momentjs date and datetime with the
`UTC` flag set to `true`, the `bootstrap-datetimepicker` does something
which seems inconsistent.
First, it retrieves the `viewDate`, and sets it to the beginning of the
month and week in:
https://github.com/odoo/odoo/blob/1c6c504215f3ef09e6336c92c9d350e87599eaa1/addons/web/static/lib/bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js#L725
In this part, it is important to note that each `startOf` functions
called sets the hours/minutes/seconds to zero. It means that the
reference time is changed.
Then, it iterates on this newly created date, and determines `today` by
comparing it to `getMoment()` in:
https://github.com/odoo/odoo/blob/1c6c504215f3ef09e6336c92c9d350e87599eaa1/addons/web/static/lib/bootstrap-datetimepicker/src/js/bootstrap-datetimepicker.js#L748
However, `getMoment()` returns the current date and time, but with the
`UTC` flag set to `false`.
Therefore, we compare a UTC datetime on which the reference time has
been changed to a non-UTC datetime, which fails to give the appropriate
current day.
There are two approaches to solve this. The first possibility is to
change the way Odoo defines momentjs dates and datetimes, maybe by
removing the `UTC` flag at creation. This sounds like a bad idea, since
other widgets or views (such as the calendar or the pivot view) make use
of them. This is likely to introduce a bunch of new issues with TZ in
these views. The second approach is patching the library to fit our use.
Although we usually don't do such a thing, this allows to specifically
solve this use case, and in particular placing the 'small triangle' at
the appropriate date without impacting any other part of the system or
the library. It can be easily performed by comparing the dates and the
months to make it work.
opw-1915251
closesodoo/odoo#30538
Florent de Labarre