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>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Now in a calendar view, if we use the color, attribute, it will use
the same color as Gantt views and the color picker widget.
The attribute color isn't more set as default in filter because it make,
in most situation, no sense to filter by color.
Now, we can add new filters in the right panel. To do that, we must
add the attribute "filter='1'" in the corresponding field line.
And if the filter has no direct link with the color of the model,
we can specify an attribute 'color' for this filter line block.
(for example color='color', and the color of the related model
will be used)
TaskID: 2153249
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>
PURPOSE
Allow multi-edit for calendar event and utm campaigns. Indeed it gives
flexibility to users when they have to edit several records at once.
SPECIFICATION
Enable multi-edit in each of the following views
* calendar.view_calendar_event_tree
* utm.utm_campaign_view_tree
Set the fields not editable to be readonly.
LINKS
PR #42786
Task 2078662
Related: odoo/enterprise#7553
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
Without demo data, for the odoo-master transifex project
closesodoo/odoo#41935
X-original-commit: dab7670b73506fb3a835695ee3bd735e0c5e5c2b
Related: odoo/enterprise#7287
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Followup of a425695e
The terms were back in 12.0
Courtesy of Juan José Scarafía
closesodoo/odoo#41624
X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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>
Fixes https://github.com/odoo/odoo/issues/39358
Before this commit Internal user (With no other Rights) cannot perform any activity on Reminder Popup due to missing rights to set calendar_last_notif_ack field.
With this fix, we are now using sudo to write calendar_last_notif_ack
closesodoo/odoo#40104
X-original-commit: 91560fae56f1cba09141eefa1d0da03f4a7b3f72
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Purpose is to lessen size of technical "Email" menu and move some
discuss menu entries in their own menu. It will be the new first menu
entry in technical, before Emails that is more technical.
Some menu items are moved in this new menu, notably followers, messages
or mail blacklist.
Emails menu is also reordered, to have notably all channels related
entries together, ...
Task 2118599
PR #39460
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>
*:
- account
- barcodes
- calenndar
- hr_timesheet
- mail
- mass_mailing
- partner_autocomplete
- web
- website_slides
This commit removes description of fields that should not be shown in
non-debug mode Studio. Only field widgets whose own description is
set are displayed in non-debug mode Studio in "Widget" of sidebar.
In other words, even if any ancestor has a description but not the
current widget, it won't be displayed in the sidebar in non-debug
mode.
Task-Id 2056992
closesodoo/odoo#35902
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Step to reproduce :
For small screens
> enter the debug mode
> go to the calendar app
> access one of your meetings
> access the tab "invitations"
> try to change the state of attendance
It's due to the missing kanban view used by the o2m field 'attendee_ids'
We had to create this missing kanban view to allow theses actions on mobile.
opw-2058770
closesodoo/odoo#36501
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Slovenian language, as many others languages, is not present in the
beta/master projects in Transifex.
For some reason, Transiflex removed all current translations, this was
already fixed in 12, but as there are not automatic forward-port for
translations, this is a manual forward-port.
opw-2060055
closesodoo/odoo#36374
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
jerome hanke (jhk)