Currently, auto_install is triggered when all dependencies get
installed, but there are cases where one would want such trigger on
only a subset thereof.
e.g. we want `website_sale_dashboard` to auto-install when
`website_sale` is installed. Currently, it requires `web_dashboard` to
also be auto-installed otherwise `website_sale_dashboard` would "wait"
for both dependencies to be explicitly installed before the
auto-install triggers. That's despite `web_dashboard` not being very
useful on its own. More generally this is an issue with technical
modules which need to be marked as auto_install so as not to block
e.g. bridge modules from automatically installing.
This change allows setting `auto_install` to a subset of `depends`:
* if auto_install is set to `False`, the module does not get
automatically installed (no change in semantics)
* if auto_install is set to `True`, the module gets automatically
installed if and only if all its dependencies are installed (also no
change in semantics)
* if auto_install is set to a list of dependencies, the module will be
installed when all *these* dependencies are installed, other
dependencies (excluded from auto_install) will be installed
alongside as a consequence
* auto_install can be set to an empty list, in this case the module
will always be automatically installed regardless of its
dependencies (and will force their installation).
So after this change, `web_dashboard`'s auto_install can be set to
`False` (such that it's not installed if no module defining dashboards
is installed) and `website_sale_dashboard`'s manifest can be edited
to:
'auto_install': ['website_sale']
possibilities:
# no automatic installation
'depends': ['a', 'b'],
'auto_install': False
# automatic installation if both a and b are installed
'depends': ['a', 'b'],
'auto_install': True
# automatic installation if both a and b are installed (explicit)
'depends': ['a', 'b'],
'auto_install': ['a', 'b']
# automatic installation if b is installed, a will get forcefully
# installed if it isn't yet
'depends': ['a', 'b'],
'auto_install': ['b']
# always automatically installed, will cause the installation of
# its dependencies even if they're not marked explicitly
'depends': ['a', 'b'],
'auto_install': []
Task 1851328
closesodoo/odoo#29431
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Users may not do all actions bound to a model. We add the `groups_id` field
on `ir.actions.server` so that `get_bindings` can filter out unauthorized ones.
task id- 1945291
-customers were misunderstanding the concept of "no gap" sequence
implementation hence updated the tooltip of the same to make it more useful and
clearer.
Task-1973967
closesodoo/odoo#33017
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, there was no space between:
- Install button and Upgrade button.
- Uninstall button and Upgrade button.
After this commit, margin will be added to all the buttons for proper layout.
Task ID: #1937131closesodoo/odoo#30829
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Just like other views (form, list, kanban, etc.) CRUD operations (create,
delete and edit) are now set as attributes on the activity node based on
the user access rights.
Task 1894990
The activity view has been greatly improved to allow to customize it
more easily. It works quite similarly to the kanban view, defining
`<field>` tags at the top and using these fields in the `<template>`
section. The template name used to define the activity cards is
`activity-box`.
Note that these activity cards are rendered using `KanbanRecord` widget
(this has implied that ActivityView inherits from `BasicView`).
Also note that the view validation has been moved in base to include the
common grammar.
Task 1894990
Type is the label of the field state ('Custom Field' or 'Base Field') while
ttype is 'Field Type'
closesodoo/odoo#33124
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- Install hr and base_address_city
- Edit an employee
- In private info, set a private address
- Open private address form from the employee form
Traceback because parent_id is undefined.
The base_address_city module override a part of res.partner
view form to change the city readonly modifier.
This override adds a domain in which appears parent_id,
but the field is not present in the view.
Related commit 526bfca3afclosesodoo/odoo#32172
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit is a few small improvement/fixes to the web framework:
- allow placeholder attribute on input tags in form view
- only bind click event handler to buttons managed by the framework, not
custom ones
- _onExecuteAction method in action manager properly fails if event
cannot be properly handled
closesodoo/odoo#32458
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Since the images are not guaranteed to be square anymore, the kanban image had
to be adapted to better handle the different image ratios.
Also the placeholder has been moved into the actual image div instead of
being a separate div that acted differently.
The avatar placeholder was white... displayed on top of white. Now it's grey
so we can actually see it.
task-1958000
PR: #31811
* = hr, im_livechat, mail, payment, purchase, web, web_editor, web_unsplash,
website_profile, website_slides
Since the merge of all image tools into one function, the intermediary functions
are not needed anymore.
task-1958000
PR: #31811
Make the image tools more consistent and easier to maintain by having a single
function handling all the cases, instead of several functions doing more or less
the same thing with obscure differences.
Also introduce a new function to guess the size based on a field name, to be
used in the following commit.
task-1958000
PR: #31811
Following commit: 6801baa662
Crop is always used when we know the target size. Therefore there is no point
to pass a ratio argument. However size is required now.
Also "center" is always used, so make it the default type.
task-1958000
PR: #31811
* = website_partner, website_profile, website_sale, website_slides
Before
======
Since commit: 2e3848b394
The images that are resized have additional borders if the target ratio is
different than the image ratio. Those borders are transparent if the image
format supports it, and are white otherwise.
With that current solution, if the background where the image is displayed is
another color than white, it is looking really bad.
Moreover, most images are stored resized like this, so it is not even possible
to decide if it should have borders or not depending on the context, the
original image and ratio is forever lost.
It is also inconsistent because if the image is already smaller than the target
size then it doesn't include borders. In that case it keeps the original ratio
instead of the target ratio. So it isn't even guaranteed that the target
ratio is going to be respected.
After
=====
This commit will solve all of those problems by always keeping the ratio of the
original image.
This implies the views should be taking care of adding borders when necessary.
task-1958000
PR: #31811
The image tools were accepting an encoding parameter but it was never used.
Indeed the given images are always encoded in base64.
`image_colorize` was the only method not taking base64 directly, so it has been
modified for consistency. This allows to change the code in partner to not
base64 decode the image in some case just to be base64 encode it again after.
`crop_image` and `limited_image_resize` have been slightly refactored to account
for this change, but in this commit their behavior was kept.
task-1958000
PR: #31811
When using the 'tag' quicksearch on the contacts, it should search on the
parent tags as well. It is what users expect from this kind of search.
Using child_of is considered valid here as people should not have a huge
list of nested categories / tags. Even a famous production db like Odoo
does not have more than 215 of them.
Related Task ID: 1903699
closes#30733
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This widget was exactly the same as a `one2many` and was kept for backward
compatibility reasons. It can be safely removed in master.
Related to task 1918327
Before this commit, the field assignment would cache the value it received, even
if that value was altered during `write`. This can happen if `write` is
overridden (for example to resize images), or it could also happen if a database
procedure is altering the value.
To fix this issue, we do not cache the value that was assigned. This implies
that additional queries may be necessary to retrieve the value, but those were
already necessary most of the time, so it does not have a significant impact on
performances.
Purpose of this task is,
Before this task, the customer was able to click on on the email of a contact from the res.partner view.
But, he wasn't able to click on this same email when the modal of a contact was open.
For the phone it's the opposite. You can't click on the phone from the res.partner view but well from the contact's modal.
So, I made both the fields clickable in both (res.partner view and contact's modal)
Task ID: 1965730
Closes: #32586
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When making a manual payment with account_sepa we want to allow people to add a bank account as it might display the European QR code for banking app, but this should stay optional.
So we made sure that the conditions making the field visible and required weren't the same.
part of task #1918423closesodoo/odoo#32198
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
simplification of payments objects and refactoring of the code
* registering payment(s) from the list of invoice now generate a single payment per invoice selected
* no more abstract object for payments/payment wizard as the logic is now really simple:
- group_invoices option is now removed and we never try to group payments based on the currency/customer of whatsoever (see above),
- the payment amount is the full residual amount of invoice and users cannot change it anymore
* partner_bank_account_id not required as soon as visible (depends on the payment method)
* refactoring to name tags and allow easier inheritance via xpath
part of task #1918423
Checking access rules only makes sence if we have some records,
_filter_access_rules will always return a subset or current
recordset, and a subset or a empty recordset is an empty recordset.
closesodoo/odoo#32313
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Should correctly handle / fallback to regular code when processing
non-stored partners.
Perf difference according to cprofile on my machine:
original python:
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.134 0.134 205.380 205.380 res_partner.py:277(_compute_commercial_partner)
SQLized
1 0.118 0.118 67.239 67.239 res_partner.py:280(_compute_commercial_partner)
most of the time leftover seems to be in modified_draft
mreficent