- Before fix:
only select activities done today or in the future so
it does not reflect the expected behavior of the filter.
- After fix:
have an expected data with suitable filter name
- OPW: 3504670
closesodoo/odoo#137468
X-original-commit: acb27f6cd225571ae919c5a50a6bba504cd75589
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
The cookie service was replaced by a utils file in core. This was done
to be able to use the cookies without the need of environment.
"Om Nom Nom Nom" - Cookie Monster
part-of task-id 3439226
closesodoo/odoo#136782
Related: odoo/enterprise#48005
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The prorated MRR displayed in the kanban header of CRM's forecast resets
to 0 when moving leads from one column to another
Steps to reproduce:
1. Install CRM
2. Go to Settings > CRM and enable Recurring Revenues
3. Go to CRM > Reporting > Forecast
4. Open a lead in the first column and set a recurring revenue and a
recurring plan (after the "+" in the expected revenue)
5. Go back to Forecast, a value is displayed after the "+" next to the
progress bar of the first column
6. Change the column of the edited lead, the prorated MRR of all columns
change to 0
Solution:
ForecastKanbanController should extend crmKanbanView.controller
Problem:
The ForecastKanbanController extended the generic KanbanController so it
didn't inherit from the crmKanbanView.Controller override of the getter
`progressBarAggregateFields` that adds the prorated MRR to the fields
used in the progress bar
opw-3463826
closesodoo/odoo#136929
X-original-commit: bab34140725a014995d9374ec0994399776ce4aa
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PR #105873 added computed indexes on the `mobile` and `phone` commits
for the benefit of `phone_mobile_search`, however it created both
indexes to work on the `phone` field as source, rather than whichever
field they were named after and partial for. As a result, the index
has no effect when searching on `mobile`.
closesodoo/odoo#135878
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Update (some) query counters according to runbot state.
Also make some tests deterministic when involving company name.
Task-36879 (Mail: Support MultiCompany Aliases)
closesodoo/odoo#135288
Related: odoo/enterprise#47345
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit changes the behavior of the avatar card preview so that it
is now triggered on click instead of on hover and the previous behavior
of the click event (open chat) is therefore removed. It also adds the
functionality to the Message and Activity components of discuss so that
clicking on the avatar inside these components will also show the card.
It also makes sure that the id of the user is added to the persona even
if nothing indicates that it should.
task-3442819
closesodoo/odoo#131355
Related: odoo/enterprise#47084
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
psycopg2.extras.execute_values was introduced in PR #101237
however it pypasses the override logic for cr.execute. As a result
1. --log-sql cannot log these queries
2. assertQueryCount cannot notice these queries
...
This commit create a new api cr.execute_values to support the same SQL feature
without losing the override logic for cr.execute
closesodoo/odoo#131190
Related: odoo/enterprise#47374
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Establish a set of target font-weight values (may not directly match the
final result on screen).
Enable the system to naturally utilize the "bolder" font-weight.
Remove previous customizations designed for "Roboto" that clashed
with certain system-fonts.
Enforce the "normal" font-weight for icons, regardless by their parent
design.
Adapts some kanban titles.
closesodoo/odoo#134824
X-original-commit: 74fce06cad4000a3894757d4fef9074b64153b7b
Related: odoo/enterprise#47140
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Impacted versions:
16.3+
How to reproduce:
- open CRM > Forecast
- drag&drop a lead from a column to another
- click on "add next month" button
Current Behavior:
- the progressbars revert back to their state before the drag&drop
Expected Behavior:
- the progressbars keep their updated value after the drag&drop
Technical explanation:
After [1], the split of the progress bar logic from the relational model, only
notifying the model of a reload is not enough to correctly update the
progress bar values. It is therefore required to manually do it in the CRM
Forecast view after adding a column.
Master update:
Furthermore, after [2], the adaptation of the codebase to the new relational
model, the domain modification of the `forecast_kanban_model` was not
transcripted correctly: the domain modification for the fillTemporalPeriod
should be added by replacing the previous one if present, not simply added
(because then we have a constantly growing domain with contradictory leaves).
Also, since the new `RelationalModel` makes it mandatory to render the view
after a `DynamicGroupList.load` because `DynamicGroupList` is `Reactive`, to
avoid `progressBars` flickering when adding a forecast kanban column, the
`ProgressBarHook._updateProgressBar` should store the result of its
`read_progress_bar` call in `_pbCounts`. This makes it so that when the
`DynamicGroupList.load` is done, already computed progressBars will keep their
value and not switch back and forth between the previous state of `_pbCounts`
computed in `loadProgressBar`.
[1]: https://github.com/odoo/odoo/commit/58ca40b03215ef4c6c575267494dc8bccc30a033
[2]: https://github.com/odoo/odoo/commit/218ad8456a06503dd508e7216edcffdc90b35cac
task-3497579
closesodoo/odoo#135149
X-original-commit: b53b46ec36818615b7beb1d24fd44c9f8d69063a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS: MAIL COMPOSER IN MAILING
When using the composer with a mailing, it currently skips recipients whose
email is a multi-email due to the strict usage of 'email_normalize'.
We can improve multi-email support by effectively checking for the first
email found, using the "less strict" mode of normalize. It means more emails
are detected as valid, and therefore sent.
Due to lower support of multi-emails when sending emails, this even allows
to send multiple emails as all emails are mailed.
SPECIFICATIONS: DEFAULT RECIPIENTS
Mailings are generally done using default recipients, aka using a model method
that returns the people to mail: customers ('partner_id'), customer emails
('email_from'), specific implementation, ...
This is implementation using '_message_get_default_recipients' that returns
'partner_ids', 'email_to' and 'email_cc' that are then used in the mail
composer to generate final recipients.
In this commit we better handle the content of email fields to avoid issues
with multi-emails. For that purpose we correctly split the content of those
fields. We now have several 'email_to' for records having multi-emails instead
of a single badly-formatted 'email_to'.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@4a0d87d44f
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Post-message hook is used in various apps to link records to a newly created
created partner. This is the case notably when used with a template as it
creates partner on the fly based on emails to always handle partners.
We now check either the complete 'email', either the normalized version of
it to avoid comparison issues with multi emails and formatted emails. As
'email_normalized' now supports multi-emails by storing the first found one
it helps finding the partner.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@e5ad9e0371
Part-of: odoo/odoo#134934
As it already normalizes returned emails some manual calls to 'email_normalize'
are not necessary. Some variable names are updated to be clearer about the
email being normalized.
Parsing contact name and email is also moved into a tool function to avoid
using a partner environment just for a tool parsing method.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@f7add44c28
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When having multi-emails input in an email field, 'email_normalized' field is
currently 'False', as they expect the field to contain a single email. This
has several drawbacks
* searching partners or fetching information based on emails does not work as
most tool methods use 'email_normalized' which is False (see e.g.
'_message_partner_info_from_emails', '_mail_find_partner_from_emails'
or 'find_or_create');
* blacklist is not available as it is based on 'email_normalized';
* mass_mailing wrongly considers those emails as invalid and cancel their
mail and related trace, as it tries to skip sending emails to invalid
emails;
Be more defensive and use first found email in case of multi-emails field.
Other emails are ignored. It is already an improvement that does not break
flows in stable and allow more emails to be sent.
before
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: False
after
-> email: '"Raoul" <raoul1@raoul.fr>, raoul2@raoul.fr'
-> email_normalized: raoul1@raoul.fr
A side effect is that it helps finding back some partners, as indicated in
tests where less phantom partners are created. It also helps suggested
partners / emails flow in discuss.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@90218186c5
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
When possible, use 'email_formatted' field on partner, instead of calling
'format_addr'. That way management of corner case input (multi emails and
double encapsulation) is managed by the computed field itself.
When 'format_addr' has to be used, ensure email part is normalized to avoid
formatting issues.
Also use tools to extract emails instead of 'email_re' regex when possible.
That way all code extracting and managing emails go through the same stack.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@1c06014531
Part-of: odoo/odoo#134934
PURPOSE
Be defensive when dealing with email fields, notably when having multi-emails
or email field containing an already-formatted email.
SPECIFICATIONS
Main fix in this commit: fix multiple nested formatting in 'email_formatted'
computation for <res.partner>. Other use cases are mainly left untouched as
we let users deal with their input. In summary :
* double format: if email already holds a formatted email, we should not use
it to compute email_formatted, like
name: Name / email: 'Format' <email@domain.com>
-> before '"Name" <"Name" <email@domain.com>>"
-> after '"Name" <email@domain.com>''
* multi emails: sometimes this field is used to hold several addresses
like email1@domain.com, email2@domain.com. We currently let this value
globally untouched by extracting emails and joining them, as we do not
expect email_formatted to be a list of emails. Extractin emails allows
to filter out extra text stored in email field, like
name: Name / email: text, email1@domain.com, email2@domain.com
-> before: "Name" <text, email1@domain.com, email2@domain.com>
-> after: "Name" <email1@domain.com,email2@domain.com>
* invalid email: if something is wrong, better keep it in email_formatted
than harcoding "False". Indeed this eases management and understanding
of failures at mail.mail, mail.notification and mailing.trace level. This
behavior does not change as it was already implemented like that even if
not sure it was intended;
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@9175bbd8e2
Part-of: odoo/odoo#134934
This method is still not really tested, except its override of 'mail.thread.cc'.
So better have a test, especially in CRM that has some specific overrides.
Formatted email and multi-email input are tested, to check their current
support. Next commits will try to improve that, notably avoid formatting
issues.
Task-2612945 (Mail: Defensive email formatting)
X-original-commit: odoo/odoo@ce1fb51352
Part-of: odoo/odoo#134934
*: base, crm, digest, mail, mass_mailing, sms, test_base_automation,
website_forum, website_sale
This commit makes "Automated Actions" more discoverable and usable by:
- Adding a menu in the kanban header config dropdown to add/edit them.
- Creating a new custom kanban view for a clear understanding of each
automated action record and its associated actions.
- Introducing new "smart" triggers that appear in the form view based on the
chosen model:
- Updated Values category:
- "Stage is set to" when a `stage_id` field exists in the model,
allowing users to select a specific stage value.
- "State is set to" when a `state` field exists in the model,
allowing users to select a specific state value.
- "Priority is set to" (`priority`) where users can select a specific priority.
- "User is set" (`user_id`, `user_ids` fields)
- "Tag is added" (`tag_ids` field) where users can select a specific tag.
- "On Archive"
- "On Unarchive"
- Timing Conditions:
- "After creation"
- "After last update"
- Deprecating previously known triggers "On Creation" (`on_create`) and "On
Update" (`on_write`) to simplify the user experience. "On Creation & Update"
(`on_create_or_write`) is retained and renamed to "On save".
- Changing the `ir.actions.server` Many2one relationship to a One2many
relationship. Automated actions can now directly contain multiple actions,
eliminating the need for an "Execute several actions" action in automation
rules.
- Introducing a widget for the new `ir.actions.server` One2many field for a
clearer understanding of multiple actions.
This commit also enhances the usability of "Server Actions" (`ir.actions`) by:
- Removing the `ir.server.object.lines` model and the associated `fields_lines`
One2Many field. The attributes of the removed model are now merged into
`ir.actions`. An action can now write to only one field, and the create action
is now a name_create action.
- Adapting the form view when creating an "Update the record" action. The value
field shown adapts itself based on the field to update; this field can be a
`reference` field for a `one2many` `update_field_id`, a `one2many` field for a
selection `update_field_id`, or a `text` field otherwise.
- Refactoring the form view to display only relevant details and other
miscellaneous improvements.
Taskid: 3085360
Part-of: odoo/odoo#114352
Co-authored-by: Florent Dardenne <dafl@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
When we haven't provided a custom action, the tour step runs the default
action. In the final step of the tour, when there is no `run` or
`isCheck` provided, It shows warnings of 'ignoring action (auto) of last
step' as it can lead to a race condition.
This commit resolves the warnings: `ignoring action (auto) of last step`
task-3429500
closesodoo/odoo#129239
Related: odoo/enterprise#46683
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit, adds a new python method (`web_save`) to save a record, and
optionally read-it again in one rpc call. This optimizes the current
behavior that is to save a record in one rpc, and read-it in a second
rpc.
web_save, will receive the list of IDs of the records to save (if this
list is empty it will create the records, if not, it will write on the
existing records), the list of changed fields, and the unity
specification as optional argument to read the created/modified records
(if the specification is not set, the function will return a list of IDs
of the created/modified records).
closesodoo/odoo#133021
Task-id: 3453184
Related: odoo/enterprise#46559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Instead of having a count field for meetings linked to
a crm.lead, show a (start) date instead:
- If there is a next meeting, show its date + "Next Meeting"
- Otherwise, show last meeting date + "Last Meeting"
- If no meeting, show no date and display "No Meeting"
- hide button for new records
This commit removes the field "calendar_event_count" that
has no use anymore. A test using the count field is adapted.
Another is added to assert new fields behavior.
UPG PR odoo/upgrade#4935
Task-3418397
closesodoo/odoo#128366
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
These changes are made as a result of simplifying attrs and 'states' in
views.
Before applying the migration script, it is necessary to fix some views.
These views are erroneous and either work by chance or are simply
untested. We have for example wrong domains, elements used by modifiers
but not present in the view, obsolete domain operators, inherit views
not targeting the right views, xpaths using attributes as target, the
use of %(...)s in views, false attribute value types in python.
Part-of: odoo/odoo#104741
Goal:
* Simplified modifiers to only have one way to define modifiers;
* Remove states attributes on python field;
* Use python expression in view `required`, `readonly`, `invisible`;
* More accurate validation of xml views.
This commit change the syntax to python expression. The next commit
will update/convert all xml views.
Before this commit:
* the `required`, `readonly` and `invisible` attributes can only have
values of `True`, `False`, 1, 0 or a python expression to use the
context;
* the `attrs` attribute define a dict. The key of this dict was
`required`, `readonly` and `invisible` and the values are the domain or
a string representing a domain to be evaluate as python expression.
This python expressions was evaluate by the javascript with view fields
and other contextual values as: context, uid, parent, active_id,
active_ids, active_model, allowed_company_ids, current_company_id.
* the `states` attribute in the view was a comma separated list of the
state. This list was combined with the `invisible` attribute;
* the `invisible` attribute on python field is used as default value;
* the `states` attribute on python field was dictionnary with state as
key and list of tuple. This structure was combined with `readonly` view
attribute.
* After combining, the resulting domains of the different attributes
`required`, `readonly` and `invisible` are evaluated with the values of
the fields. The `invisible` attributes is splitted into two use:
`invisible` and `column_invisible`.
After this commit:
* The attributes `required`, `readonly`, `invisible` and
`column_invisible` define python expression. This python expressions
are evaluate by the javascript with view fields and other contextual
values as: context, uid, parent, active_id, active_ids, active_model,
allowed_company_ids, current_company_id.
The domains can contains contextual value and will be evaluate by the
javascript.
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'readonly': [('field_b', '!=', False), ('field_c', '=', parent.c)]}"/>
<field name="field_b" states="draft"/>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a') or field_b and field_c == parent.c"/>
<field name="field_b" invisible="state != 'draft'"/>
```
Some inherited views will be modified differently in order to maintain
the previous behavior:
```xml
<field name="field_a" readonly="not context.get('show_a')" attrs="{'invisible': [('field_b', '!=', False)]}">
```
```xml
<field name="field_a" position="attributes">
<attribute name="attrs">{'readonly': [('field_c', '=', False)], 'invisible': [('field_d', '!=', '3')]}<attribute>
</field>
```
will be replaced by
```xml
<field name="field_a" readonly="not context.get('show_a')" invisible="field_b">
```
```xml
<field name="field_a" position="attributes">
<attribute name="readonly" add="(not field_c)" separator=" or "/>
<attribute name="invisible">field_d != 3<attribute>
</field>
```
Validation:
A stricter control is made on the level of the attributes (modifiers)
and the fields necessary for these. The use of the previous attributes
'attr' and 'states' triggers an error (these no longer exist after the
application of the migration script)
task-2495504
Part-of: odoo/odoo#104741
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
Improve gettext to directly handle value injection within translations,
removing the need for sprintf.
closesodoo/odoo#123932
Related: odoo/enterprise#45370
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Cleanup alias usage and definition. Prepare code to ease future changes and
improvements. Notably
* add a 'alias_email' computed field on the mixin allowing to have the
complete alias email when set, and False in case it is inactive or linked
to an inactive alias domain;
* remove unnecessary alias_id field definition when just the help differs
from the standard definition coming from the 'mail.alias.mixin';
* use fields coming from 'inherits' instead of using alias_id and its sub-
fields; notably use 'alias_display_name' and 'alias_email' fields;
* remove useless custom code and management;
* improve alias parameters support code in configuration parameters;
Task-3453343 (Mail: Cleanup Alias Usage)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130632
In this commit, _t import from import { _t } from
"@web/legacy/js/services/core" and from
web/static/src/legacy/js/core/translation.js are replaced by
@web/core/l10n/translation.js.
task-3292454
closesodoo/odoo#130865
Related: odoo/enterprise#45270
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Rename alias domain and aliases used a test data. This allows to make
them easier to read, follow, grep and understand.
Activate multi-company on alias and gateway tests, ensuring it currently
has few impact on tests.
Task-3453577 (TestMail: Update Alias/Gateway tests for MC)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130768
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Support by default 'phone' and 'mobile' fields if present on model as phone
fields to fetch when searching for a number. This allows to remove several
of unnecessary overrides always doing the same thing.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
As the "Create" button is renamed to "New" so update it and remove "top left" in
helper to enhance clarity and avoid any confusion.
Task-3420529
closesodoo/odoo#130432
X-original-commit: 7a1bcb9c74eb48877731367b3da95c1eec7db19b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since the relational model was rewritten (PR 114024), it is now reactive,
so it is no longer necessary to use model.notify() to render the view.
closesodoo/odoo#130058
Related: odoo/enterprise#44781
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If you have some leads which are nearly always won or lost, you may
end with a probability which is either 0% or 100%.
These values indicate that the lead is lost or won, therefore we must
check the limit values.
opw-3413206
closesodoo/odoo#130109
X-original-commit: 49166f3c291c44d6635d30687ec8d439de145d01
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
International formatting ease reading the value, which is handy in onchange.
This partially reverts odoo/odoo@51d571fab4 .
closesodoo/odoo#129851
X-original-commit: dab802a939c97603f70c504e98ecc92b0ac552f9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit, the x2m present in a record's evalContext was
represented by the resIds defined in the config. It therefore did not
contain the current changes. It should therefore be represented by the
currentIds of non-virtual records.
How to reproduce:
- Create a new record with a m2m field having at least one default record
- Edit a field which triggers an onchange with a context depending on the
value of the m2m
Before this commit:
The domain and context used contain an empty list for the m2m.
After this commit:
The domain and context used contain a list with the default id for the m2m
Part-of: odoo/odoo#114024
This commit adapts the code in addons w.r.t. the introduction of
the RelationalModel.
Main changes that were requested are:
- record datapoints no longer always have an "id" key in their
data (they still do if the id field is in the view), so we use
record.resId instead
- the new model is based on fined-grained reactivity, so several
components that previously relied on onWillUpdateProps to update
their internal state no longer worked. Typically, using the hook
"observeRecord" is the way to go now.
- specialdata are no longer handled in the model, so the components
needing specialData can use the hook "useSpecialData"
- more generally, all overrides of models (RelationalModel or
KanbanModel) needed to be reworked.
Part of task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
The purpose of this commit is to change the evaluation of
date_deadline based on month for 'Quote for 12 Tables' demo data.
As calculating expected revenue for next month give different amount
from expected. This is because previously 4 weeks gives 28 days
and now 1 month will set same date of next month.
Task-3414271
closesodoo/odoo#129103
X-original-commit: c08d69a00e2ab5fa72934bddee804aa17642466d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Allow sharing records between company
* accounts
* taxes
* fiscal positions
* products
* ...and some related models
These records can be read and used in children companies.
This can be used to
* have different branding for different businesses
* allow more complex security rules
* consolidate branches differently
* manage different tax reports with different tax ids in the same
country
task-3371677
closesodoo/odoo#125642
Related: odoo/enterprise#43215
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
* = crm,hr_work_entry_holidays
This commit changes the value of the "QueryCount" as `mail_enterprise`
executes a new query to search for devices associated with the partner.
Task ID: 3123678
closesodoo/odoo#127198
Related: odoo/enterprise#43577
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
kva