https://github.com/odoo/odoo/pull/110188 introduced a change in the TagsList
component, making the className prop be used in the parent tag rather than the
image tag. This change makes sense as most times you want to add classes to the
root element in the component. However, in calendar, we used className to style
the image tag, to allow showing the calendar attendee status for an event. This
commit introduces the imageClass property that should be passed in the tags
prop. Therefore, tags list will now have both className and imageClass, making
it possible to style both tags.
task-3277079
closesodoo/odoo#118781
Signed-off-by: Arnaud Joset <arj@odoo.com>
The `read_group` of `calendar.event` sends a danger notification when
the user groups by any field in the list view. It is because the
security reenforcement done in 2c0b3ab670168a155b3974d5a5b39aa1f1df3452
is too strict. It checks all `fields`, even the ones that are filtered
out by the `read_group` (`fields` without aggregation specification
nor `group_operator`).
closesodoo/odoo#119459
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit replaces a closing </xpath> with a </div>, and also prevents some
potential issues with class overrides for the div.
closesodoo/odoo#119196
Signed-off-by: Arnaud Joset <arj@odoo.com>
* = bus, calendar, crm_livechat, hr, hr_holidays, im_livechat, mail_bot,
mass_mailing, privacy_lookup, test_discuss_full, test_mail,
test_mail_full, website_crm_livechat, website_livechat, base
In preparation of splitting discuss and mail modules.
Part of task-3265211
closesodoo/odoo#118354
Related: odoo/upgrade#4553
Related: odoo/enterprise#39661
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = base_geolocalize, calendar, website_crm_partner_assign
Oversight of discuss refactoring. Code is restored into bus module as it
does not depend on any mail or discuss feature.
closesodoo/odoo#119243
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
Issue:
------
It is possible to create recurring events
that are in the same DST period.
Unfortunately, the basic event is sometimes duplicated
Cause:
------
The cause comes from the Daylight Saving Time (DST).
With the base event, we create a recurrence.
This recurrence will create all the events
of the recurrence.
To achieve this, with the basic event, we create all the ranges.
Then, we compare these ranges to remove those which already have
events.
Logically, we must reconcile the first range with the base event.
Sometimes the range of the base event and the first range
calculated to generate the occurrences do not match.
The consequence is the creation of a new event.
The cause of this problem is that we go back too far to find
the starting date of the period from which we will generate the ranges.
For example, in the case of a recurrence with a frequency of `MONTHLY`,
we will take the first date of the month.
And if we are in the month when the DST changes,
we will have the problem.
Solution:
---------
The solution is not to go back
if we encounter a difference in the DSTs
between the starting date of the base event
and the starting date for generating the ranges.
opw-3143680
closesodoo/odoo#119073
X-original-commit: 065dd4a2548ff0da6cf23a7ac62321ce99500d35
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
This commit consists of a full rework of the quick create form in the calendar
view, so that it shows more options to the user rather than only the name of
the event. To accomplish this, we added a new attribute on the calendar view
with the id of the quick create form view to be used. This allows us to have
a custom view to be shown on quick create.
task-3129030
closesodoo/odoo#114827
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
The reposition() method got a new parameter in #116499.
Many2ManyExpandable now passes the necessary argument to reposition().
closesodoo/odoo#118459
Signed-off-by: Arnaud Joset <arj@odoo.com>
Calendar popovers are now easier to read and navigate.
If an event contains a lot of information, its popover now grows tall
instead of wide.
In case of more than a few attendees, the widget shows a summary and
allows the user to expand the full list.
The displayed total number of attendees is now accurate, without the
default field limit.
task-2685440
closesodoo/odoo#112114
Signed-off-by: Arnaud Joset <arj@odoo.com>
Before this commit, the field node id (`field_id`) uses the field name
for the first occurrence on the arch, and add an underscore and a number
for the rest of the occurrences. This can create inconsistencies when
sombody assumes that the field_id is equal to the name, and don't take
into account the possibility of multiple occurrences.
Now, a unique id is created since the first occurrence, this remove all
ambiguity between the id and the name.
Part-of task-id 3179751
closesodoo/odoo#117799
Related: odoo/enterprise#39511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Changing end time for recurrent event will generate an error.
steps to reproduce the error:
1- Create an event in the calendar app with recurrence on
2- Save and close
3- Edit this event again and select change all events at the top
4- Change the ending time
The error was happening because the wrong key was accessed in a
dictionary
opw-3236432
closesodoo/odoo#118087
X-original-commit: 97f51b24da5db1a0217121aae583a9c1d715adc4
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
This commit fixes the components destructuration for the
AttendeeCalendarYearRenderer extends.
closesodoo/odoo#117845
X-original-commit: 340e9c2416537fc2e46a914e6038e5233dd876b6
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
On a calendar event, the 'free' option does not hide the element.
So that the user doesn't expect this behavior,
you have to modify its description.
opw-3047999
closesodoo/odoo#117654
X-original-commit: ecc850f4df1151a793d36fdd58621665a6e1a414
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
After https://github.com/odoo/odoo/pull/102967, a readonly="1" was added in the
videocall_location field. This forces the field to be readonly instead of
taking into account the readonly domain set in the attrs.
closesodoo/odoo#117214
X-original-commit: 459d5d75edafc2f8796006308e15940889c7dcb6
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
In case the videocall_location was a relative URL, the link wouldn't work
properly. This commit fixes this by converting all URLs to absolute
automatically. Note that this only works for http and https protocols. If
using proprietary schemes such as :skype is desired, this implementation
should be done in the respective module.
X-original-commit: 16fb60e193d0c79333d95ef2f31f0ec01830571f
Part-of: odoo/odoo#117214
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a personal calendar filter
record.
Set the on_delete attribute to 'cascade' as the record is not
of any usage without the user anyway.
Taskid: 3222941
Part-of: odoo/odoo#114656
This PR change the delete button in the attendee calendar if the
event is recurrent.
If the event is recurrent, a wizard pop up to ask if you
wish to remove :
- The selected event
- The selected event and the following
- All the event in the recurrence
task-id : 3148011
closesodoo/odoo#113024
Signed-off-by: Arnaud Joset <arj@odoo.com>
Steps to reproduce:
-Go to calendar
-Change the view to see the whole month.
-Watch every meeting we have.
Issue:
We are missing the starting hour for the meetings that we had working on
previous versions.
Solution:
Added proper way to display the hour to the
`calendar.AttendeeCalendarCommonRenderer.event` template.
opw-3119858
closesodoo/odoo#114251
X-original-commit: 90020976ab2a0e6a35ab4624ff227c30edc8d249
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
When following recurring meeting are imported through google calendar
synchronisation, it happens that a meeting get unexpectedly
duplicated in Odoo, what will in turn duplicate the event on google
and send invitations to all the existing attendees.
As calendar.recurrence.calendar_event_ids is a One2many field,
the update using self was setting the base_event_id's recurrence_id
field to the last record of self recordset. Due to this, the event
will not be considered to filter out the existing_ranges in
calendar.recurrence._reconcile_events function.
Therefore, a calendar.event will in turn be created using the same
start and end datetime as the base_event_id of the calendar.recurrence.
OPW-3143680
closesodoo/odoo#114392
X-original-commit: d1587758ac642b0181e660ea48222385d01098e3
Signed-off-by: Arnaud Joset <arj@odoo.com>
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
The goal is to be able to use Query objects for both subqueries and
known ids tuples. This provides a single API for injecting either a
subquery or its resulting ids into another query.
Part-of: odoo/odoo#112126
Before this commit, the widget's description was stored on the
component and this component was then registered.
Now, an object describing the widget is used on registration the same way
as it is done for views since b828cfc.
This split the component's description (props, template, ...) of
the widget's description ( component, extractProps, ...) and makes
it clearer.
We did the same thing for fields in 9f4622492c
Part of task: 3179751
closesodoo/odoo#112962
Related: odoo/enterprise#37215
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Removing the async header from the setup() function because this function is not entirely async, and inserting it alongside an onWillStart hook to be awaited before rendering the component.
closesodoo/odoo#111831
Task: 3141281
X-original-commit: 295f04b3496763cfef5237ff4b1f40df232371a7
Signed-off-by: Arnaud Joset <arj@odoo.com>
This PR change generic calendar view to make it behave more like
google calendar.
These changes includes :
- Scss rules for small event(<15 minutes) so that the title is always readable.
On top of that, the top border of a darker color has been removed
for these even to allow more space.
- Event longer than 24h are now shown in the all day column independent
of their 'allday' status
- Time is now added in the event description, if the event is
shorter than 30 minutes, only the start time is displayed at the end
of the line.
If the event is longer, the start time and end time are displayed
on a new line.
task-id : 3114155
closesodoo/odoo#109736
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Method 'message_notify' is a simplified version of 'message_post' to use
to notify people of something, without posting on a document. It creates
a "user notification", a specific kind of message.
In this commit we make 'message_notify' process attachments like posting
does. That way the API is more similar between those two methods. Moreover
it allows to give 'attachments' to notify. Those are then transformed into
real 'attachment_ids' and converted if they come from the composer.
That way the mail composer can be used in notification mode with attachments.
This happens notably when using a template on a record that does not inherit
from MailThread. It is a classic usage of 'message_notify' which allows
notifying on documents that have no chatter, notably technical or admin
oriented models.
Followup of odoo/odoo#99482
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#107356
This commit fixes a function call that was trying to call on `this`
while the function is imported and not assigned to the object.
closesodoo/odoo#111138
X-original-commit: b01be3ea8f77d42d5162648a078f09328491c102
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Overriding the _compute_field_value in order to only prefetch the currently requested field
opw-3141262
closesodoo/odoo#110489
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
*: calendar, im_livechat, mail.
Before this commit, the legacy session was a dependency for the bus
service. This was problematic since one would need to import a bunch
of legacy files to fulfill this dependency in order to use it.
This commit removes this dependency. In order to pass parameters to
the `bus_service`, the `bus_parameters` service is now used.
closesodoo/odoo#110247
Related: odoo/enterprise#35974
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
If there was an issue an the lastcall value for the calendar cron
the cron would raise an error. This commit give a default value to
the lastcall equal to one week ago.
task-id : 3102295
closesodoo/odoo#110154
X-original-commit: e0aa273104ce576cd2746340f0e2c5c4af4a86bd
Signed-off-by: Arnaud Joset <arj@odoo.com>
Currently when using the composer to create a mass mailing emails are sent
directly, unless scheduled date is in the future.
With this commit it is now controllable through a field like what has been
done on SMS composer. Its default behavior is the same as before
* posting on a monorecord: force send notification emails;
* posting on multirecords: use the queue (force_send=False parameter given
to message_post and propagated to _notify_thread);
* mass mailing: use force send to send emails directly;
Usage of mail_notify_force_send context key is also removed when possible
as it is a standard parameter of posting API.
Task-3132710 (Mail: Configurable composer)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
Before this commit, when somebody updated the status of recurrent meeting
the dialog was crashing because the component was destroyed and the orm call
could not be done.
X-original-commit: 544b7d9bf805f7860dd318293964cf822b05e0b9
Part-of: odoo/odoo#110133
Leonardo Pavan Rocha