- Added taxes for year 2018 of sales and purchase with percentage 3.7 and 7.7
- Added tags to show newly added tax in VAT report(enterprise branch) for Switzerland
Was PR #20851. Was task 39082.
- Added latest taxes for year 2018 of sales and purchase with percentage 3.7 and 7.7
- Added tags to show newly added taxies in VAT report(enterprise branch with PR #1628) for Switzerland
- Added fiscal positions mapping as well.
Was PR #20851. Was task 39082
Summernote uses `document.execCommand` to apply most styles when
editing, leveraging the implementation to the browser.
Summernote is configured to use HTML styling (`'styleWithSpan': false`),
and in this case, browsers such as Firefox use HTML attributes for
styling text align, while Chrome still uses CSS for that. In fact,
`document.execCommand` is browser-inconsistent... but so is the
`styleWithSpan` option. Indeed, setting the option to `true` will make
Firefox use CSS property for alignment too... but not Internet Explorer.
So we might consider changing this option's value but this would not
solve the current problem.
Indeed, any CSS `text-align` style in Firefox takes precedence above
the element's `align` attribute, so when users were trying to align text
on stuff that was pre-aligned, they were unable to do so.
We can better explain the situation with this example:
A user tries to left-align in Firefox a `p.text-center` element, and
produces this:
```html
<p class="text-center" align="left"/>
```
(`align` attribute is ignored because of the `text-center` class)
On Chrome, this would be produced with the same steps:
```html
<p class="text-center" style="text-align:left"/>
```
With this patch, we actually make that HTML look like expected by the
user, no matter the browser he's using, by forcing the editor to use
the text-align CSS property. Note that the implementation is quite
ugly but had to take care of compatibility.
See https://github.com/odoo/odoo/pull/20900
(thanks to @Yajo for original PR)
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.
This rev. introduces two helper functions for the tests: patch
and unpatch. Those function allow patching an Odoo Widget (e.g.
AbstractField), and unpatch it at the end of the test with the
guarantee that the Widget's prototype is exactly the same as it
was before the test.
This was necessary because the way it was done before was a little
bit too naive, and could lead to unexpected behavior. Indeed, doing
var someFunction = AbstractField.prototype.someFunction;
// test content
AbstractField.prototype.someFunction = someFunction;
is correct if someFunction is actually define (or overriden) in
AbstractField, as in that case, it really exists on its prototype.
Otherwise, it isn't correct if it is not directly defined on the
prototype before the test, as it will be after..
The 'on_reverse_breadcrumbs' option of do_action() allows to
define an handler to execute when coming back to the previous
action by clicking on the breadcrumbs.
This option was set when executing the Import client action, to
ensure that the previous view was reloaded when the client action
was left. However, the view to restore is always reloaded, so
specifying the option in this case produces a double reload.
- 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
qdp-odoo