The field is now `quantity`. This wasn't spotted before because the
method is not used anywhere.
opw-2008491
closesodoo/odoo#34067
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
If the option 'Reload from attachment' is checked for a report, it will be generated from the existing attachments.
However, for snailmail, we have to force the re-rendering to apply specific css rules to match the layout of a A4 letter.
Task-ID: 2008896
closesodoo/odoo#34053
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
To reproduce:
- Go on the website page of a product with optional products.
- Disable the Select Quantity customize show.
- Click add to cart.
This will open the optional product modal, where the quantity will be displayed.
However changing that quantity will have no effect, especially the price will
not update accordingly.
The real issue is that the quantity should not be displayed there if Select
Quantity is disabled, but this has never worked before, so this is outside the
scope of this fix.
Anyway, since the quantity is present there, we would at least expect it to
correctly recompute the price, which worked fine when the modal was introduced,
but has been broken since 51e51055bf
opw-2005317
closesodoo/odoo#33992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set an analytic account on an employee contract
- Set credit and debit accounts on the salary rules
- Create a payslip, confirm
The journal items created do not use the analytic account set on the
contract.
If no analytic account is set on the salary rule, we fall back on the
contract account.
opw-2006090
closesodoo/odoo#34095
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Installing test_new_api without demo will fail since demo_user
does not exists. This is a problem if we want to test migration
with all modules installed. This simple fix solve the problem.
closesodoo/odoo#34065
Signed-off-by: Christophe Simonis <chs@odoo.com>
Have a multi-company setup, with shared products.
Write the default code of a product; an access error is raised on inventory.line
On inventory.line, the field product_code is defined as related to
'product_id.default_code', and stored.
So when writing on the default_code of a product, we get the inventory lines of
other companies. For obvious reasons their access is protected by the record
rule "Inventory Line multi-company", therefore the access error is raised.
To avoid that situation stored related fields should be in compute_sudo.
Note that similarly this is necessary for product_name.
There is one more subtlety: directly writing on the product.product does trigger
the access error, but writing it on the product.template does not.
opw 2007167
closesodoo/odoo#34019
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, it was impossible to eval the domain if context_today was
used in domain.
closesodoo/odoo#34031
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When the channel has a linked forum, the "Review" link on the forum should redirect the user
to the "Review" tab on the course page.
Task #2003222closesodoo/odoo#33786
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit improves the footer image of the slides home page by adding
the top 3 users avatars (ordered by karm desc) in the image.
We only fetch users that have an image set as avatar.
Task #2003222
Co-authored-by: @stefanorigano <sri@odoo.com>
- On the HR module, the field `parent_id` is added on `res.users`.
The issue here, is that `res.users` inherits the fields from
`res.partner` where `parent_id` is already defined.
This causes issues when trying to read the parent `res.partner`.
Issue found by @rrahir
closesodoo/odoo#34059
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
From now, the color option 2 ('Mixed color & B/W') is not available anymore. So set the option to 1 ('Color').
Task-ID: 2008913
closesodoo/odoo#34052
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This tour is useless in backend.
This patch will be required in saas~12.2 as `web_editor.base` (used in
the tour) is only available in frontend.
closesodoo/odoo#34041
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create a mailing campaign
- Create a mailing 1, set the subject to "Test 1"
- Create a mailing 2, set the subject to "Test 2"
The subject of mailing 1 is set to "Test 2".
When checking the code, this behavior seems the one expected. The
`_rec_name` of a mass mailing is the `subject_id`:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L437
Moreover, there is an onchange to set the subject in line with the
subject of the campaign:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L608
However this behavior is not present up to v11, and only appears in v12.
Surprisingly, this is due to an unrelated improvement which adds the
field in the view (in debug mode): 5b0bcaef3e.
Up to v11, the onchange exists, but since the fields are not in the
view, it has no effect. However, in v12 the fields are in the view so
the onchange has an effect.
Since this was the behavior up to v11, and that the behavior is fixed
in f50fbc6d16, we keep it consistent in v12 as
well.
opw-2007764
closesodoo/odoo#34028
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a translation linked to a record unreadable because of a record rule
(e.g. a product that is not shared between companies).
Display the translations list view; if one such translation is in the view,
it will raise an access error.
When computing the source value, _compute_source will fail to read the record,
and raise an access error.
This will make it impossible to access untranslated terms.
Instead we guard this error.
Since it is displayed in the view, we display an informative message.
Note that since we make this error go away, we also fix the check method.
Only the superuser bypasses the record rules; so if we made the check on write
with _is_admin, it means than a user in group_erp_manager cannot read a record
but can edit its translations.
opw 2000817
closesodoo/odoo#33989
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Create a product A of type "Service", Invoice based on "Milestones",
Service Tracking "Create a task in a new project".
- Create a new SO with A, confirm.
- Go the to task associated to the SO, go to "Timesheets" tab, add an
entry
- In the SO, edit the delivered quantity
- Create invoice, validate
Back to the SO, delivered quantity is reset to 0.
We make sure to filter out SO lines which have a delivered quantity set
manually.
Introduced by d6ad22227c.
opw-1982020
closesodoo/odoo#33991
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
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>
Christophe Simonis