This commit reverts commit 492764c
*Note for forward port*
This commit will conflict with 76ee0af. Keep this version.
TL;DR: the fix had unintended effects and the original problem has been
fixed by b5c2004 in the mean time.
Why the original commit?
------------------------
To know if the current user has the rights to approve/delete a leave,
two boolean fields are computed (respectively `can_approve`
and `can_reset`). Associated buttons are shown in the form view according to
the field values.
In the compute methods, the `check_approval_update(state)` method is called.
This method checks various conditions, including `ir.rules` by calling the ORM
method `self.check_access_rule('write')`. If one condition or one `ir.rule`
is not met, an Error is raised.
If the method raises, the user does not have the rights.
The exception is catched and the field `can_approve|reset` is set to False.
However, an unexpected behaviour happens when fields are re-computed
in the context of an onchange. In an onchange, `self.ids` is an empty list.
When checking ir.rules, the `_filter_access_rules()` method is used
to retrieve valid records in self by checking every record against ir.rules.
If some records are not in the valid set, they are considered invalid and an
exception is raised.
But because self.ids is empty, no record is actually checked and therefore
no record is valid.
=> in an onchange it always raises an AccessError and the users is considered
as not having the rights to approve nor refuse a leave as soon as an
onchange has been triggered. Thus associated buttons does not appear.
The original commit fixed the problem by preventing checking the rules
when in an onchange.
In the mean time, the root cause of the problem has been fixed by b5c2004.
Why revert?
-----------
While commit 492764c allowed HR users and Team leaders to approve
after an onchange, it had the unintended effect to
show the "Approve" and "Refuse" buttons to other users.
In summary:
- With commit 492764c: buttons are shown more than necessary
(which is confusing to users who don't actually the rights
to approve)
- Without: Thanks to b5c2004, the original problem no longer exists.
Users with access rights always see buttons. Users without never see
buttons.
closesodoo/odoo#33894
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33942
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
1) Add a 1st product to compare from the ecommerce /shop page.
2) Open the compare list pop up at the bottom.
3) Add a 2nd product to compare from the /shop page.
4) Remove the 1st product from the compare list before the rpc of the
2nd product is done.
5) Javascript error `self.product_data[res] is undefined`
The function `add_new_products` and `rm_from_comparelist` are
concurrent, they both modify the internal `comparelist_product_ids`
product list. The first one perform an RPC and delay the update once the
request is done, the second does the update immediately.
The solution has been to use a mutex to exclude the two functions.
opw-1974108
closesodoo/odoo#33302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Try to get the report_pricelist with empty data
(Studio Report editor can)
Before this commit, it crashes because we tried to access dict keys directly
in an empty dict
After this commit, it doesn't crash
OPW 2009862
closesodoo/odoo#34118
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Backport of fa39019ee1.
If crop_image is called without a default format, it would try the default,
'PNG', to save the result and crash at save when processing non-PNG images.
For example, if a jpeg image was in CMYK colors.
Here it will still crash non-gracefully when failing to save, but the default
should almost always work; if it doesn't it means we failed to detect the format
of the stream, so it is unlikely that we could save the image anyway.
opw 2009029
closesodoo/odoo#34088
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33945
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
`_patch_method` and `_revert_method` do not work properly.
This commit fixes a test which patches `create` and `unlink`
of `ir.attachment`.
The methods are not correctly unpatched.
One consequence:
if a module is installed after this test is executed and
the new module overrides `create` and `unlink`, the overritten
methods are never called.
closesodoo/odoo#33952
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
If a user has an ooom in his Preferences, it should be
used as the default value for a leave ooom.
closesodoo/odoo#33890
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Purpose
=======
Currently, the ooom field is editable in the leave view but an ir.rule
prevents the employee to save as soon as the leave is approved.
Specification
=============
An employee should be able to edit the out of office message
even if the leave is already approved.
The goal of the to_check checkbox in the reconciliation widget is to set the to_check field present on the move that will be created. However since the UI is not perfect, the to_check checkbox was added on the wizard when we create a new line in the widget, which cause the following problem: what if we select to_check on line1 and then deselect it on line2, previously it was not possible to do this, a warning was thrown to tell the user that he had some line with to_check set and some other not. A better way to do this, and more user friendly is by preventing the user from deselecting the checkbox if some other line has the to_check value set.
closesodoo/odoo#33956
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Before this task, when creating the related field from the studio, it is by
default stored. When we change the field name in 'ir.model.fields' using ORM's
write method, it also renames the column in the table associated with the
field's model.
This is the expected behavior. But when someone tries to change the 'name' of a
non stored field, the column is not available in the associated model, and so
trying to rename the column results into traceback. This issue was probably
there for a while but came into light with the task 1985710. More info can
be found on the chatter of the task.
This commit fixes the issue by adding an extra check before renaming the table
column. The query will be executed only when the field is stored and thus
exists in the table.
closesodoo/odoo#33944
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The function get_all_data_for_manual_reconciliation got an empty list instead of None. This leads to not query the db. However we want to get results in the default behavior for get_all_data_for_manual_reconciliation
closesodoo/odoo#33711
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
The content of these fields can't be updated, there's no reason to
even show them. Just remove them from the default / auto-generated
view for client actions.
Task 1772242
closesodoo/odoo#29179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The field job_id is displayed in the tree view but it was not available in the form view
like in 12.0. So it was not possible to change it.
opw:2006084
closesodoo/odoo#33933
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Purposes:
* Remove bridge module event_sale_product_configurator
* Ease developement of product configurators AND product-based sale_order_line configurators
* Fix the tests for those extensions
* Note that despite the widget being extensible, the tests from the other configurators can easily crash when other configurators are installed because of query counts or limited data available in tests environments.
Technical clarifications:
A main product_configurator widget base in odoo/addons/sale, set on the product_product and product_template on the sale_order_line inline list, providing:
* 5 hooks:
* _onTemplateChange for product_product configurators based on product templates
* _onProductChange for sale_order_line configurators based on product_product
Those two hooks are expected to return a boolean promise to know whether the line has been configured or not, avoiding the opening of multiple wizards.
* _isConfigurableProduct
* _isConfigurableLine
If true, a pencil button is shown next to the product/product_template, calling _onEditProductConfiguration when clicked.
* _onEditProductConfiguration
Called when clicking on edit pencil button.
Examples :
Product configurator : odoo/addons/sale_product_configurator module --> product_configurator (true one, the one in sale doesn't do anything until extended)
Sale Order Line configurator : odoo/addons/event_sale/ --> event_configurator, future rental configurator
Traceback coming from tests are currently logged
line by line. This will implies that runbot will have one
ir_logging entry per line which is not practical. More than
that, the log prefix can make the traceback less readable
because of line returns and difficult to copy paste.
This commit simply remove this feature. After discussion with odo
and chs, we will also remove the docstring from test shortDescription
since most of the time this information is not clear and can be accessed
in source code if needed.
closesodoo/odoo#33911
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
We now force tax repartition lines to use the same percentages for invoices and credit notes. Thanks to that, we are able to simplify the way manual modifications made on vendor bills' account.invoice.tax entries must affect the ones of the refunds created for them. This also prepares the code for the incoming big accounting revamping.
closesodoo/odoo#33577
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.
See opw-2000305
closesodoo/odoo#33908
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If you are logged into a company that differs from the company of your
employee, you won't be able to read the informations on that employee,
and you will have a crash.
Instead of taking the employee linked to the current user, we use search
in order to first apply the ir.rules hence we ensure that we will be
able to read the needed informations.
closesodoo/odoo#33903
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, call a controller defined as:
```
@http.route('/route', type='http', auth='public')
def controller_func(self, foo):
do_it()
```
and called with url like /route?foo=1&bar=2
will crash with an exception:
`TypeError: controller_func() got an unexpected keyword argument 'bar'`
Now, we remove the extra parameters if the controller doesn't support it.
This case is not uncommon, you can easily arrive in this case with utm or
debug as extra parameter.
closesodoo/odoo#33962
Signed-off-by: Christophe Simonis <chs@odoo.com>
In JS tests, when the ready code takes too much time, a warning is
logged. As a consequence, the runbot updates the github status as a
failure, causing real pain to people who simply wants to merge their
features.
With this commit the warning is changed into an info and the runbot will
be happy.
closesodoo/odoo#33931
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
export.selection.withdefault and export.selection both have a selection field
with Foo and Bar as possible selections.
When doing
self.env["base.update.translations"].create({'lang': 'fr_FR'}).act_update()
the base.update.translations wizard exports the translations of ALL modules,
including the ones of the test_impex module.
The generate po entry is something like:
#. modules: test_impex, test_translation_import
#: selection:export.selection,value:0
#: selection:export.selection.withdefault,value:0
#: selection:test.translation.import,import_type:0
msgid "Bar"
msgstr "Bar in french"
but may also be
#. modules: test_translation_import, test_impex
#: selection:export.selection,value:0
#: selection:export.selection.withdefault,value:0
#: selection:test.translation.import,import_type:0
msgid "Bar"
msgstr "Bar in french"
(not sure where the indeterminism comes from)
which creates 3 translation entries that are sometimes linked to the module
test_impex (ignored when exporting the translations of test_translation_import)
but are sometimes linked to the module test_translation_import instead
In the second case, this makes 3 more translations that is was supposed to
exist.
This commit hides the symptom by making sure there is no longer a clash
when exporting the translations of the module test_translation_import.
A real fix to avoid creating unnecessary translations during an execution of
the base.update.translations wizard must also be made in the future.
It is assumed the unnecessary translations problem was already present before
a7621137cb but polib introduced the indeterminism
making the test fails from time to time.
closesodoo/odoo#33958
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since forward-port, `/sale/get_combination_info_website` and `_cart_update`
would lead to a concurrency error.
Indeed, the session would not have an order_id at first. Then both rpc would
be sent at the same time:
- `cart_update` would create an order and add it in the session
- `/sale/get_combination_info_website` would end up calling `_compute_cart_qty`
which would call `sale_get_order` and would set the `sale_order_id` to none,
just aftet the `_compute_cart_qty` would actually add an order in the
session, simultaneously.
closesodoo/odoo#33993
Signed-off-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
In order to setup the tour environment, the tour would create and write on
some records.
This part of code could be moved from JS to python to avoid potential
concurrent error and to gain time.
Comparing the length of the recordset is not enough for determining if
there is changes on m2m.
This also fix the merge of f14ae73a98 and
d0bb596f1d
Oversight of previous forward-port.
Before this commit, the test `list: edit view menu item` would sometimes crash
as now the debug manager loads its templates with an `xmlDependencies` where it
was not the case before (included in base.xml), see 73327db065.
Odoo Translation Bot