We fix a number of problems:
- grayscale filter not being applied except on desktop Firefox
- incorrect vertical-align on iOS
- image sliders being displayed below the margin on iOS
- carousel indicators flickering at initial load
- very short indicator panel, almost unusable on mobile
- misaligned indicators because of first margin
There are two modes on which these fixes apply:
- image gallery in slideshow
- slideshow in modal
(e.g. obtained by clicking on the gallery set on masonry mode)
Note that due to a refactoring, the gallerySlider was not loaded in the modal,
completely breaking the indicators.
Coauthored by @nle-odoo
opw 1874274
closesodoo/odoo#27226
After a refactoring for v11, the id of a newly created thread is not returned
anymore.
Therefore server actions weren't being executed on newly created records.
opw 1886383
closesodoo/odoo#27238
The inline tree view of the purchase order lines has a state field that is used
in attrs.
The popup form does not have the state view.
Even if the state field is not used in the form view, closing the form view
produces an error as the field state is not found.
This patch is a workaround to avoid the error.
The real issue should be fixed in the future but is more complex.
closesodoo/odoo#27208
In the case where the user forces a sale with a negative product quantity on
hand, then the average price update might divide by zero.
We guard against this case.
opw 1886967
closesodoo/odoo#27232
Somehow, having theses 2 new `website.page` records created separately from
their `ir.ui.view` would throw an error in dev-xml when installing website
module.
A task has been created in website team to track the origin of this bug.
In the meantime, this commit will avoid the traceback by creating the view
inside the page record. As the page's view is not intented to be inherited, it
is the best way to write it anyway.
Step to reproduce:
- Start odoo in dev xml
- Install website app
Related to #27199closesodoo/odoo#27210
- Create a project
- Create some tasks with followers
- Create an outgoing mail server with active = False
- Copy that project
When copied, the project tries to send emails to followers using the
inactive mail server. This leads to a traceback.
The addition of the context key dates back to 2009 with 853789d0aa.
The purpose was to copy all tasks, including the archived ones.
We keep this behavior, but without propagating the `active_test` during
the copy of the tasks.
opw-1887354
closesodoo/odoo#27192
Steps to reproduce the bug:
- Create a picking
- Create a line with product "A"
- Validate Picking
- Duplicate Picking
- Add a new line for product "A"
- Validate Picking
Bug:
A missing error was raised.
PS: The function _action_done on model 'stock.move' calls the function _action_confirm
where some stock.move records could be unlinked by function _merge_moves
But the recordset was not updated afetwards.
opw:1885053
closesodoo/odoo#27209
- Set the Outgoing shipping of your warehouse to pick + pack + ship
- Create a SO with a stockable product and validate it
- Set the qty done to 1 in the ship and validate it
- Cancel the pack
Bug:
It was impossible to cancel the pick.
opw:1887098
closesodoo/odoo#27193
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
Steps to reproduce the bug:
-Go to Sales > Dashboard > Point of Sale > Settings
-Set nothing as group_by value
-Go back to Dashboard
Bug:
A traceback was raised.
opw:1881444
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
qsm-odoo