Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Currently template rendering in calendar returns a tuple instead of real
results. This is a followup of 7159f657a0 and probably linked to cleaning
done in template while working on new calendar.
This commit makes calendar correctly use the rendering API.
Spotted when working on task ID 2238597
- In a res.partner;
- Schedule activity;
- Choose 'meeting' as activity;
- Set a summary : 'test summary';
- Open Calendar;
- Chose a date and an hour;
- Edit the meeting;
- Add a description with a line break;
- Save the meeting;
- open the res.partner view;
Before this commit, the note on the planned activity lack the line
break.
Now, the note in the planned activity has the same output as the
description of the calendar meeting.
opw-2236838
closesodoo/odoo#50226
X-original-commit: 2e9cc92fb45f9328c45520275ab11c7a486a2590
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
- Go to the calendar list view
- Click on 'Create'
- Tick 'All Day'
- Set a start date
The end date is set to the day before.
This happens because in this case, the default duration is zero.
opw-2236766
closesodoo/odoo#49682
X-original-commit: 0b6ae3ed4ff20898cd88b97a644190b20f11cf8f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit b0f1086 forgot that `read_group` supports
aggregation functions (e.g. "start:month") and that
`groupby` could be a single field or a list of fields.
+ add some tests
Task 2238100
closesodoo/odoo#49550
Related: odoo/enterprise#9878
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit refactors calendar synchronization between Odoo and Google after the
main calendar application refactoring.
This refactoring takes advantage of two new features from the Google API:
- New way of synchronizing resources efficiently[1]
Incremental sync is performed repeatedly and updates Odoo with all the changes that
happened ever since the previous sync. Each time, Odoo provides the previous sync
token it obtained from Google and stores the new sync token from the response.
- Event metadata[2]
Ability to set hidden key-value pairs with an event, called extended properties.
These extended properties are used to store the related odoo event id and the Odoo
owner id (see known limitations)
Known limitations
=================
- Let A and B be two new users (no tokens available). A creates an event in Odoo and
invites B. A is the owner of the event (user_id). Now B authenticates to his Google Calendar
account and synchronizes his calendar. We cannot send the event to A's calendar since we
don't have any access to his Google Calendar. Hence the event his sent to B's calendar.
This leads to data de-synchronisation: The owner is A in Odoo but B in Google.
The "real" owner (user A) is stored in the Google event's metadata to be able to
reconcile the owner for following synchronizations.
- Let A and B be two users of Odoo and Google Calendar. And let the Google Calendar of B
be private (e.g. if A creates an event in Google Calendar and invites B, B won't see the
event in his calendar). If A creates an event in Odoo and invites B. The event is synced
to Google Calendar of A. Now B can see the event in Odoo but he can't see it in his
Google Calendar.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
[1] https://developers.google.com/calendar/v3/sync
[2] https://developers.google.com/calendar/extended-properties
The fields `start_datetime` and `stop_datetime` are the exact miror
of fields `start` and `stop` respectively.
The field `display_start` is never used.
Hence those fields are removed.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit removes the `state` field of calendar events.
The field was not displayed on any view and never used by any business code.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Some fields of a calendar event are private.
The previous implementation was deleted while refactoring recurring events.
This commit cleanly re-implements the feature.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
This commit refactors the event attendees and notifications according
to the recurring event refactoring.
Some (very) basic reminder tests are also added.
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
TL;DR A bit of magic and ... Pouf ... all virtual events are now real records.
Purpose
=======
The current implementation of recurring events uses "virtual events" to represents all
events in the recurrence. Only one event is stored in the database. All other events are
dynamically built and sent to the web client which sees them as real records.
This implementation is old, difficult to read (6 years of changes and bug fixes) and
has become more and more difficult to maintain.
A fresh start would be welcome.
Specification
=============
When creating a recurring event, a `calendar.recurrence.rule` record should be created.
This model holds the rrule configuration and is responsible to manage events that result
from the rrule.
When a new recurrence is created, all resulting events are also created (stored in the
database). No more virtual events.
To avoid an explosion of events, a maximum of 720 events is created. With 720 events,
a daily recurrence lasts for 2 years and a weekly recurrence lasts for 15 years.
This strategy is used by Google Calendar and seems acceptable in most cases.
A cron job could eventually be introduced to generated more events as the end comes.
This allows to introduce an new rrule end type: 'Forever'. This is actually a shortcut
to create a recurrence running for 720 events.
Inspired by Google Calendar, new possibilities are introduced when modifying a recurring
event (e.g. change the name, add an attendee):
- Modify only this particular event (the event is still part of the recurrence)
- Modify this and following events (events are still in the same recurrence)
- Modify all events
In a similar way, when updating the rrule of an event (e.g. from every Monday to every
Tuesday), the user can choose to:
- Modify this and following events: the recurrence is split. The first part remains
unchanged but now ends when the second recurrence begins. The second parts is the
updated rrule.
- Modify only this particular event.
- Modify all events: Forbidden (same as Google Calendar)
Note: when events are "moved" because the rrule changed, the events are not actually
moved. They are unlinked and new events are created (See "Some design choices explained"
section).
Some design choices explained
=============================
Where to store the rrule?
-------------------------
Two options were considered.
1) Store the rrule on an event, each event of the recurrence having a Many2one
to the parent_id, aka the Master Event of the recurrence.
2) Store the rrule on another model: `calendar.recurrence.rule`. Each event in the
recurrence having a Many2one to the recurrence record.
Both options have pros & cons. But there is no clear winner.
However the actual business logic of handling the recurrence creation/update
would be the same.
Where the rrule configuration is stored is the only main difference between both options.
And this is probably the easiest part of implementing recurring events.
With that in mind, option 2) is chosen. It allows to clearly separate recurrence
logic from the events themselves. It is also the "correct" way of modeling data to avoid
many empty columns for most records.
Reusing events on rrule update
------------------------------
When an rrule is modified, events should also be updated.
In most cases, current events are unlinked and new events are created from scratch.
Only events exactly at the same time before and after the rrule update are kept.
Trying to reuse other events would require an obscure and arbitrary heuristic.
(Imagine an rrule every Monday that is changed to every Tuesday and every Friday.
What would you do?).
This implies that any change to a specific event (name change, attendee added, chatter
messages) is lost. This tradeoff seems acceptable as updating an rrule should not be
that frequent. Moreover, Google Calendar also works that way so why not Odoo?
Reusing events on events shifts
-------------------------------
On the calendar view, drag and drop an event to shift the entire recurrence.
One way to handle the recurrence shift is to apply the same timedelta to all events.
Now events are correctly positioned... except for events that were specifically
moved. Those outliers needs special handling.
This also introduces some behavior inconsistencies:
when an rrule is directly modified, events are not reused, but when the rrule is
modified by drag & dropping an event, events are reused. This option needs more code to
handle the shift and the behaviors are not consistent.
The chosen option is to find the rrule configuration from the dragged event (this is
easy) and update the recurrence with those new rrule values. This brings us back to
an rrule update (see above): code reusability yeah; one behavior to rule them all yeah.
One downside is that outliers are lost (but Google Calendar also works that way).
Task 2126717
PR #42031
PR Enterprise odoo/enterprise#8006
Issue
- Install Calendar, HR Recruitment & Studio
- Go into Calendar
- Create a recurring event
- Edit it with Studio
- Add a related field
- Select Applicant > Assigned
Traceback
Cause
Applicant > Assigned is a stored field.
Adding a stored field seems to triggers
something that recomputes all models
odoo/odoo:odoo/modules/registry.py@12.0#L307
Then it calls the _write method of models.py
which uses self.ids (which contains virtuals ids)
for a SQL query.
odoo/odoo:odoo/models.py@12.0#L3428
Solution
Avoid all the virtuals ids to be retrieved
when we have "update_custom_fields" in
the context.
OPW-2214170
closesodoo/odoo#48208
X-original-commit: 112f976eb193020c093068fd30a004be3f5e9254
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
Before this commit, when user attempts to edit or delete a private
event without being an attendee, it raises an access right error.
This commit disables edit and delete buttons in this case, in
addition to hide event details.
task-2151150
Closes https://github.com/odoo/odoo/pull/42569closesodoo/odoo#42569
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Steps to reproduce:
- install calendar
- create a recurring event with 0 repetitions
- save
Previous behavior:
raises an UserError, this would interrupt the sync with google calendar
Google calendar sometimes sets recurring events to 0 repetitions
once they are done recurring
Current behavior:
the event is handled like a punctual event but remains recurrent
initial commit: https://github.com/odoo/odoo/commit/ba727e15d2dc9a1325cd20527e2ccfe6f8bc63f0
opw-2185699
closesodoo/odoo#45947
X-original-commit: 5b63ddb4e03f34f015e7668c69108fb4a2badd08
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
Install Projects, documents, calendar, website, crm.
Under Settings enable "File Centralization"
Now go to Projects, enter in a Task, click on "schedule activity".
On the activity form under "Activity Type" choose Meeting, click on
"Open Calendar" button.
Choose a slot, edit the event, add a contact type individual, save
Error will popup.
This is caused by the whole flow of creating a new document for the
invitation.ics generated for the meetings which has to be sent via email
but get detected as an attachment to be sent into the document app as
well.
Disabling the document creation since it is not a relevant attachment
opw-2150770
closesodoo/odoo#43537
X-original-commit: 4e30db33938d4d740d847cfbc6a29b4013be964d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since commit 91560fae56f1cba0914, we are using sudo to write
calendar_last_notif_ack, but we need to update the real partner stored
in the context.
opw-2133566
closesodoo/odoo#41982
X-original-commit: 4d6416dbc82f07c91111457b503ccfc737f802c9
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
When the event is private and some other user going to
see the event at that time it was going to display the
archived ribbon because the active field was not in the list
of public fields(readable field).
so added an active field to the readable list so it will display the
propper archive ribbon on a private event.
Task-2144553
closes odoo/odoo#41589
Closes: #41157
X-original-commit: c1b89567ca3fdd6f4004389aad345ad3e52248c3
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Currently when other users view the private event of
another user it display the name of the private event as
'false' instead of 'busy' and onclick of event it generates
traceback.
so to fix it added display_name in condition of read because
the event name displayed in calendar view(previously name) is
replace by display_name in commit 369c20a99b
Task-2144553
Closes: #41157
X-original-commit: 1ec853751bd995449619585db8e17f582ba5e5bc
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
In order to be more explicit subtype parameter is renamed to subtype_xmlid.
It therefore clearly indicates it should be a valid subtype Xml ID. Support
of ill formatted Xml IDs is removed because there is no reason to try to
add some random prefix. Give something that exists or go to hell, punk !
LINKS
Task ID 2071556
PR #38692
From now on mail.mail is considered as a technical model. Indeed people should
not really manually craft mails by hand. Instead various functional flows
should either send mails, either craft mails based on some user input.
We therefore make mail restricted to admin users. Flows creating mail.mail
are updated to use sudo, and ensure it was done in a context that makes
sense to delegate this power to the user.
Task ID 1853147
PR #32243
Adapt calendar highlight option (that "highlight" event linked to the
record we come from) to current JS framework data structures.
note: this changeset also fixes the original `_compute_is_highlighted`
that was would trigger CacheMiss errors, and also adds back the CSS for
highlighting that was lost between 12.0 and 13.0 version.
opw-2131494
closes#40791closesodoo/odoo#41077
X-original-commit: da56e3e7036ecdb3905f4152778e853e080e0163
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When a calendar event is created with a duration of for example 20
minutes, the end time appears as the start time + 19 minutes.
Because of the rounding of the duration (20 minutes = 0.333... hours),
the end time is incorrectly set (xx:19:59.998...) then displayed. Since
the duration can only be set by the minute, we round it before computing
the end time.
opw-2122853
closesodoo/odoo#40655
X-original-commit: f6ae9f0aea5a250cbff6734de8a43a1b741394a7
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reproduce this bug
- Install Calendar
- Create a recurring event starting at the date of yesterday
(later than your actual time)
- Set the recurrency to every day, 1 time (today)
- Click on the today's event
- Add attendees > Invitations > Send mail
- Run the mail queue manually (Technical > Scheduled actions)
The mail you sent are for the date of yesterday
The behavior is the same for the reminders
Cause
The mail are sent with the `_send_mail_to_attendees` method
who pass the attendee_id to the templates.
The `attendee_id.event_id` is always the first one.
This commit pass the correct event to the template via the context.
I replaced only the dates values in the template.
closesodoo/odoo#40320
X-original-commit: 1926c6cfea0e21842fbd71fd85629b13fce9b413
Signed-off-by: Jason Van Malder <jasonvanmalder@users.noreply.github.com>
Before this commit, when an event have multiples notifications, if the
first notification is not ack when the second notification is shown, not
only two are visualized but multiples notifications are raised.
Now, only the correct number of notifications are shown.
opw-2070852
closesodoo/odoo#39909
X-original-commit: 8ab0bfeaa7b6c3e1642064d123197b1cba74355d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Activate Google Synchronization, create on GC a recurrent event,
synchronize OE, then delete an event of the recursion on GC, sync again
on OE.
The event will be deleted from GC but not from OE after sync.
The exclusion on OE is not correctly working in that particular case,
fixing require also to "suppress" the attendee to avoid that just
created exclusions would be detected as changes to send in a following
synchronization.
closesodoo/odoo#37884closesodoo/odoo#39510
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
It is possible to select "System (English)" as chosen language,
or False in v12 or earlier versions.
However, if the language has not been activated,
then record_lang is an empty recordset, so record_lang.date_format is False,
(respectively time_format), and so the formatting crashes.
Note that if this happens, the calendar notification mechanism generates a crash
at each page load.
Instead we use get_lang which defaults to the most appropriate activated
language: the one given in argument if it exists, or the company one.
co-authored with @mart-e
closesodoo/odoo#38445
X-original-commit: 738214f00dff33389e7211ee73eae76b196b7844
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
en_US may not be activated as it is possible to create a database in
another language using the database manager.
When trying to install a chart of account, the tax return entry tried
to format a date at the installation of the module, with no lang in
the context. The fallback was made on en_US but an error is raised if
that language is not activated.
As it is a very common scenario to retrieve a language from the
context, add a generic tool method to do it.
Replace and closesodoo/odoo#37629closesodoo/odoo#37568
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
From calendar create a recursive event and add some guests. Delete one
event of the chain.
Invitations (Mail) will be created for the deleted event, and should not
be the case because the event has been deleted.
This happens because the recursive event is really just a record in the
database representing all the generated events. When the user want to
delete an event in the chain, a new event, copy of the "parent" event
has to be registered and subsequently disabled.
In the process of creating the event the mail is sent as
side effect. Note that the code to prevent this was partially there
because a context flag "dont_notify" is sent by the unlink in
Calendar.Meeting but was ignored from the mail subsystem.
opw-2039576
closesodoo/odoo#36270
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This branch is the combination of several optimizations in the ORM:
* store field values once in the cache: the cache reflects more
faithfully the database, only fields that explicitly depend on the
context have an extra indirection in the cache;
* delay recomputations by default: use method `recompute` to explicitly
flush out pending recomputations;
* delay updates in method `write`: updates are stored in a data
structure that can be flushed efficiently to the database with method
`flush` (which also flush out recomputations);
* make method `modified` take advantage of inverse fields to inverse
dependencies;
* filter records by evaluating a domain on records in Python;
* a computed field with `readonly=False` behaves like a normal field
with an onchange method;
* computed fields are computed in superuser mode by default.
Work done by Toufik Ben Jaa, Raphael Collet, Denis Ledoux and Fabien
Pinckaers.
closesodoo/odoo#35659
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
PURPOSE
SMS are a powerful marketing tool. For instance it is perfect to announce a
sale or to communicate a coupon code, to welcome a new customer in a fidelity
program, ...
Purpose of this task is to integrate SMS sending in batch in mass mailing. It
will use same mailing objects but sending SMS instead of emails. Some metrics
and flows will have to be slightly updated at the same time.
SPECIFICATIONS
Limit use of templates to models that are really capable of sending
SMS. Templates are now available on models that inherit from mail.thread
and effectively have fields used in SMS sending.
Technically this is done through a not stored field on ir.model that is
searchable. SMS sending capabilities is based on
* having fields holding phone numbers, as defined on mail.thread in SMS;
* having fields holding partners, as defined on mail.thread in SMS;
This implied some code rewriting notably about finding default SMS
recipients on a given model, in order to have fields instead of directly
returning partners.
LINKS
Task 1997464
PR #34424
Original SMS addition: Task 1922163 (4287481)
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closesodoo/odoo#35504
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Martin Trigaux