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>
The first column should have a minimum width to avoid the table to
resize when changing the domain for example.
Task 1894990
closesodoo/odoo#33273
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
added group to hide a server action of 'Mrp: plan production orders' when 'work orders feature of settings is inactive'
before this commit:
when 'WO feature(group_mrp_routings)' is inactive it still displays 'Mrp: Plan production Orders' server action.
after this commit:
'Mrp: plan production orders' server action will display only when 'WO feature(group_mrp_routings)' is active.
task id - 1945291
closesodoo/odoo#33117
Signed-off-by: Simon Lejeune (sle) <sle@openerp.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
-replaced domain with context in workorder view. user cannot work on
done or canceled workorder.
-added a default, removable filter to show orders of current workcenter
from dashboard.
This commit is related to task id: 1911218
Co-Authored-By: Hetal Dhanak <hdh-odoo@users.noreply.github.com>
closesodoo/odoo#29492
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Somehow, when a sales order is confirmed, its confirmation date might not be set (or it is
possible to remove it). This makes no sense as we expect it to be set when the SO is confirmed.
This commit adds an SQL constraint to ensure the confirmation date is required when the SO is
confirmed or done.
To populate this column, the confirmation can be deduced from the mail.message, with the confirmed
subtype.
Task-1930506
closesodoo/odoo#33230
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
If timesheets are recorded on tasks that aren't linked to any Sales
Order, the user can assign a SOL (in batch) later on by going to the
Action > Assign Sale Order Item. Since the introduction of FSM, the
user can directly create Sales Orders from the Project Overview and
from Tasks. This makes the "Assign Sale Order Item" action redundant.
This commit removes this action.
Task-1968074
closesodoo/odoo#32696
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
-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>
Comparing float is a sensitive matter. Odoo creates specific tools
to manipulate float values. This commit makes the reinvoicing flow use
those tools to avoid rounding mistakes, ....
Task-1962608
closesodoo/odoo#33229
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
Rev. odoo/odoo@5dc971b introduced a `description` attribute on AbstractField.
Sadly, the attribute was already used for something else (in `handle`
and a widget in asset, to hide the column name). So the widget new
description is now displayed in the list header (instead of the field
name).
A new attribute `noLabel` has been now added on AbstractField (currently
only used in list) to fill the same purpose as the previous `description`.
Task 1981757closesodoo/odoo#33060
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A traceback occured when displaying the tooltip (only visible in debug) on a list
view header if the field had a `widget` attribute (introduced in rev. odoo/odoo@5dc971b).
The issue here was linked to the fact that a widget is not always rendered in list view
(compared to form view) so the `Widget` property in the attributes was not there.
Task 1981757
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>
Before this commit, it was allowed to add empty lines while adding a member in channel.
After this commit, it'll not be allowed to add empty lines as partner_id is required.
Task-1973972
closes#32958
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
As it's easy to forgot user's password and if user do,
user currently have no way to reset it if user didn't activate
the settings to enable the Reset Password.
so enable this options by default to avoid people getting blocked
because they forgot their password.
task-1925281
closesodoo/odoo#30391
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
This commit extracts the logic of the selection of the default
value for search panel categories into a private function
so it can be hooked in other modules.
task: #1959112closesodoo/odoo#32448
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
This prevent the uninstallation of all payment provider through the
NOT NULL constraint. There is no reason for this field to be explicitely
required - it will fail if the template is wrong anyway.
closesodoo/odoo#33170
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Rev. a3489be33 removed this feature to fix a bug (when the single
line many2one, e.g. a product, is too long and displayed over
several lines). However, we (fp) still want this for res_partner
many2ones with show_adress.
This rev. re-introduced the feature without re-introducing the bug.
closesodoo/odoo#33139
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This commit introduces the Alipay payment provider, a popular acquirer
in the Chinese market.
There are 2 possible ways to use this acquirer:
- express checkout mode (only available for merchants located in CN)
- standard checkout mode (availabe for foreign merchants)
Note that this provider does not support server-to-server payments,
tokenization or any other bells and whistles besides fees. There are no
specific behaviours related to this acquirer, it behaves like most 'form
based' payment acquirers with a form submission, s2s notification from
the provider as well as redirect in case the s2s did not reach the
server in time.
closesodoo/odoo#21855
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
purpose of this commit is to schedule an activity exception on delivery picking
when user change address of the SO, to notify user that
sales order address is changed.
Task-1888829
closesodoo/odoo#28191
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Tag name should be "Need Assistance" instead of "NeedAssistance".
Task-1891795
closesodoo/odoo#32146
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
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`.
Other features have also been added (see each commit for more information).
closesodoo/odoo#29271
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
The activity view has been added on multiple models (invoice, fleet
contract, vehicles, leads, employee, contract, expense, expense sheet,
leave, leave allocation, applicant, partner, product, task, purchase
order, sale order) to ease the creation and the management of
related actvities.
Task 1894990
The activity view has been refactored and improved so the qunit test
suite needed to be adapted.
More tests have also been added to test new features (progressbar,
schedule an activity, etc.) and the method 'get_activity' has been
correctly mocked (the result was previously hardcoded).
Task 1894990
At the top of each column of the activity view, a progress bar is now
displayed below the activity type name based on activities scheduled.
Note that the progress bar widget is an extension of the kanban progress
bar as both have a very similar behavior.
Task 1894990
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
In the activity view footer, it's now possible to create a new record
(and an associated activity). When clicking on the link, a 'SelectCreate'
dialog is opened and the activity is created when selecting a record.
Task 1894990
For a record and an activity type (cell in the activiy view), a counter
is now displayed at the bottom right, that shows the number of
activities if more than one are scheduled.
Task 1894990
An indication that the user can schedule new activities by clicking on
an empty cell is now displayed while hovering an empty cell.
When clicking on the empty cell, the activity form is opened in a modal
defaulted to the corresponding activity type (no dropdown menu anymore).
Task 1894990
In the activity view, all activity types are now displayed in columns,
even if no activity are scheduled yet for some types.
Note that they are ordered based on their sequence from left to right.
Task 1894990
In activity view, there was a dummy logic for the deadline precision
(the year was not displayed if it was the current year).
This has been fixed with a valid logic as per locale.
Related to 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>
-Previously, The Retry button was visible on printable view of the
survey as well as on answers.
-This commit fixes the issue by passing an extra parameter to
determine whether user is in printable view or simply in answer review.
Task: 1967500
closesodoo/odoo#32618
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Without this patch, you have to redefine the field to be able to override this field.
closesodoo/odoo#33049
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Purpose: improve UTM definition and propagation in sale and account
applications, as well as in event.
Specifications
* inherit from utm mixin in sale for SO and invoice;
* propagate UTMs from SO to invoice when invoicing;
* add utm fields on registration model;
* remove website_sale_link_tracker module and inline its content in sale
and website_sale;
Merge linked to task ID 1929272
closesodoo/odoo#31260
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Replace the font selection UI by a dropdown. Make the system generic
so that a dropdown can be used for any set of options.
task-1942241
closesodoo/odoo#32437
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Xavier Morel