- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
Nothing prevents to click on the 'Pay Now' button, although the shipper
rating has failed. Moreover, the error is not displayed in the label of
the shipper.
Workaround: we force a click on the selected default shipper to trigger
the update. The good solution would probably be to have a completely
dynamic shipper rating integration, instead of some processing at first
rendering and then extra dynamic processing.
opw-1838765
When clicking on button "Invoices" from a payment, it always displayed
the supplier views instead of taking care about the type of the payment.
opw:1849397
Revision on 8ac98fc78a
The commit above does not check whether the list contains data or not.
As a result, if there are no data in the list, there is no reason to
fetch `name_gets`.
In fact, there could be a traceback because some parameters of this rpc
are computed from data in the list. So if there are no data in the list,
the parameters of the rpc are undefined. This was the case for a test
in enterprise.
Revision on https://github.com/odoo/odoo/commit/9a9da5763b38a3bce54e9c4870af0032e38cacc3
The intent of the commit above was to no abandon records in a list on
discard when these records have been created from a `default_get`.
Also, the `default_get` may also perform an `onchange` that could create
more records. The records from this `onchange` must also be included in
the "do not abandon" rule.
However, the rule was too relax, so that any following `onchanges` from
a user interaction was also considered into this rule. As a result, it was
not possible to abandon such records.
With this fix, we restrict the rule to `default_get` (already the case) and
only the `onchange` right after a `default_get`. Any record created on an
`onchange` from a user interaction after a `default_get` should be abandoned
on discard.
Representation of creating the list:
savepoint
|----------|-----------|-------||--------|------->
create default_get onchange1 onchange2
record in the list is created by default_get or onchange1
=> do not abandon on discard
record in the list is created by onchange2
=> abandon on discard
When seeing the work orders view, it would display an empty black box instead of
the proper message.
The message is not displaed since creation is deactivated.
opw 1839001
Have a delivery for a client, with pack operations
Connect on this user's portal
Go on the SO and then on the delivery
Before this commit, there was an Error 500
because access to fields of pack_operations was forbidden
After this commit, the report downloads well
OPW 1849520
closes#24849
datetime.date(year, month, day).weekday() is undefined for year > 9999.
When creating a google recurrent event that is set to never end,
Odoo tries to create 100 individual events.
If in Google calendar the user sets a recurring event to a custom interval,
of say a century, then the hundredth event is in 100x100 years, so in 12018.
Since 12018 > 9999, we get a traceback and synchronisation never happens.
opw 1845311
- Create the following BOM structure:
```
Prod 1 (Manufacture)
|
--- Prod 2
Prod 3 (Kit)
|
--- Prod 4
Prod 5
```
- The BOMs for Prod 1 & 3 must have a routing set, to generate
workorders
- Create a MO for 1 unit of Prod 1, process to the end
2 units of Prod 1 are created instead of 1.
This is due to the WO for Prod 3 not having a `next_work_order_id`.
Therefore, `record_production` adds an extra quantity at:
```
production_move.quantity_done += self.qty_producing
```
To prevent this, we set as `next_work_order_id` of the BOM of Prod 3 the
WO of Prod 1.
Closes#19527
opw-1817398
Starting with the 1000th user, the kanban view returns the id value
as '1,001', which, for some reason, does not go well when trying to
find the attachment by url...
Use `raw_value` instead, which does not format the id value.
Depending on the situation, it is possible to have move with origines
and destinations that have a loop.
A simple example is a return of a return, the origin and destination of
the return of a return is the return itself.
opw-1845444
closes#24787
Mercury can partially approve transactions in case a card does not
have enough credit available to cover the full amount.
Before this the payment amount was kept as the full purchase amount
leading to a difference between what Mercury charged and what Odoo
registered as charged.
opw-1840946
Before this commit, some records in a list did not show the name of their
many2one fields.
This case occurs when the records in the list are created from a default_get,
and the records do not fit in a single page. In that case, the records in the
first page correctly display the names of their many2one fields, but not the
records in the other pages.
Fixes#24547
Before this commit, when a list contains records with many2one fields that
contain the same values, duplicate ids were passed to the server on rpc
`name_get`.
For instance, if 40 records in a list refer to a Unit of Measure with id "1"
whose displayed_name is "unit(s)", the server receives a long list of ids with
simply the value "1". Also, the server responds with a list of displayed_name,
in this case a list of 40 strings "unit(s)".
With this commit, we always pass unique ids to the server on rpc `name_get`.
Odoo puts in cache all stored fields of a recordset when you access the
first stored field not already in cache. In this particular case, Odoo
will put in cache all stored fields of 'mail.followers', which is
unnecessary and time consuming, especially on models where user follows
plenty of records.
With thousands of followed records, using a read() when searching on
followers is around 2.5 times faster than using mapped().
Record rules based on followers are speed up the same way.
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
Backported from fd4939dc78
Before this patch the registry and cache signaling was only activated
for PreforkServer. In case Odoo was deployed in a multi process/multi
threaded architecture the signaling was not ensured, causing registry
de-synchronisation amongst threaded servers.
When posting an svg image, Odoo tries to resize it for thumbnailing
(like any image).
However this is of no interest since this is a vectorial file format, and
furthermore it distastefully makes the image library Pillow crash, since it only
supports raster formats.
The result would be a broken thumbnail instead of the image itself.
By not setting the thumbnail size if the mimetype contains svg,
we ignore the thumbnailing altogether.
Note that this only applies to the admin user, as otherwise the file is
treated as binary and thus no thumbnailing occurs anyway.
opw 1841153
* [FIX] mrp: negative workorder issues
- In the onchange of the qty_producing in the wo,
we need to add the date to the stock.move.line as
it is a required field.
- When starting a workorder, check first if it has
not already been done.
Commit bcd4c90 was intendend to make get_file handle uncaught/unserialized exceptions
in the context of a http request
The drawback is that when get_file received a serialized exception (route: /report/download)
the JS modal was empty in that case
This commit handles both the cases
OPW 1848606
closes#24794
When opening the activity dropdown in the kanban view
of the opportunities,
the activity type names were not translated in the user language.
In addition, when marking it as done, the message
posted in the discussion thread of the opportunity
was not translated either.
opw-1847908
- Use a shipping method costing $ 1.00
- Buy a product costing $ 1.00
In the payment page, the delivery cost is displayed `$ 1.00`, while the
subtotal is displayed `$ 1`.
- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
- No delivery amount is set
- Change shipper to one which doesn't cause an issue
- The delivery amount is set
- Switch back to the shipper with error
The delivery amount stays set, while it should change back to zero.
Every time we update the carrier, we automatically remove the delivery
line. One will be added back if the rating succeeds. Moreover, we update
the prices even if the rating doesn't succeed. Since the delivery line
was removed, the price will be updated without delivery.
opw-1838765
- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
- The 'Delivery' amount (next to the total/subtotal) is not displayed
- Change shipper to one which doesn't cause an issue
The 'Delivery' amount is still not displayed.
The amount is displayed if there is no issue at first rendering of the
page, but never re-evaluated afterwards.
The 'Delivery' amount is now displayed if there is a shipper on the
order.
opw-1838765
- Set up as a shipper with the highest priority one which will cause an
error (e.g. service not available for customer address)
- Order a product on eCommerce, go to Payment page
- The error "Ouch, you cannot choose this carrier!"
- Change shipper to one which doesn't cause an issue
The error is still displayed.
The error is displayed at first rendering of the page, but never
re-evaluated afterwards.
There is no other choice than removing it. Anyway, in the opposite case
(default shipper is OK, and then select one which causes an error) the
error doesn't appears.
opw-1838765
This patches fixes the untested and broken draft of inetd and systemd
activation support in the threaded server.
This patch also fixes the loss of the process environment in the
`_reexec()` function when Odoo is respawning during the following events:
- SIGHUP signal is received
- one click install has been triggered
- code reload needed when using `--dev=reload`
When creating a new company, the fields customer/vendor location
were empty.
Now, these fields are set with the internal transit location for the company
of the partner and set with Partners Locations/Customers and Partners Locations/Vendors
for the other companies.
opw:1845753