Depending on the speed of the runbot, errors may appear if one tries to
use a template that is not yet loaded. Templates are being
loaded and we add new template to read, the ready function does not
take into account new additions.
The kanban view uses a template which comes from the server, already
translated. Before this commit, it tried to retranslate again the
template in qweb.js, which may be a problem (in addition to the useless
work): if some english string A is translated in B (french), but B is
also a valid english string which is translated into C in french, then
we will have a wrong result.
In this commit, we simply add a flag to disable the translation process, which
should also slightly improve the kanban view rendering performance.
Avoid texts to be translated twice if some modules have the translated
value corresponding to the English source term.
To reproduce: create a translation for static xml (comment 'openerp-web')
with 'Modifier' translated by 'Tadaaa'. In french context, the 'Edit'
button in forms is translated by 'Tadaaa'.
Don't translate template in web_editor if we are in the backend because
the translations of all the modules have already been loaded and applied.
Take account of the user timezone to compute the price for
pricelist rules with start / end date.
Before this revision, the date used to compare to
the dated pricelist rule is always the date of today
in UTC.
For instance:
- If a user is in timezone UTC +12
- The 10% discount on the pricelist starts on December 19
- It's currently December 18 13:00
The user did not have the discount,
because it was consdiered December 18,
while the user was already in December 19.
With this revision, we take account of the context
and its timezone to compute the date of today
and return the correct price according to the
dated start and end datetime.
opw-785203
Purpose
=======
Unbreak consistency check:
- on creation (check not done)
- when applied to a record set of several sheets belonging to different employees (reporting spurious errors)
Specification
=============
- self.something() in a api.model method does not make sense, so I replaced it with a call on the newly created sheet.
- Iterate on sheets instead of mapping all the lines
Purpose
=======
Employee must match on sheet and lines
Since the employee_id field of hr.expense.sheet is modifiable in submit state, there is a possibility to modify a sheet in such a way that the employee does not match on the expense sheet and expense lines. This commit fixes this.
When no input line is found in get_payslip_lines, the input line with
amount_python_compute = 'result = inputs.ARS.amount', the function __getattr__
on BrowsableObject returns 0.0 for ARS and raises an error for amount because
a float has no attribute amount.
Inspired from 9a6e7799fe
opw:785033
- 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.
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 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
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.
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
In some cases the MRP scheduler can remain blocked on an infinite loop
consuming a lot of CPU. The reason comes from the loop 'Check done
procurements'
If a new procument is created from another process (such like MTO
orders) during this loop, the process never ends.
The only way to reproduce is in debug mode:
1. Put a breakpoint on line 'Check done procurements'
2. Launch the MRP scheduler manually and stay paused on the breakpoint
3. In parrallel, create and confirm a sale order with a MTO route, this
will trigger the creation of a new procurement order in state
'Running'
4. Continue debugging step by step the scheduler and you will notice
that the loop never ends.
Closes#21565
opw-787651
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
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
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.
As the field digit doesn't exist on currency, we use decimal_places
instead which is the field containing the number of digits of the
corresponding rounding field
As there's a check for unique supplier reference numbers, you can't duplicate them as the field is copied on the duplicated record. This patch removes the copy for emptying the error.
@Tecnativa
Before this commit, when a localization defined default payable or receivable
accounts on partners (like l10n_do does)
The reconciliation tests that involve an invoice on the one hand and a payment on the other hand
broke just because the accounts of the payment and the one of the invoice did not match
After this commit, we force the receivable or payable account to be the partner's (if available)
and the tests do not break
Before this commit, when printing all orders from the POS interface,
the ticket sometimes showed weird amounts (like 128.25000000001).
This was due to the usual problem of representing a float and has nothing to do with Odoo.
After this commit, the templates correctly display the amounts, rounded according to the currency
We do this by applying the relevant qweb widget (or calling the right format function in JS)
OPW 784626
Related fields that are not readonly are rewritten each time you save the
associated record, provoking performance problems.
Moreover, we don't want to allow an employee to change its department through
an attendance record.
Closes#21441
In Pick - Ship:
- validate a sale order which scheduled date is an hour in the future.
- validate the WH/PICK picking
Before this commit the WH/OUT picking 's scheduled date was set a day in the **past**
This was due to the implementation of datetime substraction and timedelta, which,
in case of a negative value, would take -1 day and some complementary values (hours, minutes etc...)
(the difference is complementary)
After this commit, the WH/OUT picking 's scheduled date stays what it was in that particular use case.
OPW 784452
Christophe Matthieu