- 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.
The order of production was first based on "priority DESC" and then
"date_planned ASC".
So for production with the same priority/date_planned the order is not
deterministic.
This commit make the order deterministic as it seems preferred.
opw-784243
closes#21644
Since 7b3796d77c, view attributes are
validated against use of invalid field names.
However, the use of `global` field is a special case due to fact of
being a python keyword.
Rewrite the python expression to avoid using it, while keeping the same
visual effect.
Close#21631
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
Was PR #20581. Was task 29922
The bug is also present in enterprise but the required style of
enterprise makes the bug invisible. The bug has also been naturally
fixed in 11.0 thanks to the views and design refactoring.
Thanks @auyeung112002 for the original fix.
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.
Without proper group restrictions many computed/related fields will
crash because they depend on other group-restricted fields, such as
the `children` field.
When you have e.g. an SO with a product MTO generating a manufacturing
order, and you put the delivery order to done, before the MO is done,
you can not cancel the MO anymore, because the cancel method checks if
the move is not done (and raises an error).
As the user stays blocked in this case, it is better to just not try to
cancel the destination move by not propagating the cancel when the destination
move is done.
opw-786571
When you have e.g. an SO with a product MTO generating a manufacturing
order, and you put the delivery order to done, before the MO is done,
you can not cancel the MO anymore, because the cancel method checks if
the move is not done.
As the user stays blocked in this case, it is better to just not try to
cancel the destination move by not propagating the cancel when the
destination move is done.
opw-786571
Once installed, a standard employee cannot open a employee form view since this
field was computed and that field children is not allowed without group hr_user
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.
Before this commit:
To know if an event menu is an auto generated one (eg: location, register..),
it checks if the menu name is the same as the hardcoded one in
_get_standard_menu_entries_names.
If user change the menu name, the code won't retrieve it and will act as if the
menu had been deleted and it will recreate it.
This leads to 2 bugs:
*First (website_event)
- Change menu name from website_event (eg: location, introduction or register)
- Check/Uncheck 'Track on website' or 'Track Proposals on website' to force
the code to rewrite missing menus.
- Go back to the event front end, theses menus have now been recreated, and
are duplicated.
*Second (website_event_track)
- Check 'Track on website' on event's back end
- Change the 'Talks' menu name in front end
- Go back to backend, 'Track on website' is unchecked because
_compute_website_track won't retrieve an event menu named exactly 'Talks'
Now:
We don't use euristics to try to recover missing menus.
We just create related menu when option is checked, and we delete them when
option is unchecked.
To know which menu item comes from which option, we store a value in a new
model 'website.event.menu'.
We don't want to try to check if the menus are all there and recreate them if
needed anymore. There is cases where user wan't to delete a menu and repace
it with a link to that menu's URL in the page content.
Before this commit, the option would've been unchecked since it won't
retrieve the menu.
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
This technical dependency module adds settings to res_company for the
company's social media pages.
It is introduced to fix duplicated fields for res_company in website and
mass_mailing, these two modules now require social_media as a dependency
Add the context manager method `assertQueryCount` to count queries,
the decorator `@users(...)` to execute a test for several users, and
the decorator `@warmup` to execute a test twice (warm-up, then real).
Creating data directly in tests was done when tests were located in mail
module to avoid creating real data or demo. Now that mail tests have their
own module we can create demo data and use them in tests. It is simpler to
have demo data for things like subtype and email templates to ease
understanding and reuse.
Nicolas Martinelli