When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
opw-1928512
closes#30239
Task #1910927
Purpose
=======
When confirming a sale order with event tickets, a modal is supposed to be shown to be able to
confirm the event registration.
That modal was not shown anymore.
To solve it, we split the '_action_confirm' to run the actual business of the event_sale module,
which is '_update_registrations', and moved the action returned in the regular 'action_confirm' method.
closesodoo/odoo#29997
- Fix the position of 'Add to menu' toggle button in new page dialog
- Properly align tip icon in the welcome message
task-1895287
closesodoo/odoo#29403
- The method `_get_available_payment_input` that returns the available
payments acquirers and the payments tokens for a specific user never
returns the payments tokens linked to a non s2s payment acquirers.
This is wrong, the payments tokens should always appears no matter
what are the acquirers' payment flow.
The payment flow is used only to specify where the customer should
input his credit cards details, either on Odoo or on the payment
acquirer's website (or popup).
Once a token is created, it is safe to process it since no credits cards
details are stored on the Odoo database.
closesodoo/odoo#30258
Display a BoM.
On BoM lines, there is an attachment feature that creates a mrp.document,
which is basically a container for an attachment.
This commit fixes the view which displayed 'no attachment' when there were some
and vice versa.
It also fixes the computation of the number of attachment: the displayed view is
on mrp.document, but the computation is done on ir.attachment.
As a result if there are other unrelated attachments (such as digital files)
they would be counted but not displayed.
opw 1923441
closesodoo/odoo#30208
The update does not work anymore on the IoT Box,
probably because the structure of the branch is
a bit different now. It starts to download everything
instead.
We did not use 'git archive' because this does not work
on GitHub and downloading a zip would always have everything
inside. This way, we keep the original method, even with
diverged branches.
- If a customer pays an invoice using a credit card, the payment is
taken in account but the invoice validation isn't processed until the
Payment Processing cron do it.
We want the invoice to be validated as soon as possible.
To do so, we need to redirect the customer on the payment processing
page that take cares of validating the payments.
OPW-1913876
closesodoo/odoo#30217
When importing an invoice without specifying the type, the invoice type
is set to `out_invoice`, but the account set is the supplier account.
At this point, the invoice type is simply undefined (`False`). It will
be set by default at creation to `out_invoice`. Therefore, we reach the
`else` condition which uses the supplier info.
We simply inverse the condition, so it creates a consistent object.
However, it raises a bigger question about how the action context should
be kept at invoice. We won't address it :-)
opw-1925547
closesodoo/odoo#30154
On a manufacturing order, there is no way to print a pdf report that
gather all finished products. This new report show product, quantity as
well as the lot barcode and name.
Task : 1923216
closesodoo/odoo#30011
When arriving on the page to unsubscribe from mailing lists,
it was unclear whether the checkboxes were to mean "unsubscribe to this list"
or "subscribed to this list"
With a little string helper, it is clearer
OPW 1922308
closesodoo/odoo#30227
Before this commit, when livechat operators had chats in the
Discuss app and reload their page, they could loose some
pinned livechats.
This problem only occurred on livechat conversations when both
users are authenticated. Any two-user channels should always
be pinned by default, which is the case for internal chats.
This logic was applied on channels with type `chat`, but this
is ignored with livechats because they are channels of type
`livechat`.
This commit fixes the issue by defining internal chats and
livechats as `chat`. Any chat conversations are automatically
pinned when a message is posted, including livechats.
Note that before this commit, the livechats were visually
pinned in the Discuss app, although the server did not consider
them as pinned. The client-side code always assume conversations
are pinned, which is why a page refresh looks like a loose of
previously pinned conversations.
opw-1919327
closesodoo/odoo#30200
For historical reasons, the tour manager executed each step of tour
in a setTimeout (10ms). When a step could be executed (i.e. when
its trigger selector has a match in the DOM), the element matching
its trigger was saved as a jQuery element (the $anchor), and in the
setTimeout, the action (e.g. click) was performed on that element.
However, it could happen that, after the delay, the $anchor was no
longer in the DOM, either because
1) the tip selector had no match anymore, meaning that the element
had been removed from the DOM meanwhile
2) the tip selector still had a match in the DOM, but that element
had been rerendered meanwhile
Case 2) occured sometimes when the main_flow_tour was executed in
community, when trying to open a Manufacturing Order after having
reloaded the Manufacturing Order list view (because the row of the
order to open that was saved as $anchor was the one of the list
before the reload, and that list was re-rendered during the delay).
This rev. removes the default delay of 10ms, but the feature is
kept such that one can still manually run a tour slowly (e.g. to
debug or to make a demo). It also adapts some tours that didn't pass
anymore without the delay, and it fixes a bug in the kanban view that
has been spotted thanks to the delay removal.
closesodoo/odoo#30106
After the delay removal, those two tours failed for the same
reason. They made a research on the /shop page with a specific
product name, and then opened that product.
With the delay, the page was reloaded with the new search, and we
clicked on the product after the reload.
Without the delay, we directly click on the product (which is in
both case already displayed even before searching), and then the
page is reloaded, so the product is never opened and the tours
fail.
This rev. adapts those tours to either wait for the page to be
reloaded before clicking on the product, or simply remove the
searching step when the requested product is actually the first
one.
Before this rev., there was a race condition when the user did
some changes on a form view (triggering an onchange), saved and
clicked on the breadcrumbs to leave the form view (before the
onchange returned). As a consequence, the dialog telling the user
that there are pending changes was displayed. This mostly occured
on the main_flow_tour since the removal of an unnecessary check,
and could be reproduced manually on a slow network.
Basically, the check if there were pending changes was done too
early (before the view was actually saved).
This rev. fixes a concurrency issue in the kanban view spotted by
the Project tour and the removal of the delay in the tour system.
Let's assume the following scenario in a kanban view grouped by a
many2one field with at least one column and with the quick create
feature enabled:
- quick create a new column
- before the column is actually created, click on CREATE in the
control panel to create a new record
Before this rev., the record quick create widget was opened
directly, but as soon as the column was created, the view was
re-rendered, and the quick create widget was lost.
This rev. forces the column to be created (and the view to be
re-rendered) before opening the record quick create.
This rev. concerns automatic executions of tours. It makes each
step executed in a setTimeout, thus ensuring that the call stack
has been emptied before executing the next step (which is the case
when the user manually executes the flow).
For historical reasons, the tour manager executed each step of tour
in a setTimeout (10ms). When a step could be executed (i.e. when
its trigger selector has a match in the DOM), the element matching
its trigger was saved as a jQuery element (the $anchor), and in the
setTimeout, the action (e.g. click) was performed on that element.
However, it could happen that, after the delay, the $anchor was no
longer in the DOM, either because
1) the tip selector had no match anymore, meaning that the element
had been removed from the DOM meanwhile
2) the tip selector still had a match in the DOM, but that element
had been rerendered meanwhile
Case 2) occured sometimes when the main_flow_tour was executed in
community, when trying to open a Manufacturing Order after having
reloaded the Manufacturing Order list view (because the row of the
order to open that was saved as $anchor was the one of the list
before the reload, and that list was re-rendered during the delay).
This rev. removes the default delay of 10ms, but the feature is
kept such that one can still manually run a tour slowly (e.g. to
debug or to make a demo).
The aged reports were wrongly taking the previous day of the requested date to compute the different report periods.
E.g: An aged balance requested for the 31-12-2018 was excluding entries made on the that exact date and was starting from the 30-12-2018
closesodoo/odoo#30195
When selection an invoice in the view list and send it from the
"action > send" button, the checkbox for the print option is
not checked according to the configuration.
This fix remove the context that was forcing the print checkbox on
false.
opw-1927126
closesodoo/odoo#30175
Since commit 52a85e57b9, it is possible to configure the
weight unit. Therefore, we should not hardcode `kg` anymore.
opw-1919821
closesodoo/odoo#30147
- Go to Leaves > Managers > All > Allocations
- Create an allocation for:
Leave Type: Legal Leaves
Mode: By Department
- Validate
When going to the Legal Leaves form view, the days allocated are not
shown.
This is because the domain is too restrictive. The allocation has a
`date_from` which is `False`, since it is only set for Accrual leaves.
We adapt the domain accordingly.
opw-1921338
closesodoo/odoo#30152
crm lead is created with a default company_id which is the current company of the user
When creating a lead from email, this logic doesn't hold, especially in v12.0
where the __system__ user is not someone real
In that case, we retrieve the company from the sales team
OPW 1918837
closesodoo/odoo#30146
Before this commit, the web client had a naive strategy to handle lost
connections: it tried to poll the server every 2 seconds until a rpc
succeeds.
This works quite well from the perspective of the user, but may be a problem
from the perspective of the server. If a server is down for a longish period,
then each users active tabs will then perform a request every 2 seconds. This
means that the server will be progressively hammered by many requests, which
will clutter the logs, and make it more difficult to gracefully recover.
With this commit, we simply exponentially increase the delay each time, and add
a little jitter to give a better distribution.
closesodoo/odoo#30136
The field ignored is set in javascript on company object to filter the
ones we want to show. As it is not an odoo field, it triggers a
traceback when the trigger_up 'field_changed' is called.
OPW-1921568
closesodoo/odoo#30153
Purpose
=======
Since 9c5f930, the double holiday is computed from the wage with holidays.
When we compute the employer costs, we should take the original wage,
not the adapted one, to keep fix employer costs, whatever the amount
of days the employee takes.
closesodoo/odoo#30149
opw-1918789
Before this commit, the addresses (invoicing and shipping) in the SO wasn't displayed in the
same way in the portal and in the report.
Now, the addresses are displayed in the same way in both the portal and the report.
closesodoo/odoo#30093
Following 4a3fd02af4 on the portal when displaying an invoice we may get
a report_type variable (with value 'html' or 'pdf') on the portal.
This was used to not display the page number when checking the report,
but when the report is printed in the backend this report_type was unset
so the page number was mistakenly removed too.
With this changeset, the report alway know if he is pdf, html or text
and only print the page number if it is of type pdf.
opw-1924729
closes#30095
Since panel collapse became card collapse while migrating from BS3 to BS4 with
commit 59237ea819, it is impossible to open the card content.
Indeed, there was already data-parent attribut pointing to inexisting DOM
element. This was not an issue in BS3 but BS4 is not working with it.
closesodoo/odoo#30142
Jeremy Kersten