Since 76b7242 if we have a recurring event with 3 occurences:
[4th 4:00-4th 5:00] [14th 4:00-14th 5:00] [24th 4:00-24th 4:00]
And we detach the first one to modify it, then when getting the
info of reccurring events not detached the system get:
- starts: [14th 4:00] [24th 4:00]
- stops: [4th 5:00] [14th 5:00] [24th 5:00]
And wrongly apply the current filtering over:
[14th 4:00-4th 5:00] [24th 4:00-14th 5:00]
So the issue hides recurrences of event wrongly if:
- they have not been detached
- they don't have a duration of 0
- one or several previous events have been detached
- the stop date of the nth previous event occurrence (nth equaling
number of detached previous events) is not in the current filtering.
With this change, the stops are also filtered based on start of
occurrence + duration.
Without the change, the added test fails with:
False != '155-20120301120100' : Last event should be found searching it by date range
note: for 10.0 up to not including 11.0 which is solved with #26901
opw-1866151
closes#26887
In a multicompany environment, if the user is not logged-in in the same company as the statement's company (even though he might have access to it), the reconcile interface was filtering on the user's company instead of the bank statement lines's company.
Was PR #26782
Since march 2015, using in a domain "relativedelta(months=X)" with
X being bigger than 11 or lower than -11 would result in an error.
This is because in the refactoring adding modules (e8a00bc50d) the two
functions divmod and utils.divmod with different implementation in
pyeval.js were replaced by one function divmod in web.utils module.
But there was still an usage of the removed implementation.
opw-1880766
closes#26816
When two transactions conflicts (eg. deleting same data, see [1]) Odoo
will retry the whole transaction several times hoping for the best.
But when rendering template, the error handling would prevent this
feature. For example a recurring issue was:
- loading quickly two times the /web route
- for each recompute the assets
=> this could lead to 2 concurrents transactions that would delete
previous same attachment (ie. DELETE FROM ir_attachment where id=3).
With this changeset, when getting a template fails because of a
transaction rollback, we let the issue bubble up so our retry system is
used.
So instead of a "500 Internal Server Error" page and in log:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
"GET /web HTTP/1.1" 500 -
... big traceback ...
load could not load template
we would get the requested page without error and:
bad query: b'DELETE FROM ir_attachment WHERE id IN (3)'
ERROR: could not serialize access due to concurrent update
"GET /web HTTP/1.1" 200 -
SERIALIZATION_FAILURE, retry 1/5 in 0.8920 sec..
"GET /web HTTP/1.1" 200 -
As a side node, the issue was exacerbated in some instances:
- when running a database on another server: assets are recomputed
- when a module was installed/uninstalled: assets may are recomputed
- when updating the source code: assets may be recomputed
- when starting server: requests could be stacked waiting for readiness
- when using google chrome: the "Use a prediction service to load pages
more quickly" option may load a page two times. for example:
-> an URL is entered in address bar
-> a prediction request to it is started URL
-> go to this page (Enter) when that request is not already resolved
-> the prediction request is cancelled and a new request is started
[1] https://www.postgresql.org/docs/9.6/static/transaction-iso.html#XACT-REPEATABLE-READ
note: 10.0 backport of 11.0 #26778
opw-1849167
closes#26785
In Employees views, selecting New Hired filters leads to an access error
with a simple user.
With this commit, this filter is limited to the corresponding users
group.
Backport of 804b9b7c5e
If we do:
- one change that will be saved in history
- go back to the document before any change
- do other change
we can easily get in a state were the history is no longer recorded.
The history is kept like this:
- pos: our position in the history
- aUndo: the snapshots of history
- toSnap: the last history snapshop that is to be saved
so for example if we start without change (at originalState):
{pos: 0, aUndo=[], toSnap=null}
Then we do two changes (change1, change2):
{pos: 2, aUndo=[originalState, change1], toSnap=change2}
If we make an undo, we will get to:
{pos: 1, aUndo=[originalState,change1,change2], toSnap=null)
If we make another change (change3):
{pos: 2, aUndo=[originalState, change1], toSnap=change3}
So the history after the position is removed.
But when we get back to the original, the state would forever be:
{pos: 0, aUndo=[originalState], toSnap=change85}
because when doing a change, the code only removed history from the
max(pos, 1) index.
opw-1870119
closes#26701
In the editor in a table cell, when we press UP/DOWN keys:
- we have default editor/browser behavior if there is content before
(UP) or after (DOWN) the element we are currently on
- else we go to the previous (UP) or next (DOWN) row if available
- else we go to the next content if available
- else we have the default editor/browser behavior
But when checking if there is an element before/after the content, we
did not take into account if there was an ancestor node inside the cell
that had content after, so for example with this structure:
```
<table>
<tr><td>
<p>hello <b>world</b></p>
<p>cruel</p>
</td></tr>
<tr><td>
<p>bingo</p>
</td></tr>
</table>
```
if the current range was on 'world' text node, we would just check if
there is content after this text node, not if there is content after its
`<p/>` ancestor.
Before the fix we would get on the next row, after we would have default
editor/browser behavior: ie. if cruel is on another line, going to this
line.
opw-1870119
closes#26701
The override of fields_get adds "virtual" fields corresponding to
groups.
If for example we make "res.users" have inherit "mail.thread", we get
these "virtual" field as if they had "track_visibility", since we do a
"fields_get" with fields having track_visibility expecting to only get
back "track_visibility" ones.
So the system would then fail trying to track visibility on fields like
"in_group_5" and for example a res.users could not be created anymore.
With this fix, we fix the fields_get so it respect the fields we ask of
it.
fixes#22332
opw-1878654
closes#22338closes#26705
Co-authored-by: Wolfgang Pichler <wpichler@callino.at>
Some users are confused by the generic error message asking to confirm a sale
order that is in locked or cancelled state.
We add specific error messages in these two cases.
opw 1871019
compute method called 2 times in t-esc case when monetary field has "from_currency ::
1) value_to_html: compute method call when qweb monetary widget is return value as a html.
see https://github.com/odoo/odoo/blob/10.0/odoo/addons/base/ir/ir_qweb/fields.py#L325
2) compute_currency : compute_currency method is pass from controller into render engine and it is call the compute method.
So, we removed compute_currency method from qweb template in the t-esc with monetary widget.
FIXUP da2140b
The above commmit was half-right in the business logic, but overlooked that if a user is not
in the company of the project, it will crash.
This use case worked before that commit
While agreeing that a little more clear access right is needed
like for example be able to get the project_time_mode_id on the companies
that are in user.company_ids,
the aim of this present commit is to avoid regression
OPW 1878204
closes#26539
Steps to reproduce:
Create a customer invoice with 2 product A and refund 1 product A.
Display account.invoice.report for this custumer.
Bug:
The quantity should be 1 not 3.
Fine tuning of this commit: e890682656
opw:1868116
When creating a new wizard, the related field user_id = employee_id.user_id
forces a write on employee model
Make sure we actually have the same value (to avoid using the wizard to modify
employees) and use sudo to grant the badge.
In master, the field should not be stored
backport 1dbc655676
Company in USD
Invoice in EUR with rate A
Register a payment in EUR with rate B
Unreconcile them.
Before this commit, there was an error because we tried to reconcile the exchange items
with its reversal while the formers were already reconciled with the invoice
After this commit, there is no error
OPW 1864091
closes#26583
In the reconciliation widget, search for an amount like 5361.61
Before this commit, if the targetted line that you want to see was represented as 5361.61000001
you did not see it in the results of the search
After this commit, you do!
OPW 1872543
closes#26523
- In some cases (merge of partners, etc ...) there might be mail.channel
that have two mail.channel.partner with the same res.partner.
When you try to open a discuss window with a partner for which you
have no existing mail.channel.
The channel opened is the one where your partner is duplicated.
This is due to the fact that the SQL request to find the mail.channel
doesn't take in account that a mail.channel may have twice the same
partner.
To fix this issue, we try to exactly match the partners we search.
Because of 2917b38f28 which appeared in v9.0 but has not been adapted to the new API
afterwards, the early return was out of sync with what a search returns in new API
in v9.0: search returns a list, so must our early return
in v10.0: search returns a recordset, hence the fix
OPW 1878192
closes#26474
On a new DB with demo data, as Demo User:
- Create a partner
- Unlink the partner
An `AccessError` is raised.
The error is raised on `ir.property`, for the field
`property_product_pricelist`. An entry was indeed automatically created
at partner creation. However, a regular user is not allowed to delete an
`ir.property`.
The property can be safely deleted as SUPERUSER as long as the proper
unlink access rights have been tested beforehand.
opw-1870737
When creating and editing a new calendar.event record from the calendar
view, the start_datetime field does not prefill from the day that was
selected on the calendar.
Introduced in e08f999468
opw-1875276
Christophe Simonis