This commit introduces a new optional feature in the chatter.
Users can request translation from the Google Cloud Translation API.
Documentation: <https://cloud.google.com/translate/docs#docs>
Adding the key in settings will instantly enable the feature for all
users of the database and consumption is not measured nor limited
by Odoo as it is natively supported using the Google Cloud Console.
Translation values are stored in the database to reduce cost as
much as possible. Therefore, translation values are automatically
garbage collected every 2 weeks to prevent database pollution.
Task-3338165
closesodoo/odoo#126555
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
New fa-bell icon to manage notifications according to that channel only
Options:
Mute (+choose time period):
No longer see the unread status: the bold text disappears and the channel name fades out.
As if you are not a channel member anymore.
Receive messages but without sound + only need action counter (grayed).
Add a crossed-out bell icon next to the channel or user name to indicate that the channel is muted
All messages: all messages sound + need action counter
@Mentions: only mention sounds + need action counter
Nothing (Discord-like): No sound + need action counter
By default: all messages
task-3328665
closesodoo/odoo#136405
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, if all reactions are deleted from reactions menu, the menu remains open. This commit force it close in case of having no reactions.
closesodoo/odoo#139632
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
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
Now that alias domains are used in Odoo codebase there is no usage anymore
for the old config parameters. So long and thanks for all the fish !
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
Update settings to configure your company's current alias domain instead
of the global 'alias.catchall.domain' configuration parameter. As domain
configuration is globally done per company, this is now a related on the
company. Advanced configuration and management can still be done manually
in settings.
Field 'external_email_server_default' triggering display of mail configuration
is moved to mail. It is defined in 'base_setup' but used only in mail hence
moving the field to be coherent.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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: MAIL.MAIL
Update MailMail to use alias domains. Notably "Return-Path" headers are
now computed based on alias domain when possible, using the recently added
fields on 'mail.message' model for that purpose. Fallback is to use current
company's bounce email when mail_mail creation is done outside of classic
mail flows or without that information.
SPECIFICATIONS: IR.MAIL.SERVER
Update IrMailServer and low-level stack to use alias domains. This has an
impact notably on default values computation for from and bounce emails
* '_get_default_bounce_address' is called when there is no 'Return-Path'
given. Most classic mail flows will set it according to current record
company / alias domain. Fallback when not set is to fallback on current
company's bounce email, computed based on its alias domain;
* '_get_default_from_address' is used in two use cases
* computing a default 'email_from' for outgoing emails when it is not set.
In most classic mail flows it is set based on current user's email. If
not set fallback on current company's notification emails is considered
as a safe bet, replacing the global configuration parameter;
* overriding the 'email_from' of emails that are considered spoofing the
mail server, allowing to wrap the sending into a 'notifications@domain'
generic sender. For those we should try to keep record's information as
it may be called in classic mail flows;
* '_get_default_from_filter' is added in base and overridden in mail to
either use 'mail.default.from_filter' ICP, or use the one defined on
the alias domain. Supporting both is still an option, as its behavior
is implemented for basic email sending, without mail being available.
Those methods are updated to try to support multi domains / multi company
setup. However as those defaults are located ar ir.mail_server level it is
not always easy to have complete environment information, hence fallbacking
on current company's parameters when no better information is provided.
A test about 'mail.default.from' is removed, as it was testing a default_from
outside of catchall domain. It is not possible anymore as default_from is now
part of domain definition. As multi domains is supported, no need to support
exotic configuration like that.
SPECIFICATIONS: FROM MAIL.MAIL TO OUTGOING EMAILS
When sending emails based on MailMail, we now prepares sending groups based
on MailServer, email_from, but also alias domain to which the mail belongs to.
Information about alias domain (e.g. notifications email based on default_from
and bounce email) is propagated to low-level email preparation methods. It
uses the context as it is the easiest way to propagate information to that
level without hacking too much models or calls.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
Store 'company_id' and 'alias_domain_id' on 'mail.message' model. It helps
knowing the environment that produced the message, notably
* for layouting: it will be used to improve company (and soon alias domain)
given for the email notification layout;
* for sending: it will be used to better compute mail-related values like
default from, return path, ...
When logging, those fields are kept false as anyway no notification is sent.
No need to fetch extra information.
Some sudo() are included in post_* methods, as portal may go through the
posting method, see 'test_portal_acls' in test_message_post.py file.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
Make mail gateway support alias domains instead of relying on configuration
parameters. This implies the following changes
* destination alias check is now based on full email by default. Previously
only left-part of aliases were checked. Optionally an allowed list of
domains could be additionally checked. Default from now on is to check
the complete email e.g. 'sales@mydomain.com' != 'sales@mydomain.in';
* detection of direct write to catchall implies checking all domains
catchall emails;
* detection of write to bounce implies checking all domains bounce emails;
* when having to send bounce emails using the bounce alias as mailer-daemon,
find the bounce email from the relevant company;
However we have to ease transition from the old ICP-based model used since
ages to the new domain-based model. Notably a common usage of mail gateways
is to do mail forwarding e.g. forward mail from domainA to domainB without
rewriting destination. It means that e.g. sales@mail.domainA should be
considered as a valid alias equivalent to sales@mail.domainB. This was
working due to left-part only check of destination aliases. In order to
keep this setup working after migration a flag is added on aliases allowing
to keep the detection of those aliases based only on local parts.
In summary: When searching for aliases, mailgateway now either checks for
exact email, either for matching local parts when the flag is active. This
is not the default behavior, as we want a stricter comparison of emails by
default but it will be the default behavior at **migration time**.
The 'mail.catchall.domain.allowed' configuration parameter is kept. It is
used only for left-part check aliases, allowing to limit the scope of the
match.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
When computing reply-to of message or documents, classify them per company
and use alias domains when computing catchall emails. Reply-to computation
based on alias is also simplified as aliases are now complete and use
alias domains. They do not depend on configuration parameters anymore.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
Currently alias search is done only on 'alias_name' field. Now that alias
domains can be multiple we have to be able to search on complete alias
email definition e.g. when checking destination aliases of incoming emails
in mail gateway.
We add a new 'alias_full_name' field that is computed based on alias_name
and alias_domain_id.name. It is stored so that search is possible on it.
Allow to search on 'alias_full_name' from the 'mail.alias.mixin(.optional)'
by making 'alias_email' field searchable, based on 'alias_full_name'.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
Now that alias domains are multiple and can be linked to companies it is
easy to end up with configuration where an alias is using a domain of
CompanyA while the owner and/or target record belongs to CompanyB. We
want to avoid that situation and strengthen company separation.
When changing alias domain of an alias check that it is not used in another
company than the one define on
* the owner record (using owner fields like the 'project.project' for
'project.task' creating aliases);
* the target record (using update fields like the 'mail.group' for group
aliases that routes emails to a specific group);
If the new alias domain is linked to a company that is different from the
company of any related record, raise an error as it could lead to invalid
multi-company setup and record creation.
If the new alias domain is different from the company domain but is not
used in any company it is a valid configuration. It is just flexibility
offered by multi-domains aliases.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
As 'alias_domain' is now dynamic and not based on a configuration parameter
it makes sense to be able to change it when having several alias domain.
We now allow writing on 'alias_domain_id' in 'mail.alias.mixin(.optional)'.
Users may now change the alias domain of the alias coming with the mixin
when they have write access on the record.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
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
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 a new 'mail.alias.domain' model storing information previously stored
as a unique value in 'mail.catchall.domain' configuration parameter. Domains
are not completely linked to companies, allowing to have a mono-domain MC
setup, or mono-company multi-domain setup.
A main email domain is present on companies for all default domain computation
when being in that company while keeping flexibility of having other domains
defined.
Now that a new 'mail.alias.domain' model exists we move bounce and catchall
aliases definition directly on this model. Update related computation on
company model. Default_from is also moved on this model, allowing an higher
level default from computation for mail servers when having knowledge of
alias domain environment. Filtering configuration based on default_from_filter
is kept as an ICP as it is mainly used for odoo-bin with smtp-host.
Usage of 'mail.catchall.domain' will soon be completely removed to be replaced
by proposed company-based email alias domain usage.
Constraints are added so that each bounce and catchall defined on domains
do not clash with existing aliases. Sanitize of bounce and catchall is also
performed to ensure they make valid emails. This matches previous behavior
of ICP parameters. Domain name is also sanitized like alias names.
Currently only base modeling and computation is done. Their usage is about to
be gradually added in mail stack.
LINKS
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Composer tests now use the multi-company enabled model by default, allowing to
test company-dependent behavior. This has no impact on current tests, as there
is no company-dependent fields on composer model, and all tests are anyway
run into the main company (except multi-company specific tests, suffixed
by '_mc' generally).
We therefore also add some multi-company oriented tests to check notably
return-path or environment companies in various scenarios. Go until the SMTP
generation to test mail server choice, smtp_from and filtering, notifications
email.
Followup of odoo/odoo#136318 and odoo/odoo@3ffa1a0611 notably.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
Perform some code cleanup not really related to other commits notably in mail
gateway where alias domains will have some impact. Extract some processing
in sub-methods, allowing to better distinguish code purpose. This implies
notably some checks in mail gateway (write to bounce or catchall detection).
In mail.message, reorder some fields according to their usage, just to keep
definitions / section.
Also improve docstrings and/or fix some of them.
This is mainly a "reduce diff in other commits" commit. No change should occur
with this commit.
Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
This may have an impact when trying to find an outgoing mail server based
on from and filter, as first match wins when checking matching filter on a
bunch of mail servers.
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
When composer runs in 'rendering' mode, it is often based on a mail.template
record that gives information about recipients. When having no template
default recipients are added to be sure to contact 'intended people'.
When rewriting code in 16.2, support of batch-comment was added in addition to
mass mailing. Result is that now default recipients are also computed when
posting in batch. However when posting we consider recipients are already set
on records using followers. Adding default recipients to avoid dummy emails
is present mainly for the mass mailing mode.
Followup of odoo/odoo#107356
Prepares Task-36879 (Mail: Support Multi Domains Aliases)
Part-of: odoo/odoo#76734
To reproduce:
* Populate mail.message as medium or more
* Open odoo and click the messaging menu
* The messaging menu take an unreasonable amount of time to open.
This PR cache the threads getter to avoid unnecessary computations
task-3551625
closesodoo/odoo#139519
X-original-commit: aa92a630d5146b7a4ee5eb5d09bb6db04c1ba146
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit adds new optional props to the Message and Thread Components:
closeThread, openThread, avatarPlaceholder and showDates.
* `closeThread` is a function that enables the user to close an active comment
thread.
* `openThread` is a function that reopens a previously closed thread.
* `avatarPlaceholder` is a boolean that will add an avatar placeholder
(fa-user icon) when needed. For example when using Knowledge via the portal.
* `showDates` enables us to hide the dates showed inside the Thread component,
it may not be useful for certain comment threads.
We also added a button inside the actionBox in the Message Component and it is
only rendered if we are on the first message of the thread.
The button can trigger either of the new function props depending on what is
provided to the component.
task-3317056
closesodoo/odoo#127380
Related: odoo/enterprise#41951
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Back-port test with `contains` from `master` and specify text present
on command before clicking it.
runbot-24981
closesodoo/odoo#138087
X-original-commit: ddc9da828ad338678bfa6e3b44461f87683b828f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = bus, crm_livechat, hr, mail_bot, test_discuss_full, test_mail,
website_livechat
Now that livechat uses guest, we can write proper ACL for channel and
channel member to check if the current user/guest is a member.
This allows removing most sudo in code and to simplify search domains.
Remaining sudo in discuss folder have been reviewed and commented.
task-3394829
closesodoo/odoo#138330
Related: odoo/upgrade#5295
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Also impacts mass_mailing_sms, test_mail_sms,
test_mass_mailing
This PR adds support to receive sms delivery reports.
Before this PR, an SMS was considered 'sent' when successfully
handled by the third party. The user couldn't know if/when an
SMS was actually sent for delivery or delivered to the
recipient's device.
This was similar to the behavior for emails as delivery reports
are not commonly used (and not supported in Odoo).
With this work, the SMS `pending` state is introduced in mail,
mass_mailing, sms and mass_mailing_sms contexts although only fully
used in the latter two modules (+tests of course).
Because of the huge cost related to upgrading very large existing
databases, the following compromises were made:
1. An email and sms notification/trace SENT means DELIVERED.
Those that are sent but NOT DELIVERED are PENDING.
The difference between email and sms traces reinforced with this PR
is that an email sent will be counted as "sent" ~ "delivered"
unless an error is returned for emails while for SMS it can only be
reached if a delivery report is received.
2. The Link between an SMS uuid (shared with trusted parties) and
the tracking records (notifications or traces) is done via an
explicit relationship table (sms_tracker) instead of via a new field.
This however allowed to nicely concentrate the state update logic.
A `process` state is added to represent an intermediate
step in the sending process, such as held at IAP for SMS.
A few adjustments are also included to update for IAP api v3.
Also, adapts and includes new tests.
Task-2560666
Part-of: odoo/odoo#133392
As a step to simplify model insert from python. All data are
formatted in a way to make data insert trivial in JS models.
closesodoo/odoo#138760
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
- `__invs__`/`RecordInverses` have been renamed to
`__uses__`/`RecordUses`, so that it's more clearly separated
from inverse fields. While they are some overlap in concepts,
they require different datastructures so it's best to keep
different implementations for the time being.
- `list.__addInverse__(r)`/`list.__deleteInverse__(r)` have been
replaced to `r.__uses__.add(list)`/`r.__uses__.delete(list)`.
Again change of wording "inverse" to "uses" like before, but
also it feels more natural for uses as low-level concept to
expose function on object where the uses are tracked, i.e. on
the record, rather than functions in RecordList like before.
- Remove useless `__` prefix/suffix and/or only keep `_` prefix
for `store` and `__addNoInv`/`__deleteNoInv`, for improved
code readability
- Renamed `__list__` and `__map__` datastructures to `data`,
again for improved code readability.
- Replaced some `Map<>` to `Object<>`, so that accessors are
easier to read in code with `[]` rather than `.set()`/`.get()`,
especially with code formatter that produces more LOCs than
necessary with the latter. Note that the affected dict,
`__computes__` and `__rels__` are set up at model and record
setup, so they do not change shape after that, so using Object
should not be a performance issue.
Part-of: odoo/odoo#138760
Some test coverage on model with inverses, especially on deletion
that are not frequently functionally covered by tests.
To make test coverage on very specific on models and relational
fields with inverses, store service has been refactored so we can
test the store without Persona/Thread/Message models and all related
services and behaviours.
Part-of: odoo/odoo#138760
Name was hard to grasp what it means, when in practice it refers to
showing discuss failures in messaging menu. The "group" part just
refers to a failure being conceptually uniquely defined so that it
sometimes group notifications together as a single failure entry
in the messaging menu.
This rename will help simplifying insert flow with this model.
[REF] mail: slightly simplify Notification.insert()
Format `persona` so it can be immediately inserted in JS model.
[REF] mail: simply Notification/Failure.insert
[REF] mail: introduce computed fields on discuss models
Some models have no concept in server, so the formatted data require
specific handling to make some client-side specific models. This is
notably the case with `Failure` model, which is used to group
failure notifications per model for the specific showing in UI.
In order to simplify update so they consists to simply adding data
from server, these models should be inserted automatically depending
on changes from inserted data. Since these models come from
relational fields that must be computed outside of server data, we
add support to computed fields: such relational fields can have their
value automatically computed based on the state of the current
record.
[REF] mail: remove Record.atomically and Record.onChange
These were added to reactive seeing intermediate state in models,
which were caused by `RecordList.sort()`.
This commit removes them and adapt specifically `RecordList.sort()`
so intermediate states during sort is not exposed in the actual
value of the many field.
Part-of: odoo/odoo#138760
Fixes a large number of cases where strings are translated then
formatted, instead of letting `_()` do the formatting internally,
which allows it to recover from incorrect translations (missing,
broken, or extra placeholders).
Also
- removes translation markers entirely when there's nothing to
translate e.g. `_("%s - %s")` is not useful
- fixes a few messes which lead to only partial translatability
(DRY is generally a bad idea when translations are involved, even
more so when you don't make the variable part translatable)
- fixes a few nearby issues noticed at the same time
- replaces a few `"%s"` by `%r`, which should automatically quote
strings relatively appropriately
- fixes translated strings which use `\` to escape a newline (in order
to fill-paragraph): `\` escapes only the newline, if the
continuation string is indented this results in a bunch of spaces
ending in the string to translate, which is pretty garbage for the
translator, using implicit concatenation works much better
Note: some of the updates revert f-string parameters to %, because
babel (2.9) apparently has trouble with f-strings and blows up trying
to extract them.
Not in scope:
Helping translators fix translatable strings e.g. any translation
string with more than one placeholder probably should use keyword
placeholders
- Provides more context / data to the translator to make sense of the
sentence.
- Allows reordering the translated terms, which can be necessary
depending on the sentence and language.
closesodoo/odoo#139314
Related: odoo/enterprise#49311
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, devices with the key-repeat feature turned on
would not work well with the push-to-talk feature.
This commit sets a minimum delay before a push-to-talk key is considered
released.
closesodoo/odoo#139396
X-original-commit: aced53322309898d060c082e3d009293123ffea0
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, an error occured when opening the discuss public
page as a non internal user. This is caused by a read rpc being done
while the user is not allowed to do it. This commit ensures this rpc
is only done when allowed.
Steps to reproduce the issue:
- Open Odoo with Mitchell Admin
- Go to a public channel
- Start a RTC call
- Join the channel as guest with the invitation link
- A pop up appears
closesodoo/odoo#139397
X-original-commit: c7e66f3878b451001dbe4e8e3cdd8ced9a8ed632
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
* = calendar,test_discuss_full, test_mail, test_mail_full
Methods can be downgraded to channel_info when called by RPC.
This increases the simplicity to use these methods in python.
closesodoo/odoo#139341
Related: odoo/enterprise#49326
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Significantly improves the usability and the result of the populate for
base models and channel/member/message.
- make populate of base models re-entrant
- adapt size to values that make sense:
- small shows something relevant, and can be quickly ran several times
- medium is fast enough to be usuable but big enough to highlight
performance issues
- large is... still not to be attempted
- avoid conflicting conditions that either make no sense or can lead to
crashes when populating the data or running the database
- better spread of data in channel/member/messages
closesodoo/odoo#139269
X-original-commit: 73a5e322f6e250569ee1942d678f8a4f87616bd7
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit reduces the size and avoid conflicts caused by
the embed live chat bundle: jquery, legacy libs...
At the same time, this commit fixes the emoji picker that was
wrongly positionned and scrolled up the page when opening.
Finally, this commit ensures the chat window is always at the
bottom of the screen.
opw-3539362
closesodoo/odoo#139261
X-original-commit: 1b29419e50343bfd723b41368ba38ce63b063d92
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
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
The system tray has been simplified:
- only one clickable area per activity group
- by default, a click on an activity group open the list view, except for some
model (ex.: journal entries, project, task, documents where the activity view
is opened). This can be defined per model using the _systray_view attribute on
the model.
- the clock icon providing access to the activity view has been removed. As it
is the only action, we also remove "actions" returned by systray_get_activities
in res_users.
- the KPIs are no longer clickable
The tests have been updated (for example, because we open the list view instead
of the kanban view) and one removed "activity menu widget: activity view icon"
as we only have one clickable area now and no more icons.
Task-3300854
Part-of: odoo/odoo#138135
We add the option to keep the completed activities to allow the user to keep
track of the past action, especially the uploaded files which are displayed
along the completed activities. This feature can be activated per activity
type and is disabled by default.
We also improve the activity view to give a better overview of what has been
done and what is still to be done and by whom.
We also add tests for those new features:
- check activity data for the views (server-side test)
* Details about the activity view improvements:
** Improvement of the column header:
- progressbar: previously, only visible activities were counted in the
progression bar. Now all are counted.
- activity counter: instead of displaying the total count (next to the
progression bar), we display now a ratio as 2 numbers (only if keep done is
enabled):
** Improvement of the activity cells:
- add assignees in activity cells of activity view (limit to 2 having the
activity with closest deadline, if more a + is displayed). Note: to avoid
spacing between avatar, we add the optional props noSpacing to the avatar
component.
- add done activity in activity cell popover
- increase by 50% the popover height
- display done activity cell in grey
- instead of displaying the activity count if greater than 1, we display a
ratio ongoing / activity count. Note: we don't display the denominator if all
activities are done or all are ongoing.
** Progress bar filter
The activity filter is slighly modified. Previously, when clicking on a color
of the progress bar, all cell with a different color where hidden (ex.: if we
were clicking on the green area to filter planned activities, red cell which
represents overdue activities were hidden even if there was also a planned
activities for this record and activity type). Now we also display cells with
other "color" if there exist for that record and that type an activity
corresponding to the filtered "color".
Technical note: mail_activity.get_activity_data returns now for the activity
types a list of dictionary instead of a list of list. This simplifies the
reading as we can now uses name instead of index (type[1] becomes type.name
for example).
Task-3300854
Part-of: odoo/odoo#138135
Steps to reproduce:
- install `hr_homeworking`
- connect as Mitchell Admin
- make a private chat with Marc Demo
- `@mention` Marc Demo
=> crash (cannot read name of undefined (reading persona))
This happens because a spread record was inserted in model,
and in this scenario the record list in data can be the exact same
as the record list used in the model. The internal code of assigning
a many list is to `clear()` and then `push()` from data, but if the
data mutates from the `clear()`, then the `push()` does nothing and
the resulting relation is emptied.
This commit fixes the issue by keeping a copy of collection before
`clear()` so that push applies on original data that is intended by
insert.
This commit also adapt code in hr to not use spread record to insert
Persona. While it works with the fix, it's simpler to just update the
appropriate field and also more efficient, because spread a record
has to process all fields as an insert, wasting CPU time.
closesodoo/odoo#139143
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, some relational fields in records had
the command `[["ADD.noinv"]]` as value. This is a command and
it should have been feed by a model (pre)insert, but the
resulting value of the field should never be a command: it's
always a RecordList (one-size RecordList when a Record.one).
This happens because the RecordList tracks the owner, i.e. the
record that owns the RecordList value in the relation, but the
owner was not properly proxified.
Indeed, all models are wrapped in a proxy, so that they managed
delete/get/assign on relational fields. To feed command like
"ADD.noinv". the receiver MUST be the proxy in order to be feed
properly, otherwise the assignment with command sets the command
as the actual value on the field. This is precisely what happens.
This commit fixes the issue by properly passing the proxified owner
to the RecordList, so that `ADD.noinv` command works as expected.
---------------
This changes unveiled some mishandling of the inverse, notably
during deletion of the record: the deletion must not insert record
with `ADD.noinv`, otherwise the inverse record is added, and this
is prone to infinite loops. To properly managed deletion, a new
internal command `DELETE.noinv` is used to delete the record without
syncing the inverse field, again to prevent infinite loops like with
`ADD.noinv`.
Part-of: odoo/odoo#139143
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>
Killian Frappart