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
During uninstallation of a module, recompute operations may be triggered.
The prefetch might thus try to read a column that has already been deleted.
Install CRM, create an opportunity then schedule a meeting
(itself a calendar event linked to the opportunity).
Note that the CRM module adds an opportunity_id field on events.
When you try to uninstall the module, the bug is triggered.
The calendar model contains a res_model field, which is related to res_model_id.
Its recompute triggers the prefetching of the opportunity_id field,
which has already been removed.
opw 1917354
closesodoo/odoo#29979
Before this commit, the process of positioning chat windows
could fail if one of the tabs had discuss open.
When a chat window was hidden and become visible, the algorithm
was not updating the state of the chat window to "visible" when
discuss was open. As a result, it was always trying to make it
visible, resulting in an infinite loop and raising the following
error message:
`Uncaught RangeError: Maximum call stack size exceeded`
This commit ensures it works even when discuss is open.
opw-1919327
closesodoo/odoo#30137
opw-1921686
The failed mail notification group all the records of the same
model that failed to send an email.
Before this commit, the failed mail notification displayed as
title the name of the last record that failed to send an email.
Now, the notification displays as title the model name.
closesodoo/odoo#30134
This commit adds a test to test the scenario fixed in the parent commit.
Creating a new test module is necessary as the bug is only revealed when the
current module is different than the model._original_module (cf c9837ac5dc)
Before that commit, was failing only the second search of
test_ir_model_data_inherits_depends.
Add other test to avoid regression of the bugs corrected at 574f4c3d and c9837acclosesodoo/odoo#30116
On a field created through a _inherits, the fields on the child model did not
benefit from the parent _modules information.
If two models are created in module base
class Partner(models.Model):
_name = 'res.partner'
class User(models.Model):
_inherits = {'res.partner': 'partner_id'}
partner_id = fields.Many2one('res.partner')
and a second module auth_signup adds a field on the parent model
class ResPartner(models.Model):
_inherit = 'res.partner'
signup_token = fields.Char()
Both res.users and res.partner should have an ir.model.data create
base_setup.field_res_partner__signup_token was correctly created but
base_setup.field_res_users__signup_token was not created
The reason is was, in the call to _reflect_model, since 574f4c3deb, the
creation of ir.model.data is based on the field._modules
However, the field res.partner.signup_token did not propagate its _modules value
to the related field res.users.signup_token
With this patch, both ir.model.data are created.
This allow a proper uninstallation of fields as well as translation.
opw-1916965
Before this commit, the price printed in the product label was the
list_price (catalog price) it didn't take into account the extra price
of the variants.
Now, the price printed is the lst_price (catalog value + extra).
closesodoo/odoo#30039
Task #1923443
Purpose
=======
When adding a like/dislike to a slide, the like/dislike counter was not properly updated.
partly closes#29901closesodoo/odoo#30027
Task #1923443
Purpose
=======
Probably due to the migration to bootstrap 4, the active tab panel in the 'slide_detail_view' was not displayed
on page loading (and only when switching back and forth in the tabs).
partly closes#29901
Make an expense report containing 2 expenses
one of them has tax exigible on payment
Validate the whole thing and make a payment
Before this commit, the journal entries were wrong
this was because:
- there were 2 move lines in the payable account
Each of them wanting to reconcile with the payment, and each of them trying
to create an cash basis entry
- the amounts were incorrect too, as the matched percentage was computed
on move lines that were not in a payable/receivable, but in taxes accounts
OPW 1912247
closesodoo/odoo#29878
PAYPAL
------
The paypal tests are not working working for two reasons:
- we check that there is no date in pending state on payment
transaction, but since the refactoring in this commit: https://github.com/odoo/odoo/commit/01216345e28374b554bfe95df82d607c591271cf
the date is always set before the validation of transaction.
- Since the changes on dates, the datetime field doesn't return a string
anymore and the comparison fails. So we convert the datetime to string
for the comparison.
BUCKAROO
--------
The buckaroo tests were not working for multiple reasons.
STRIPE
------
The payment stripe tests were not working because:
- The reference set in transactions were not the same as the ones givent
to the payment provider.
- we were checking for a script tag in form that has been removed in
commit https://github.com/odoo/odoo/commit/7c639be4aadce20bf6662ab347470fadf9afd99f
AUTHORIZE
---------
This test cannot be tested on runbot due to its server to server way of
working
closesodoo/odoo#30105
The field partner id is not a required field in payment transaction, and
we try to read its value in the dictionnary given to the create
function, so if a transaction is created without the partner_id, it will
raise a KeyError.
So to fix it, we only complete the pratner values on the payment
transaction if a partner_id is given.
opw-1922531
Before this commit, the product's description for customers was not translated in the
invoice.
Now, the product's description for customers is translated in the invoice.
closesodoo/odoo#30107
In the 'banner' snippet, there is a column using a white jumbotron
component. Those comes with a default background color so when using the
website builder to remove the white background, it did not go away;
it was replaced with the default background color (some gray).
This commit sets the default background color of jumbotron components to
'transparent'.
task-1889341
closesodoo/odoo#30099
utils.round_precision() is expecting a float as precision (0.01) whereas utils.round_decimals() is expecting the number of digits to consider after the coma (2).
The previous code was totally wrong in that regard, which led to reconciliation wrongly considered as total in foreign currency, as long as the amount_currency difference was lower than the currency precision digits.
closesodoo/odoo#30091
* website_theme_install
This commit will add MODULE_UNINSTALL_FLAG to the cleanup methods of themes and
modules.
This is necessary to also unlink inherited views of those we try to unlink.
Before this commit, an error would be raised when trying to delete a view that
still had other inherited views (either created manually by the user, or with
just bad luck in the order of which the views are deleted).
PR: #29753
If a module has a view that has been copied (copy on write, web editor,
customize show, manual copy, ...), currently the copied view will not be deleted
if the module of the original view is removed.
If the copy is not used anymore, it is not a problem (but still polluting the
database), but if the copy is still used (ex. it is an inherit of a view still
in use), then it will crash if that copy references other data (views, fields,
...) that were in the module that is now removed.
Eg.
The view `website_sale_comparison.product_add_to_compare` is inheriting
`website_sale.product` and calls `website_sale_comparison.add_to_compare`.
If the view `website_sale_comparison.product_add_to_compare` is copied (when
using the web editor on the product page -> copy on write is making a copy of
the `product` view and all its tree), then the product page on website will
crash when the module `website_sale_comparison` is removed because
`product_add_to_compare` will call the deleted view `add_to_compare`.
The solution is to also remove copied views when removing a module. Instead of
just using the xml id, we should look for the `key` starting with the module
name currently removed, because copied views don't have an external id.
task-1920005
PR: #29753
`ref` could raise even if raise_if_not_found was False on `viewref`, now we
prevent that, and rely only on the exception on `viewref`.
Also, when not set to raise, the method could return None instead of a recorset.
PR: #29753
In 12.0 commit f2302dfb2 the method openDmWindow was renamed
openDMChatWindowFromBlankThreadWindow but it called openDmWindow at one
location which caused click on user connection notification to cause an
error instead of opening a chat window.
opw-1910521
closes#30084
Robot Odoo