When a user was closing a POS to go into the backend, and click on "Reprendre",
there was an error which prevent him to reopen the POS.
There was a confusion between object <datetime> and <datetime.datetime>, as
the previous code was trying to use the function timedelta() from datetime.datetime
instead of datetime. As a result, the error states that datetime.datetime has no
function timedelta.
opw-801523
- Activate Work Orders
- Go in MRP > Reporting > Work Orders
The status filters ('Ready', 'Pending'...) do not work.
This is because the action forces the domain to `[('state','=','done')]`
instead of using one of the available filters.
opw-788043
The stock_history view is generated from by grouping of move from
sources and move to destinations which depending on the request and
number of request can be rather slow.
This fix replace a possibly high number of request by a slower number.
On a production instance, doing an inventory at a choosen date:
- with 300 stock moves, went from 4 minutes to 4 seconds,
- with 130 000 stock moves, went from 66 minutes to 10 minutes
opw-765793
closes#19594
Before this commit, one could choose the App Switcher as his Home action.
and arriving on /web would trigger an infinite loop at startup
After this commit it is not possible to choose the App Switcher as Home action anymore
OPW 800323
Commit 74e4130f5f makes sure to make the accounting date prevail on
the invoice date when it comes to currency conversion.
However, the choice of date is not universally recognized. Softwares
(and accountants) might use either the accounting date or the invoice
date.
Therefore, we provide a hook se the behavior of the software can easily
be changed if necessary.
opw-783372
When the unit price of a kit is computed in anglo saxon accounting, the
average price of kit parts is not multiplied by the quantity of this
parts in the bom.
E.g.: a kit of 2 prod1 and 1 prod2, when the price is computed, it only
take into account the cost of 1 prod1 and 1 prod2 to compute the kit
cost instead of 2 prod1 and 1 prod2
opw-786268
- Create a MO which generates WOs
- User 1 starts working on it
- User 2 starts working on it
The field 'Real Duration' only displays the time spent by the user
connected. It means that there will be an inconsistency between the
field 'Real Duration' and the list of durations shown in the `time_ids`
field.
We want to keep 'Real Duration' limited to the current user, because it
should represent the duration updated in real time (done in widget
`mrp_time_counter`). However, we also want to see the total real
drations for all users. Thereofe, we simply update the view to show the
total in the list view.
opw-784456
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.
Alexandre Kühn