The VAT declaration produces an error when uploaded to the official
website. Although the structure is correct, the "Representative" and the
"Declarant" contain the same information, which is not consistent.
opw-702066
Both store triggers on reconcile_ref are triggered by the same condition,
but seen on 2 tables different, but they always happen together, so no
need for both.
On regular Odoo, the only problem is the performance: the write operation
is performed twice, but on a system with connector or other parallelization
technology, this provokes lot of concurrency problems.
With the previous condition, the `final_date`
was not recomputed when the number of repetitions
(count) was changed alone, without changing `recurrency`
(nor with other fields, such as start/stop date)
This revision makes sure to recompute the `final_date` when
there is a change in the number of repetitions without
changing the `recurrency` fields, when the event is recurrency
and the end type is `count`
opw-703812
The double inversion introduced by 6e063188 is done to catch default 0
values.
For example '>= -3' is transformed in "NOT what is found by < -3".
There was an issue with '> 0' and '< 0' since in these instance 0 don't
match and the inversion must not be done.
opw-703929
This commit fix wrong grouping when we format price via price_to_str.
where '[3,0]' was interpreted as string and not array in intersperse.
Thousand separator was duplicated ",,,320.00" e.g.
This commit fix also product page where amount for variant was formatted
js side before that RPC translation (website.ready() defered) was resolved.
'/website/translations' is only called when user have rights to edit page.
So a standard user didn't call it and l10n is not initialized.
After an update, now we format the amount with the l10n value.
To stay retro compatible, if l10n is not initialized (value = [])
we use [] for grouping as 'fallback value'.
To fix decimal precision you need to update the template product_price.
To fix the grouping, you need to update the website.layout
To fix the decimal separator, (and previous fix), you just need to pull the JS
This commit is related to #1103, #11553, #14772, #14874, ...
And fix the previous fix odoo/odoo@1f10ef8055
It should also fix (by side-effect) the translation JS for user without editor
right.
Already fixed in V9 - don't forward this commit...
When reading customized views from our dashbord in reporting,
the measures selected in the customized views were not taken into
account. It happened when the customized view was build from a report.
opw:698105
When syncrhonizing an allday event while being in a negative timezone
e.g. Dec 22 in US/Eastner (-5:00)
The event was synchronized the day before
e.g. Dec 21
because `context_timestamp` of `start date-time-` was used,
and then the time was removed to have the date of the all day event
e.g. 2016-12-22 00:00:00 converted to 2016-12-21 19:00:00 and then the time
removed 2016-12-21.
Instead of using the `start_datetime`, we now use the start
date which stores only the date, without timezone information
(and this is what you would like in the case of an all day event).
opw-697202
While choosing a start/stop datetime in a timezone hour
were the UTC value is within the next day,
e.g.
Start time Dec 22 20:00 in US/Eastner (UTC -5:00)
Therefore, start time Dec 23 01:00 in UTC
Checking the "all day" box made the start time set to
Dec 23 instead of what the user expected, Dec 22.
This is because the onchange simply took the UTC datetime
(Dec 23 01:00) from which it removed the time (Dec 23).
This revision make sure to remove the time from the
user timezoned datetime instead, so the day set
remain the same day than what was set in the datetime.
opw-702065
Event with interval > 1 was not correctly computed.
This patch doesn't fix existing event but only the new one created after this fix.
Event 1/1/2015 repeat every 3 months, 6 times
Before this commit : end recurrency = 1/1/2015 + 6 * 1 month
After this commit: end recurrency = 1/1/2015 + 6 * 1 month * 3 (interval)
This commit closes#14332
Fix datetime where the return of rrule is sometime a list,
sometime a set according to the datetime version.
list(set) == list(list) and works in both cases.
Similar fix: #9f09c62
Do these steps:
1. Create a partner.
2. Grant him portal access through *Actions > Portal Access Management*.
3. Delete the created user.
4. Delete the partner.
You will get this error:
```
Odoo Warning - Validation Error
The operation cannot be completed, probably due to the following:
- deletion: you may be trying to delete a record while other records still reference it
- creation/update: a mandatory field is not correctly set
[object with reference: Portal User Config - portal.wizard.user]
```
This happens because the wizard (which is a transient model) does not let the partner to be deleted.
With this patch, we avoid that bug.
Closes#12608
As the number of holidays are float, we may get a flloating point error when
comparing and having -0.0000000001 instead of 0 for the number of remaining
leaves, making the test fail.
Closes#12809Fixes#14643
The requirement for somebody to choose a ticket product should be that it is an
event, not that it has an event type attached, mostly when `event_type_id` is
not a required field.
The event has been improved in upper version but as this field is only
informative, relaxing a bit the domain.
Closes#12475
When sending an email via the mail.compose wizard, the selected partners are
stored in the context (`active_ids`).
If the composed message is saved (button "save template"), the context is lost
in the _reopen action.
The active_ids content of the new context is the id of the newly created mail
template and is used as the id of a res.partner (sending the email to a
different contact).
Keep the context during the reopen to avoid losing active_ids.
Closes#11947
The account move line created for a tax must have the right account_analytic_id
according CONDITION.
CONDITION(inspired from function compute defined on model "account.invoice.tax")
if the tax is for an "in_invoice" or an "out_invoice" => tax_code = 'tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_collected_id'
if the tax is for an "out_refund" or an "in_refund" => tax_code = 'ref_tax_code_id'
=> the account_analytic_id of the tax must be set to 'account_analytic_paid_id'
note:forward-port upto saas-6
opw:694821
Christophe Simonis
Nicolas Martinelli
qdp-odoo
Pedro M. Baeza
Odoo Translation Bot
Leandro Di Pasquale
Denis Ledoux
Nicolas Lempereur
Raphael Collet
Jeremy Kersten
boogerlad
Luc De Meyer
Goffin Simon
rigo1985
jclopezar
Alexis de Lattre
chafique-delli
Damien Bouvy
javierjcf
Nicolas Mac Rouillon
Jairo Llopis
Alexis de Lattre
Jairo Llopis
Hans Henrik Gabelgaard
Jordan Vrtanoski
Martin Trigaux
Stefan Rijnhart
Pere Albujer
Julien Laloux
Moises Lopez - https://www.vauxoo.com/