Before this commit, links to the documentation were referenced the
previous version, 13.0, instead of the current one, 14.0.
Eventhough there is a redirection done by NGINX of a "versionless" URL
to the latest one (e.g. /documentation/user/general/auth/google.html
-> /documentation/user/14.0/general/auth/google.html as of today), the
goal is to keep links owrking for users that will still be using the
14.0 in three years (and should not endup on the 17.0 doc).
closesodoo/odoo#60228
X-original-commit: 7ac08486d91d0ff0151abeeda057ffa6beda72e8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
- don't reset `stringifiedDomain` when changing thread (this led to the
control panel displaying obsolete filters)
- refresh non-main cache that are currently displayed when there is a known
change of messages in the same thread's main cache
- refresh non-main-cache on displaying them, to fetch potentially new messages
- fix discuss "select all" conditions
task-2171873
task-2282374
closesodoo/odoo#59644
X-original-commit: b89dc5f949b3ad062fc4197a4152066c207e1bf9
Related: odoo/enterprise#13962
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
The task will require adding new files which we don't want to do in stable.
closesodoo/odoo#58876
X-original-commit: 5580a0e4e44744d13ec9bed03f2116c043c611b1
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, there were some traceback while performing
several actions due to context that was not properly evaluated.
This commit fixes those traceback by evaluating the context and
thus enabling user to perform those actions without traceback.
We also clean some badly-configured email actions in accounting.
Task Id : 2302572
PR #56501
X-original-commit: 71a39c6650e18b71a212bf21150fece683ae01c7
Co-authored-by: D J <dja@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Passing a field containing `undefined` should lead to the same result as not
passing the field.
Fields that relied on `undefined` as a value have been changed to use the newly
introduced `clear` command, that resets a field to its default value (often
that is equal to `undefined`).
task-2336491
closesodoo/odoo#58314
X-original-commit: b18824485483564d2ab80f41914a3548aa528ae0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, the "to followers" message inside the chatter composer was
missing.
Fix also some padding issue.
This also restore the form dialog when you try to send a message to a suggested
recipient that doesn't have a partner (someone in CC email for eg).
But now, suggested recipient without partner are unchecked by default and the
form open when the user try to check them. If the user discard the form dialog,
the suggested recipient isn't checked.
This is better since only a partner will receive a notification.
task-2280157
closesodoo/odoo#58162
X-original-commit: 67d151cc36871d87b92676357a31a70de5a92fce
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce the bug:
- Have more than 100 users
- Have CRM installed
- Go to CRM > Configuration > Activity Types > Create
Bug:
The Default User selection only displays the 100 first users
opw:2330339
closesodoo/odoo#57455
X-original-commit: 75eef2506ba415d3e2be5ac3c14029bba3ed26d0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Automatically load messages from a thread cache only if the thread cache is used
in at least one thread view.
Ensure thread viewer don't keep thread view records alive when they are not
displayed.
This change is particularly important for performance, to avoid spamming RPC at
init if many threads are opened in chat windows.
task-2310623
closesodoo/odoo#57121
X-original-commit: 8d3413ff647de8d98c6858062dd07dde4160af95
Related: odoo/enterprise#12979
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Remove duplicate fields in tree views / kanban (outside of templates).
A field should not be present twice in a kanban view. If one of the nodes
has custom attributes behavior of other nodes is somehow unpredicatable.
Having field present only once gives a more coherent behavior. Xpaths
could also lead to weird results if fields are present several times.
Notably adding a field in the view preface instead of inside the view
template itself (see b63043e for example of fix).
An heuristic to detect duplicate fields will land soon in master. As this
commit targets a stable version only view fixes are provided.
Task ID-2329114
PR odoo/odoo#56946
X-original-commit: 90f8e9255fa46c408763346ed135d9e561ae7fd5
The "viewer" should be the "parent" not the view itself. This distinction will
become important in a future commit to allow viewers to not display the view in
some situations.
Rename done as a standalone commit to ease diff readability.
Part of task-2310623
closesodoo/odoo#56751
X-original-commit: f9ee1cf5f904116e4d1d70a8eaf4ee1d58b18a3a
Related: odoo/enterprise#12764
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, on page reload, sometimes web client crashed with
`Cannot read 'messagingMenu' of undefined`.
This happens due to messaging components making use of `messaging` in
`env` as if it was always set. In some rare cases, this is false,
hence the crash. This happens on root components of messaging such as
the messaging menu.
Creation of `env.messaging` has to be async, in other to ensure all
JS module that patches messaging are applied. The mounting of
messaging root components depends on other parts of the web client
like the SystrayMenu. So the proper fix is to guard `env.messaging`
on these root components.
Task-2238245
closesodoo/odoo#56684
X-original-commit: d1483ff3c83bb3146e80e5d65a27915c5b2a2bf9
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
PURPOSE
Ease the configuration of external email servers by adding links to the
documentation and by making errors more user friendly.
SPECIFICATIONS
This is done by catching more exceptions when testing outgoing mail server
connection and giving related hints.
A link to the documentation is also added in mail: Settings > External Email
Servers feature: add a link to this doc: https://www.odoo.com/documentation/user/13.0/discuss/advanced/email_servers.html
Task ID-2273671
PR #54176
X-original-commit: d30682f4d4aeaefa077ba284a60c93f3a020365f
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closesodoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose is to clearly distinguish
* common: holding common code for emojis-enabled fields;
* text emoji field: support of emojis in text fields;
* char emoji field: support of emojis in char fields;
Task ID-2224393
PR #49096
*mail,point_of_sale,web_editor,website
In the tests, required services are deployed for each test
independently. There is no need to have, in additon, all services
deployed globally. Worse, it could conflict and lead to unexpected
results.
This commit ensures services are no longer deployed globally in
tests. It turns the module 'web.env' into a declarative module with
no side-effect, by moving the service deployment to main.js, which
isn't added to the tests page.
Task 2287397
closesodoo/odoo#53817
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
FIX: use the correct API of mail.channel.py to unfollow a channel
i.e.: `execute_command_leave`
FIX: unpinning a channel has immediate effect on the interface
chatWindows are closed, and the inbox is displayed
FIX: unpinning a channel destroys corresponding chatWindows across tabs
It also unpins the channel in other tabs
FIX: python sends is_pinned as part of the channel_info
both at init messaging and in the main bus notification
That way, we can keep track of the synchronization of the pin status
between JS and python
task-2275000
task-2267941
closesodoo/odoo#53703
X-original-commit: d4fcc64acb2fc0c6fd9df505380f665abd8b39c4
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit sets attribute sample="1" in a bunch of list and
kanban views, to enable the new sample data feature when views are
empty.
Task 2232801
X-original-commit: 5471309b35619f307242c2704c7681ba63d2be42
This commit is a significant rewriting of client-side discuss, chatter,
chat window, and messaging menu using OWL. The behavior should be broadly
the same, with some slight functional changes here and there.
From a technical standpoint, the code of messaging is mainly organized in 2
main groups of modules:
- models, which are logical entities that depict the client-side state of
messaging as a whole.
- components, which are in charge of displaying information from models.
This refactoring also introduces new JS guidelines regarding folder structure
(/static) and naming rules for JS modules.
Community PR: https://github.com/odoo/odoo/pull/39023
Enterprise PR: https://github.com/odoo/enterprise/pull/6249
Task-1914207
This PR is a collaborative work by Alexandre, Julien, Sébastien and Xavier,
with the precious help of Lucas to speed it up towards the end.
closesodoo/odoo#39023
Related: odoo/enterprise#6249
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Co-authored-by: Alexandre Kühn <aku@odoo.com>
Co-authored-by: Julien Giannone <jgi@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Co-authored-by: Xavier Dubuc <xdu@odoo.com>
PURPOSE
Avoid flickering and incorrect display of warning box in SMS when updating
the number to contact.
SPECIFICATIONS
Currently when an user uses composer to send an SMS, number is validated
at onchange. It leads to two issues
* jump of content as a warning box appears;
* visual warning displayed after user may have clicked on "Send"
button, leading to warning not being useful;
We choose to validate number in real time in order to give directly
a feedback to the user. It also lessens flickering on composer screen.
This is done by allowing to trigger the 'change' event on key down. This
requires a specific onchange_on_keydown option to be used on char field.
LINKS
Task ID 2229050
PR #51159closesodoo/odoo#52962
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Don't try to save bytes, make longer sentences, easier to translate
instead of splitting it into small blocks of one word.
https://www.odoo.com/documentation/13.0/reference/translations.html#blocks
Courtesy of Erwin van der Ploeg for raising the issue
X-original-commit: 737ee6393cd99b0c41272f6cfa9a0acb68276744
Purpose
=======
Task 2195254 introduced many wonderful widgets to pimp the list view.
This task aims at implemeting them into the Services apps: project,
timesheets, helpdesk, expense, planning and field service.
Remaining days: https://drive.google.com/file/d/1o4Wn47445GxLqBkw-ifH9MgtFU_437xz/view
Avatar: https://drive.google.com/file/d/1yDwJWP0MZCUKZbqCa8hte1ziVTYRMMtb/view
Activities: https://drive.google.com/file/d/1e_rXH50eZq4zY2HOzw7_pfgiD39SoRIl/view
Field-specific decorations: https://drive.google.com/file/d/1WFnqJ-jkyDFftRHxWW4bgomoWrOpOuaY/view
More control on buttons
Specifications
==============
You will find below a list of which widgets to apply to which fields by
model. Some changes have to be done in the form/kanban views as well.
1) project.task
remaining days -> date_deadline -> list + kanban + form views
hide this field if is_closed is true
avatar -> user_id -> list view
activities -> 'next activity' field to be added -> list view
field-specific decorations
https://nimb.ws/ACewrY remove the current orange/red decorations we have
if planned_hours > 0, display the remaining_hours field in (list view):
red if progress is > 100%
orange if progress is between 80% and 100%
green if progress is <80%
display unit_amount in red if > 24:00 -> form view
2) rating.rating
display the rating in:
green = satisfied
orange = not_satisfied
red = highly_dissatisfied
list + form views
3) project.project
avatar -> user_id -> list + form views
4) account.analytic.line
avatar -> employee_id -> list view
display unit_amount in red if > 24:00 -> list + kanban + form view
https://nimb.ws/eIWa7E merge the timer and duration fields together
5) helpdesk.ticket
avatar
user_id -> list view
employee_id under timesheet_ids -> form view
remaining hours -> sla_deadline
activities -> 'next activity' field to be added -> list view
field specific decoration -> display unit_amount in red if > 24:00 -> form view
6) hr.expense
avatar -> employee_id -> list view
activities -> 'next activity' field to be added -> list view
badge -> state -> list view
draft = blue
reported = green
approved = green
done = green
refused = red
combine the unit_amount and the currency_id fields (see the total_amount field for reference) -> list view (idem for the expense_line_ids one2many on hr.expense.sheet)
display the total_amount in bold
move 'company_id' before 'amount'
7) hr.expense.sheet
avatar
employee_id -> list view
user_id -> list view
activities -> 'next activity' field to be added -> list view
badge -> state -> list view
draft = blue
submit = green
approve = green
post = green
done = green
cancel = red
display the total_amount in bold
move 'company_id' before 'amount'
8) planning.slot
avatar -> employee_id -> list view
decoration
display the allocated_percentage field in red if > 100% -> list + form view
display the forecast_hours field in red if > planned hours and if planned_hours > 0 -> form view
display the effective_hours field in red if > forecast_hours and if forecast_hours > 0 -> form view
9) misc
calendar.event -> avatar -> user_id -> form view
mail.activity.type -> combine the delay_count and delay_unit fields together -> list view
note.note -> 'next activity' field to be added -> list view
crm.lead.mining.request
combine the lead_number and lead_type fields together -> list view
display the name in bold
badge -> state
draft = blue
done = green
error = red
planning.slot.template -> display the duration field in red if it is = 0
closesodoo/odoo#51271
Taskid: 2248351
Related: odoo/enterprise#10605
Related: odoo/upgrade#1252
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=========================
The goal of this task is to set up some kind of guidelines to make
kanban views consistent.
It is fine having different kanban views, but if a UI element is shared
among several kanban views, it should behave/look the same so the user
knows what to expect.
Kanban views can be split into two types:
==> 'documents' kanbans, such as res.partner, crm.lead, etc.
- those records are created/edited often, numerous
- 'opening' the card means accessing the record
==> 'dashboard' kanbans,such as stock.picking.type,account.journal, etc.
- those records are not created/edited often, there are much less numerous
- usually presented as dashboard, where 'opening' the card means
accessing a set of related 'documents' (clicking on a account.journal
to access account.move, or stock.picking.type to access stock.picking)
- configuration of the 'card record' is done through a dropdown to
access configuration
Here are some guidelines for consistency. Bear in mind that those are
not rules, but guidelines for consistency that we'd like to keep in
mind when designing.
==> 'documents' kanbans
- the record is accessed through global click
- the user avatar is at the bottom right
- the activity widget is at the bottom left (in last position if
there are other elements)
==> 'dashboard' kanbans
- the record is accessed through a 'Configuration' option in the card dropdown
- there is no global click, and therefore no focus shadow
- the dropdown icon (o_kanban_manage_toggle_button) is always visible,
with icon fa-ellipsis-v
- the listview counterpart should be presented as a dedicated
configuration menu, and shouldn't be in the 'dashboard action'
- links in the body of the card are structured as follows: link with
<count>+label, then any additional aggregated metrics (not link) to the right
example https://drive.google.com/file/d/1ZP6HDHTtC7cQ6rDWgqLoPs6U8JCeNVkW/view?usp=sharing
==> global guidelines
- the title font color is #212529, with 500 weight
- the subtitle font color is #666666, with 400 weight
- the font size is 1.083rem
- text overflow is handled through linebreak, not ellipsis
- numerical values are aligned to the right
- the kanban state widget is at the bottom right
SPECIFICATION
=================
AS per guidelines Improved follwing kanban/dashbaord view
- hr_job
- hr_department
- hr_work_entry
- hr_appraisal
- fleet_vehicle
- product_template
- sale_subscription_template
- crm_team
- res_partner
- event
- stock_picking_type
- mrp_eco_type
- maintenance_team
- quality_alert_team
- account_journal
Added the department menu on employee with default kanban view
Added sequence in hr_work_entry list view
TaskID: 2206372
Related Enterprise PR: https://github.com/odoo/enterprise/pull/10341Closes: #50536
This list actually contain all moderated emails list, not just banned one.
Name is confusing as allowing emails increases the counter of "ban list".
Spotted when working on task ID 2238597
Use the new Many2OneAvatarUser field widget in some kanban views,
which allows to open a DM chat window with the corresponding user
by clicking on the avatar.
Part of task 2195254
This commit adapts several views to make them use newly defined
widgets, the new decoration-xxx mechanism on fields, and to adapt
them to the new design of buttons.
Part of task 2195254
This widget is an extension of Many2OneAvatar, designed for
many2one fields pointing to the 'res.users' model, or a model having
itself a many2one field pointing to 'res.partner'.
With this widget, when the avatar is clicked, we open a DM chat
window with the corresponding partner. If the user clicked on itself,
we open a blank chat window for the sake of consistency.
In kanban views, this widget only displays the avatar.
Part of task 2195254
A mail alias is still linked with the res.users model with 2 fields, alias_id
and alias_contact (related). It is not used anymore. We can therefore remove
those fields.
Aliases were added at 052f2ace57 . Purpose was to be able to discuss with
users directly using Odoo as a mailbox. However it was not usable and was
quickly deactivated. Aliases on res.users was removed at 029d1baf35 . It was
decided at that time to not support alias on users anymore as it was creating
more issues than adding communication facility.
This commit finally removes the unused fields. If necessary in some custom
flow they can always be added through studio.
LINKS
Task ID 1919277
Community PR odoo/odoo#41160
Enterprise PR odoo/enterprise#6983
Upgrade PR odoo/upgrade#872
Co-Authored-By: Rémy Voet <ryv@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
Before this commit, the test assets were called with a `t-call-assets` and contained
themselves some other `t-call-assets` to the back-end assets. According to the current
specification, having nested `t-call-assets` will result in a compilation of the
lower levels regardless of the current debugging mode.
Now, the test bundles (desktop & mobile) have been arranged so that their `t-call-assets`
are all called on the same level.
closesodoo/odoo#49306
Related: odoo/enterprise#9797
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously a blacklisted phone number or email address could only be
removed from their respective blacklist by going to the corresponding
blacklist view [in mass_mailing_(sms)] and manually
archiving/deactiviting the entry. All users could see that an email was
blacklisted via an fa-ban icon added next to their corresponding field
in the modules: crm, mass_mailing, mass_mailing_sms, and contacts (via
extension).
This commit adds additional fa-ban icons next to blacklisted phone
numbers and makes all instances of these icons clickable to remove them
from their corresponding blacklist using a wizard. There are several
limitations to this implementation including:
1. If both a mobile and phone number field appear within a crm lead
instance, then only the mobile field will indicate if it is blacklisted
(due to current implementation of PhoneMixin which only checks 1 phone
value against the blacklist and "sms" which returns mobile numbers first).
I.e. if a phone field value is blacklisted, but a value is typed into the
mobile field, then the phone field will never indicate that it is blacklisted.
2. If someone clicks on a unblacklisting icon after changing the
corresponding field value without clicking off the field input, then the
latest typed in value will be the one submitted for unblacklisting,
which may not actually be blacklisted (due to "is_blacklisted" flag
being a computed field and it not having a chance to re-compute to hide
the button).
3. If someone changes values in the blacklist, then someone who already
has a form open will not see icon disappear until something triggers a
re-compute of the "phone_sanitized_blacklisted" flag (this was already the
case with the icon, but now a user may try to unblacklist a value that is
already unblacklisted.)
4. Since the icon needs to be visible by everyone to indicate whether or
not a phone/email is blacklisted, users without corresponding unblacklist
permissions will be able to click on the icon. When they click on it, they
will be informed they do not have permission to unblacklist. A wizard was
determined to be the best way to implement this unblacklisting for the
following reasons:
- A "Unblacklisting Reason" is needed and will not be stored as a field.
- A field widget is unable to do this due to security settings +
inability to refresh view after unblacklisting with a
"Unblacklisting Reason" without wiping unsaved changes.
Additionally, to better align with GDPR, the corresponding form view for
the phone/email blacklist has been updated to use the same wizard to
track "Reason for unblacklisting". Unfortunately there is no
straightforward way to prevent direct "Archive" action, so users are
still able to bypass unblacklisting without being asked for a "reason
for unblacklisting".
Supports task: 2117635
Upgrade PR: odoo/upgrade#939
COM PR: odoo/odoo#45315
Minor UX tweaks for more consistent and correct wording, visualization,
and editing ability for mass_mailing and mass_mailing_sms. Specifically:
- Fix all "This email is blacklisted for mass mailing" => ".. mass
mailings" typos
- Make phone blacklist not editable (to align w/ email blacklist)
- Add "Archived" ribbon to phone and email blacklist
- Update menu items and actions
- "Phone Blacklist" => "Blacklisted Phone Numbers"
- "Blacklist" => "BLacklisted Email Addresses"
Supports task: 2117635
PURPOSE
Remove dead views to clean dead records
SPECIFICATIONS
Find unused views and remove them, notably specific views that are not used
anymore because generic one is always taken. Notably
* view_partner_short_form: a short form view on partner that is not used
anywhere anymore. Indeed it has a priority of 2 whereas default form view
has a priority of 1 (lower better). It is not referenced in actions
anymore. It is therefore dead.
LINKS
Task ID 2196317 (Social/Marketing specific)
Purpose of this task is to prevent users from setting portal users on
internal documents by mistake, and preventing noise and performance
issues resulting from loading all the portal users in those fields.
This commit fixes internal many2x fields to res.users which are now
restricted to internal users by setting domain (share=false) on form view.
closesodoo/odoo#47553
Taskid: 2172779
Related: https://github.com/odoo/enterprise/pull/9204
Related: odoo/enterprise#9204
Closes: #47553
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Adaptation of the code throughout all modules to properly instantiate the newly
refactored control panel and update it accordingly.
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
PURPOSE
When incoming emails bounce due to alias security bounce email is quite
generic. Purpose of this task is to ease its customization and update.
SPECIFICATIONS
In order to improve the flexibility of alias, add a customizable html field
on the alias model. This html content will be send as bounce email core content
in case of bounced/unauthorized mail received for this alias,
Obviously it has no effect on 'everyone' security setting as no email will
bounce due to that issue.
If it is not set a default generic mail will be send depending on security
setting. It allows to keep void html fields when no specific bounce content
is required
In HR, an old template allowing some light customization for employee based
security option is removed as it is completely replaced by the new feature.
Also add references message-id of the mail received to the answer so that
threads are correctly set.
LINKS
Task ID 2126509
Swapnesh Shah