The condition in `_free_reservation` explicitely ignore move lines
having a done quantity. Let's imagine the scenrario where two stock
moves reserve all the quantity available and the user chose to process
all the quantity in a move while another user already set half the
quantity as reserved. In this case, we should keep the processed
quantity on the other move but correctly remove its reservation.
- Create an event with tickets
- Add the event in a SO
- Confim the SO
- Apply
An error occurs (record deleted).
Actually, the real error is hidden and is an insertion error in SQL on
`registration.editor.line` (`event_id` cannot be NULL).
`event_id` is mandatory but read-only, therefore it is not sent to the
server.
opw-787674
[FIX] l10n_fr_certification: main module
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf
This document states that only business operations with partners not being subject to VAT should be inalterable and secure.
We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves
Protection against account_cancel is not necessary anymore
By default, this module considers a sales journal being a b2c, thus activating hashing on its move.
Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed
[ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis.
The module adds following features:
- Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries
- Security: chaining algorithm to verify the inalterability
- Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users)
[ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales.
(both of the period and cumulative).
This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data
Adaptation of #20581 for version 11.0.
Bugs introduced with commit https://github.com/odoo/odoo/commit/08e92204b661086b27a2d435d3ca06436540c0e0
- The new `rainbowMan` option was always `true`
- When checking the option, it was looked in the wrong object so it was
always considered false (so no more rainbowMan at all...)
Also deactivate the rainbowMan for the automatic tours.
Also refactor the method's documentation.
The checksum computed to verify the version of the assets includes a list of
files as JSON. This JSON is generated from a list of dictionaries.
When using Python <3.6, the ordering of the dictionaries is not guaranteed which
lead to unnecessary rebuild of assets. Particularly when starting Odoo on more
than one host, the current implementation hits this issue:
* server 1 computes the checksum with an ordering and generates the assets
* server 2 computes the checksum with a different ordering and generates the assets
* server 1 computes the checksum with a different ordering and generates the assets
* And so on...
Which obviously lead to disastrous performances.
Before this commit, editing a website.menu (linked to a website.page (m2o))
would not save the URL on the website.page record but only on the
website.menu.
But since the URL retrieved to display the website navbar is:
1. The website.page url if the menu has a page_id
2. The website.menu url otherwise
It would never get the edited URL stored on website.menu
Clean method _add_dispatch_parameters
Remove unused code for caching
Call super before to have the correct lang when we browse website.
Without it, menu was not loaded in correct language.
Steps to reproduce the bug:
POS -> Settings -> Enable Price Control.
Login with user with POS -> Manager rights
Open POS Session.
Bug: Price Option was disable.
opw:784422
Use case to reproduce:
- Go for a delivery order and use show detailed operations mode
- Have something reserved on a picking
- Manually delete the stock.move.line
-> The move state is not adapted to the new state of the stock move lines
It happens because the move state is not computed not
update on the move line unlink method.
This commit use the existing move function in order
to compute the state and add a test.
A part of test_stock_flow_74 is updated. Since procurement
refactoring make a move mto and confirm it will not work
since purchase or mrp are not install (Usererror). Also do an unreserve
on a draft move is not a real use case and should not pass
it in waiting since moves orig are never created.
The package weight is computed by summing all move lines related to it,
which is wrong, because if you have a package that is in two pickings,
its weight will two times bigger than the real weight.
To fix this, we will compute the weight based on the quants in the
package, except if we are opening the package from a pickin, it's weight
will be the sum of move lines of the package that are in the current
picking. This allow user to see the weight of a package after a put in
pack when there are not yet any quants in the package
- delivery slip: remove mention of packages
- package: fix the report's traceback
- picking: moved the packages references to a table at the bottom of the report
Have the following location structure: Loc A -> Loc B -> Loc C
The `complete_name` fields are:
- Loc A
- Loc A/Loc B
- Loc A/Loc B/Loc C
When changing Loc A to Loc D, the `complete_name` are:
- Loc D
- Loc D/Loc B
- Loc A/Loc B/Loc C
Compute `complete_name` of stock location using `complete_name` of
parent instead of parsing the full bunch of ancestors. This improves
the computation speed, and moreover solves the recursivity problem.
Closes#21585
We have problems when trying to validate our EU VAT report because some vat number are wrongly encoded in Odoo.
There are 2 problems:
1) We use vatnumber library to check the validity of the VAT number entered by the user on website.
That library removes the following characters '.' and '-' in order to perform the check and
thus can return True for a number like 123.123.123.13 or -123-3454-34
And those VAT number are then saved in our database but are rejected by the state
as VAT number should only contains alphanumeric character
-> Solution: prevent entering vat number with other characters than alphanumeric for users that are located in EUROPE!
2) Usually VAT is prefixed by country code, however some people in europe managed to bypass the system
by prefixing their VAT number with CC instead of their country code, CC is consider valid in odoo
(it means Country Code) but is not a valid European country code in general, which means that those
people that should have pay some tax have not. Which is a huge problem.
-> Solution: prevent the use of CC as country code by the user when entering a vatnumber only if the user country is in EUROPE!
source: https://en.wikipedia.org/wiki/VAT_identification_number
opw:785443
costs_hour field no longer exists
Some modules in a different repository (let say enterprise), may be still using
it but it is not its place here.
For stability reasons, we keep the computation if an external module adds the
missing field anyway
Fixes#16269Closes#20899
Improve performance (* 2.5) on _compute_reserved_availability
`mapped` makes use of orm prefetch, which is inefficient in this use
case when facing high volume.
Closes#21198
Two fiels are set readonly according to the status of the purchase
order: product_id and product_uom_id. They become readonly once the
purchase order is confirmed, but according to the options a user is
still able to add purchase order line. Make sure to always send the
required fields to the server.
Fixes#21519
On MS Windows, the mimetypes module relies on the Windows Registry to
guess mimetypes. As a consequence, when generating assets bundle for
javascript files, the mime type of js files may be wrong. In that
particular case, the Odoo user is facing an empty web page.
This commit enforce 'application/javascript' for js assets when they are
saved as ir_attachment in the database.
This commit is a backport of 77ca51f
When a stage on crm leads is removed, the leads appear in an
"Undefined" column in a kanban view, but this was not handled when
getting the "graph data" (eg. in version 11.0 for sales team graphs
when grouping by stage in CRM > Reporting > Sales Channels).
opw-784455
closes#21507
When adding a partner (without any backend or portal access) as a
follower of an invoice, project, task or SO, the mail received contains
a 'View ...' button. When clicked, it redirects to the login page.
In the case of projects and tasks, no `auth_token` exist, so the user
faces an access error in the backend. For the other objects, it
redirects normally to a frontend page.
This feature is not yet complete in v11. So simply hide the button until
this is properly developed in master.
opw-785824
I clearly missed some bits in 01e3514147
as _get_access_token was still using urllib.Request despite that
import having been removed.
Fix it up by properly converting it to requests.
Fixes#21544
The ORM does not currently, an probably won't support two fields with
the same name in different modules that do not depend on each other.
This is obviously a nasty hack, but it's the best one can do for a
stable branch.
THIS IS WHY WE HAVE DEPENDENCY MODULES, PEOPLE.
Before this commit, if you had an uom with an unicode character as name, it
would throws an UnicodeEncodeError.
Now, since the str() parsing is not needed, removing it fixes the issue
This closes#20325
This closes#21374
It was the purpose of this commit fea667a243
However it uses purchase uom in any cases and not
only vendor bill.
This commit correct it by using it only if a purchase
order is linked to the invoice.
The 'main_flow_tour' noticed an error that we
had already corrected for the input fields.
See here: @a71f2237
In fact the same error can occur in the many2one fields
for the exact same reason.
It's why the 'main_flow_tour' crashed at the following step:
".ui-menu-item > a:contains('the_flow.customer')"
Before this commit M2Mtags widget did not translate.
This was because no context was given to the rpc that fetched the fields
Hence, the lang was not passed.
After this commit, M2Mtags translate well
OPW 784396
Pierre Masereel