PURPOSE
Allow alias domains to be multiple, notably to be used in a multi company
environment where each company has its own alias domain.
SPECIFICATIONS
Add 'mail.alias.domain' information on alias model. Aliases do not use global
configuration parameters anymore. Instead they are linked to an alias domain
e.g. 'sales' linked to 'mycompany.com' alias domain: 'sales@mycompany.com'.
It is now considered as a different alias compared to 'sales@mycompany.in'
which has the same alias_name but a different alias domain.
Constraints and checks are added, as
* uniqueness of aliases is now checked inside a given domain;
* an alias name must not clash with its domain bounce or catchall;
* a combination of (alias_name, alias_domain_id) must be unique;
Crm multi-company environment is also updated to match the new alias domain
behavior.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
´extends´ generates a lot of css rules.
So in this commit, we remove it by replacing it by the ´h5´ html tag.
closesodoo/odoo#139484
Related: odoo/enterprise#49408
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Purpose:
--------
This commit adds properties (and related properties definitions) on the
following models:
- hr.employee (hr.department)
- hr_recruitment.hr_applicant (hr_recruitment.hr_job)
- product.product (product.category)
- stock.picking (stock.picking_type)
These have been added to the related form, kanban and calendar views when
applicable.
Properties have also been added to kanban and calendar views of
- crm.lead
- event.event
- project.task
(Properties had already been added on these models and form views)
Task-3458627
Part-of: odoo/odoo#132578
Purpose:
--------
This commit removes the "hideKanbanOption" from the properties field.
This option allowed to prevent users to make properties visible on cards
(kanban cards and calendar popovers).
The rationale being that there is no reason to prevent users of adding
properties on cards now that they have been redesigned (see commit [1]).
Task-3458627
[1]: https://github.com/odoo/odoo/commit/25e8fbe0a1327c289df826cf6eb7882098a4c325
Part-of: odoo/odoo#132578
To allow to search records having "done" activity (archived) assigned to
someone, we have modified the search method of the field activity_user_id (in
the activity mixin) so that it matches also responsible of archived activities.
This field is mainly used when coming from the systray to display user
activities including "done" ones but could be also used in custom filters.
We have also modified the default domain when fetching record for the activity
view so that it matches records having at least one activity, archived or not.
This prevents to load more records than necessary to display the activity view.
We also adapt the test accordingly.
Task-3300854
Part-of: odoo/odoo#138135
The following summary view of the record in the activity views have been
improved:
- project_task: task state added
- project_project: project manager added
- event_event: responsible and the dates (date_begin_located and
date_end_located) added
- account_move: total amount, customer and state added
- sale_order: total amount and the state added
- purchase_order: total amount and the state added
- crm_lead: customer and stage added
- hr_applicant (hr_recruitment): recruiter added
- survey_survey: responsible added
- maintenance.request: added equipment and responsible
- stock.picking: added scheduled_date
- repair.order: responsible, schedule_date and product_id added
- mrp.production: added responsible
- hr_leave (hr_holidays): status is added and default deadline modified see
below
Ensures that "Schedule activity" is in one line by adding a colspan.
hr_leave activity: When a time off approval activity is created as a
consequence of the creation of a hr.leave, the deadline of the activity is set
to the date_from of the hr.leave minus activity type delay_count (default 15)
except if it leads to a date anterior to today. In that case it is set to
today. That way, in the activity view, the time off approval activities are
more or less sorted by related hr.leave date_from and the cell date is an
indication of when the time off is planned.
Technical note: on most activity view, the activity record was not occupying
all the horizontal space. To solve that problem the css has been modified and
the max-width (200) that was imposed on the sub div has been removed. And as
it was impossible to impose a max-width for a flex div (which is the common
case for the activity record), the max width is imposed on each text that might
be too long using the class o_text_block. That class has been modified to
impose a max-width. That's why that class has been added in most view.
Alternativly, we could have modified the activity compiler to add that class
when the attribute full was set (not done because not sure of the consequence).
Task-3300854
Part-of: odoo/odoo#138135
Due to the Systray item add for attendance,
an additional rpc call will be performed for employees,
meaning that different counters have to be bumped.
closesodoo/odoo#135439
Related: odoo/upgrade#5234
Related: odoo/enterprise#47384
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In this commit, we add the 'foldable' option to the domain widget in crm and
event_crm.
Task-3458063
closesodoo/odoo#132008
Related: odoo/enterprise#45768
Signed-off-by: Jérémy Hennecart (jeh) <jeh@odoo.com>
The aim of this commit is to improve the impact and rendering of app
icons in bright and dark mode. It also reduces the size of svg files.
To achieve that, this commit updates the colors to flat colors. This
change will make the icons stand out and improve their readability.
task-3072562
X-original-commit: 667a19162b74fb6554a2389ba9c6e69de4ff5113
Part-of: odoo/odoo#138279
Generalize the hr.employee activity plan to any model, allowing to create
activity plan that can be launched on any model.
The activity can now be created in batch by selecting multiple record in the
list view and then clicking on a "clock" icon in a row similarly to the batch
records update (selecting multiple records allows to change for example their
name in batch in the list view). We implement also that functionality for the
plan, allowing to launch a plan on multiple records at once.
We also centralize the launching of activity or activity plan through either
the "Activities" button in the chatter or the "clock" button in the view list.
Scheduling activity is now taken in charge by a wizard that can schedule a
single activity as well as a plan. We add/update tests for checking that the
wizard is launched with the right record selection (on a single record or a
batch) and add tests for checking the wizard itself.
The plan can be defined through an added menu in the technical admin menu but
also through configuration menu added in the module crm, project.
Technical notes:
In the added wizard, to determine that there is a error, we introduce the
has_error field because we cannot use easily the error field for that. Indeed,
to determine that there is no error, we have to compare it to "<p><br></p>"
(more precisely <p><br></p>) which is not handy and may
change in the future. This is because when we write False on field error and
read it after, we get "<p><br></p>". Instead, we centralize this weird
comparison in the model in the compute method of has_error.
The ActivityListPopover still displays the activity of the record on which it
has been triggered but the button to schedule activity will launch a wizard
that create activities in batch for the selected records if more than one was
selected. For that, the ActivityListPopover component receives now an
additional prop: resIds (selected records) on top of the resId prop (record on
which the popup has been triggered). Note that when the line that trigger the
popup is not selected, the batch mode is disabled to avoid confusion.
Test are updated because the wizard is opened instead of the activity form to
schedule a new activity and as the form view is only used to edit already
existing activities, default_res_id and default_res_model are no longer passed.
We defines date_deadline and date_plan_deadline in the schedule wizard because
those date are managed differently (default value, required or not, ...).
Task-3390865
Part-of: odoo/odoo#137969
'alias_user_id' field allows to set a user when creating records through the
mail gateway. This is however quite wrong and eases spoofing. The alias owner
is not the creator of any record, nor responsible.
Current possible ways of being owner / responsible of records created through
the mailgateway
* when you send an email to an alias: if you are recognized you are already
set as creating user and logged message author;
* it is possible to use alias_defaults notably to set fields like 'user_id'
if you want to be notified / responsible of records created through this
specific alias;
Those usages are therefore sufficient, no need to have another way to spoof
users. Moreover it is hidden in technical view of aliases, no model allows
to configure it by default. Moreover since odoo/odoo@3edf181 no default
value is given to alias_user_id as it adds more (ACLs / creator) issues than
really helping setting up mail gateway flows.
Task-3453482
Prepares Task-36879 (Mail: Multi-Domain Aliases)
closesodoo/odoo#138213
Related: odoo/upgrade#5259
Related: odoo/enterprise#48692
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose:
--------
When the property field is added into a form view, the "add a property"
button is shown by default.
However, most of the time the users won't add properties when opening a
form view, making this button take up space for nothing.
To alleviate this issue, commit [1] added an option that allows to hide
this button, and added actions to allow adding properties from the cog
menu instead.
Now that properties are being added into several views, one would like
this "add properties" button to be hidden by default, and show an entry
in the cogmenu allowing add properties by default, without needing to
create an action for every view using a property field.
Therefore, a new static action "Add Properties" has been added in the form
controller that is available if a properties field has been encountered
during the parsing of the form view's arch.
The "hideAddButton" has been changed into "showAddButton" and now allows
to show the "Add a Property" by default.
Task-3458627
[1]: https://github.com/odoo/odoo/commit/1f80810e39f811122a65e11cd8cac99aa39a7960
Part-of: odoo/odoo#137589
The tempusdominus library has been removed by [1]. This commit
removes scss customizations of the library that have been forgotten.
[1] 910897fc97closesodoo/odoo#138129
Related: odoo/enterprise#48657
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose is notably to regroup some tests into a single file (notably tours
in their matching unit tests file), rename some tests / tours, ... and
globally try to lessen test file split.
Task-3535845 (TestMail: Reorder tests tours / files)
Prepares Task-3527752 (Mail: The Pre-Major Freeze FixImpLint)
Part-of: odoo/odoo#137895
When possible, use '@users' decorator. Rename tests to better match their
main purpose, notably
* test_mail_track*: mail_track specific (specific fields, display)
* test_message_track*: overall behavior of 'message_track', notably subtypes,
template usage, ...
Add some additional tests and improve test coverage, as some field types
were not covered (date, datetime, text notably). Improve currency
check for monetary fields.
Move 'mail.tracking.duration.mixin' tests into the file testing mixins
linked to 'mail.thread', rename the Case class according to current test
guidelines.
Also starting from now, `MailCommon` flushes tracking automatically at
setup time, allowing to remove some custom flush done in tests. That way
tests are less prone to non deterministic errors. This implies some changes
in execution of tests, which means some updated query counters notably.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
- 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
Thibault Delavallée