The ir.actions.todo record base.open_menu is used to redirect the user
to a menu after installing a module.
To do so, a new module override the record changing its action (toward a
menu) and setting its state to "open".
But with f7fe753 when one such changed action is removed after
uninstalling a module (or removing the action by any other way) the
base.open_menu would also be removed. Thus thereafter the open_menu will
not work anymore (since type "automatic" is lost).
With this commit, when whenever base.open_menu is removed, instead its
action will be replaced by base.action_client_base_menu which is the
original action.
closes#11224
related to: #11216, opw-660269
When creating thousands of production lots in batch, the
extra call to write() cuts performance in 2, and can be
replaced by an appropriate context when calling super(),
as all the default values are computed correctly.
The only case that could possibly fail is when the product_id
is not passed to the create() call but comes instead from
defaut values (ir.values).
This case is very rare and considered a manual exception
where the expiry dates can be input manually.
when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.
It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.
opw-670972
Closes#10375
Up to this revision, barcodes set in reports are generated
using the controller `/report/barcode`,
using a `img` HTML tag, e.g. (from `report_location_barcode`)
```
<img t-if="not o.loc_barcode"
t-att-src="'/report/barcode/?type=%s&value=%s&width=%s&height=%s'
% ('Code128', o.name, 600, 100)" style="width:300px;height:50px"/>
``
This `/report/barcode` route is set as `auth='user'`, meaning
the route can only be accessed by signed in users.
When wkhtmltopdf prints a report containing such a barcode,
it calls this `report/barcode` route, making sure to pass
the request session in the cookies, so wkhtmltopdf
uses the same session than the one of the user. This is
needed, as only users can access this `report/barcode/` route.
This session is passed in `report.py`, in the method
`_run_wkhtmltopdf`, thanks to the --cookie wkhtmltopdf
parameter.
Nevertheless, if a report is printed through the website
front-end, as public (without a signed in user), the request
session is not associated to a signed in user, and therefore
the route `/report/barcode` refuses the access / redirects
to the login, making it impossible to print a report
containing a barcode without being signed in. This even
if the report is printed as `sudo` through a controller
(as this is the session of the not signed in user which is passed,
not a session associated to `sudo).
Fixes#10621
opw-667797
It looks like reportlab doesn't handle well
UPC-A barcodes.
As UPC-A barcodes became EAN13 barcodes when
adding a `0` to the beginning of the barcode,
and the render is the same, we ask reportlab
a EAN13 barcode type when a UPC-A barcode is asked,
making sure to add the `0` automatically first.
From Wikipedia:
```
The EAN was developed as a superset of UPC,
adding an extra digit to the beginning of every UPC number.
[...]
the original rules for UPC are treated as a '0'
if read as EAN-13.
A UPC barcode XXXXXXXXXXXX therefore is the EAN-13 barcode 0XXXXXXXXXXXX.
It is possible to prefix a UPC barcode with a 0;
they become EAN-13 rather than UPC-A.
This does not change the check digit.
All point-of-sale systems can now understand both equally.
```
opw-670560
I'm not sure why the serial timeout is so aggressive, but I assume there
is a reason for it. During probing however, we shouldn't use such an
aggressive timeout because if we miss the device during initial startup
we'll never find it since we only probe devices once.
After plugging in multiple identical serial to USB interfaces, only the
last one will be available under /dev/serial/by-id/ because they'll have
identical IDs. Instead use /dev/serial/by-path/ which does not have this
issue.
We support the Mettler Toledo scales which have their own built-in USB
to serial interface. Due to continuing issues with that built-in
interface we will also support the scale configured in raw RS-232 mode
which seems to be more reliable.
This means that in order to connect the scale you'll need a third party
USB to serial interface (unless you have built-in serial interfaces, but
the POSBox doesn't).
The main difficulty this poses is that using this approach we cannot use
the name of the interface to find the device. When using the built-in
interface of the scale the interface would identify with an ID
containing 'mettler' and 'toledo'. When using a third party interface
the ID will instead contain information about the third party
interface. To fix this we use a probe-based approach, probing every
available serial interface until we find one that returns a response to
our probe. This approach will work with both third party interfaces and
the built-in interface of the scale.
Contrary to probe-based approach used in hw_blackbox_be this one is
slightly more complicated because hw_scale is written in such a way that
it is 'plug and play', which means that as long as the module is running
it will continually try to find a scale. This is fine, but we don't want
to keep sending probes to eg. Fiscal Data Modules, which could lead to
issues. Therefore we will only probe every device once. When we lose an
existing, confirmed connection to a scale we will however keep retrying
to connect to that particular device.
The alternate languages links set in the page `<head>`
were not translated in each language, but within the language
the user is browsing the website.
This leaded to SEO referencing issues, as these links leaded
to (30x) redirections if followed, to translate the URL slug
within the new current language.
e.g.
`/fr_FR/shop/product/bose-mini-bluetooth-speaker-7`
automatically redirected to
`/fr_FR/shop/product/mini-haut-parleur-bluetooth-bose-7`
And it was the first link which was displayed as alternate link
when being in another language than French, while it should
be the second (to avoid the useless redirection).
opw-669979
When we render the payment screen the current value of the current
paymentline is rendered to a string using
Paymentline.get_amount_str(). This conversion always rendered numbers
with a decimal separator of '.' because it just used
Number.toFixed(). This used to be fine but
5a10903e9b made the POS adhere to the set
decimal and thousands separator. Because of this, the POS now has to
parse the input with web.parse_value() which takes into account these
separators. When parse_value() parses a float it first deletes the
thousands separators and then replaces the decimal separator with '.'
before it gets cast to a Number.
In German (and other languages), the '.' is used as a thousands
separator which means that it will get deleted by parse_value() so
you'll end up with '12.34' being interpreted as '1234'. Because of this
it is important that we ensure that the default value that appears in
the input uses the correct separators.
The aforementioned issue only occurs when the user changes the default
value in the paymentline. Only then does a conversion take place from
String to Number. So just clicking on a payment method of type 'Bank'
and validating it would work fine, only when the payment amount was
updated would the issue occur.
Fixes#9395Closes#10952
note: this should not be forward-ported to >8.0 because later versions
use the rewritten payment screen which is completely different from the
one in 8.0.
The intrastat report period should match the accounting period of the
invoice. This might not be the case if the user manually chooses an
accounting period which does not match the invoice date.
opw-668827
In an environment where multiple database are available the company_logo
controller in the web module will return a placeholder logo (the Odoo
logo) if it can't figure out what db the request belongs to. This logo
is used on the ESC/POS receipts.
Because we load the logo with an anonymous CORS request there is no
authentication on the request. This is necessary because the POS tends
to not be served over HTTPS whereas the rest of Odoo is. Without this
crossOrigin attribute we could potentially end up in a situation where
the canvas is considered tainted by the browser which would prevent us
from extracting the canvas' data with toDataURL(). So removing the
crossOrigin attribute is not an option, specifying the db is the next
best thing.
opw-670471
note: in >=9.0 session is a variable defined in the js module instead of
a property on PosModel, so 'self.session.db' should become 'session.db'.
From issue 660592. (already fixed in v9) When products are received from a purchase line
with taxes included, the cost for the stock valuation (on the stock move) on reception
should be without these taxes included.
Checking url_list for duplicates is O(n).
Use url_set instead of url_list to improve to O(1).
Otherwise sitemap generation even for a million products will never finish.
Close#11106
If an event is private, a bunch of fields
are hidden for the users not being
the owner of the event, even for sudo.
The fields on which depends the `rrule`
computation were part of the hidden/private
fields.
In addition, the `rrule` is always computed
as sudo. See `_get_rulestring`.
Therefore, the `rrule` of recurrent private events
was not correctly computed when the owner wasn't
the administrator.
opw-670295
Iterator was consuming the first 45k records.
So don't need to specify an offset, because that will ignore the next 45k.
Eg: if step of 5, and range(1,13),
it will only use [1, 2, 3, 4, 5, 11, 12, 13]
Cherry-pick/backport of de8296c3a86da5e4ae35edcdb563d317dac32e76
The Sales Details report wizard gives the possibility
to print the details of the POS orders between two dates.
The fields in the wizard are of type `date`,
while the orders dates are of type `datetime`.
`00:00:00` and `23:59:59` were naively added
to the `date_start` and `date_end` (respectively) to
handle the case.
But, this doesn't take care of the user time zone:
When a user choose between February 24th and February 25th,
it's within his time zone, and therefore, for the search,
where the datetime are in UTC, adding `00:00:00` isn't enough,
the dates have to be converted from the user time zone
to UTC.
opw-6698831
CSV export was added in f146e2a and since then newline were not
exported.
But new line should be allowed if the string is quoted by " characters
which is done in Odoo.
closes#11005
opw-667853
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
In the case of a `raw_data` export, a boolean which has the value
`False` will not be exported correctly.
The fix handles the `False` value as a valid value for a field.
opw-666142
The product price unit should be rounded before being used in any
operation. The PoS calls the method `read` in order to get the necessary
fields. However, the product price is a non-stored calculated float. In
old API, such a field is not rounded by the `read` method. It means that
a product price of 28.067 (for example thanks to the use of a pricelist)
will be rounded to 28.07 at the server level but not rounded in the PoS
JS layer.
To lower the impact of the fix, the rounding is done at the JS level,
and not in the `_product_price` method.
opw-669024
The month used for an intrastat.report record must be the same as
the invoice_date set on the invoice.
Backport of d1d896621fffc79c73aeee07c8cb1c7a49a36411
opw-668827
In the base model `account.voucher`, in the module `account_voucher`,
the field `number` is set with `copy=False`, to avoid
copy the voucher number and force to re-use the voucher sequence.
The module `account_check_writing` redefine this column,
but forgot to set the `copy=False`. Therefore, once
this module installed, the voucher number is copied
on the voucher duplication.
opw-669154
DO NOT FORWARD-PORT: the functionality is not used anymore in v9
Commit aaf9badb filters the returned ids by keeping the domain in the
request. However, `this.dataset.domain` might be empty, while
`self.dataset.get_domain()` will retrieve it from the model.
Since `get_domain` is not always defined on the dataset, we keep
`this.dataset.domain` as a fallback. The fix is not great, and a better
solution should be found in master branch when the web refactoring is
done.
opw-666755
When an "hr.holliday" record is created or modified, the employee_id
linked to this record has to be added in the followers.
Inspired from ff1d384
opw:668515
It was like that for the date field, which is taken into account for the forecast quantity,
but in the view the scheduled date field is shown. We put the scheduled date equal to the date.
That way it is clear to the user when the products are foreseen to be consumed.
The revision 29bd622521
aimed to improve the performance by changing
the view index, to use a BIGINT instead of a text.
It was assumed that the index used
(`stock_move.id`) could not appear
multiple times with the JOINs and
group bys defined.
This was in fact possible, if a
stock move is associated to
several quants with different costs,
because of the JOIN on the many2many table
`stock_quant_move_rel`
linking quants to moves,
and the GROUP BY
`price_unit_on_quant`
that caused the different moves/quants association
not to be merged within one unique line
if the costs on the quants are different.
Instead of the group by, we now aggregate the quants
costs, using the weighted average, so the index
used can be unique, as expected.
From now, the inventory value per line in
this report view can therefore
be different than what can be found on the quants,
but this report view is based on the stock moves
rather than the stock quants, and this is therefore accepted.
In other words, the inventory value is computed for the stock move
rather than for the stock quant.
opw-658903
Use the same factor than the one used when
computing the products to consume at confirm.
Before, the quantity of products to consume was wrong
when using a different unit of measure in the BOM
than in the production order.
e.g.
- BoM defined as:
- 1 dozen of milk
- BoM lines: 1 cow
- Production order:
- 1 unit of milk
- BoM: The above one
At confirm, the quantity to consume is 0,083 cow (1 cow / 12, this is correct)
But, when updating the quantity to 2.0,
it updated the quantity of cow to 24.0, instead of 0,16.
opw-669447
Goffin Simon
Nicolas Lempereur
Odoo Translation Bot
Olivier Dony
eLBati
Denis Ledoux
Joren Van Onder
Martin Trigaux
Nicolas Martinelli
Jeremy Kersten
Christophe Simonis
Josse Colpaert
Anton Chepurov
Stéphane Bidoul
Atchuthan
Alexis de Lattre
Daniel Dico
Javier García-Panach
Antony Brugger
Andrea Stirpe
MORIN Fabien
Adrien Peiffer (ACSONE)
Yoshi Tashiro