It would probably be even better to iterate the file content and get
the non-quoted non-alphanumeric characters as separator
candidates (instead of a hard-coded list) however Python does not seem
to have a decoding iterator (taking bytes and yielding an iterator of
codepoints or even grapheme clusters) — incidentally uniseg seems to
require up-front decoding as well — so that's not really convenient as
we may be dealing with large-ish files and not want to load it
entirely in memory.
An alternative would be to use TextIOWrapper and iterate the file by
buffers of a few ks, and classify that based on either codepoints or
grapheme clusters.
This merge optimizes and lessens query count of notification process. When
posting a message some computation is done to fetch followers and/or people
and channels to notify, then notify them on their Inbox or by email. This
process now takes less queries thanks to several improvements :
* fetching followers / recipients data is now done manually in SQL allowing
to fetch data across several models in less queries;
* computing recipients is now separated from notifying them. Notification
better uses precomputed data in order to avoid fetching and browsing
several time the same data;
When possible code has been made more readable through code inlining. Several
methods have been removed because they are not used in inheritance. Some code
is now more low-level. Optimizing part of the process can make it harder to
inherit or modify.
Performance counters are updated showing gain in nearly all tested cases.
An enterprise branch is linked to this one that also improve notification
process.
This merge is linked to task ID 47934 and closes PR #24033. No functional
change should occur with this merge.
Purpose of this commit is to avoid browsing and prefetching data about
recipients when notifying a message to partners and channels. Mail message
_notify computes all necessary data in a single query. This commit allow
to re-use this data by propagating it through the call chain.
Addons inheriting from classification methods used when sending notification
emails are updated accordingly to the API and data update.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit cleans code about sending email notification to recipients.
Purpose of this code is to prepare notification emails, group recipients
and finally send emails. In this commit we clean and optimize a bit by
* propagating some additional parameter to simplify code, like record
on which the notification process runs;
* inlining some code currently located in sub-methods. It eases code
understanding as there are less code jumps. As those methods are not
inherited inlining them can be done;
* simplifying a bit notification emails preparation and computation;
It allows to save a few query by avoiding to fetch and browse again some
data that were already computed.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit is related to enterprise commit that updated mail_push. It is about
[REF] mail_push: optimize mail.message notification process override
It updates code of mail_push to lessen its impact on mail-related code. It
allows to change a few counters in test_mail. Indeed counters are impacted
by code located in enterprise because those are "maximum queries" counters.
As mail_push is an auto-install module enterprise runbot would be broken
if the counters weren't updated.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
In this commit we update _notify method of mail.message to fetch most data
related to notification process in a single query. Indeed posting a
message can be a costly process, especially when involving several partners,
channels, depending on their notification status, user groups, ... Most
of the required data can be fetched in a single hand-tuned query.
Purpose is to lessen query count. Side effect of this commit is that code
is less recordset based and therefore more low-level. It is also harder to
customize the behavior through inheritance as it implies rewriting a bit
more of code.
This query is located in a private method on follower model. It takes
parameters allowing to either fetch data related to followers of a given
subtype, either related to some partners and channels. First use case is
related to the process of posting a message with a subtype that triggers
notification of followers. Second use case is related to notifying some
specific partners or channels of a given message. It takes notably into
consideration internal subtypes and active field of partners, allowing to
correctly handle corner case for deactivated followers and portal / share
partners.
Notification process is divided into two steps. First one is to compute
recipient data. Second one is to apply the result of this computation and
call the various notification mechanisms accordingly. Doing so allows to
easily re-call notification process or compute some data differently
if necessary.
API of notification methods is updated to allow passing notably the values
used to create the newly-posted message. It allows in some simple case to
avoid browsing message and partners when no notification is necessary. It
saves some queries in simple case like posting messages with specific
subtypes not often followed or logging notes without mentioning people.
This commit allows to save a few queries on several performance tests as
indicated by updated performance counters. Future commits will gradually
propagate the use of this data to further lessen query count.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
Since date / datetime refactoring done at 960360afe4 we cannot
encode new leave requests or new allocation requests anymore. This commit
fixes that by correctly setting date / datetime on date / datetime field
and correctly computing one from the other.
The other overrides are working with multiple records but not event_sale.
The ensure_one() is not needed if you make a proper loop
Replaces and closes#26078
Various bits would lead to odd tracebacks or a complete lack of
actionable feedback.
Discover that a binary field set to b'' will return None when read back,
handle that, then handle reading an empty CSV file, then handle the
resulting iterator having no lines whatsoever when trying to match
headers.
At least for CSVs, we're now properly telling users that their file
seems to have no content when they literally upload an empty file.
Payments older than the chosen date won't be proposed in the widget allowing to match payments with bank statements. This is useful if the db used invoicing for years and then installed accounting : users don't want to have to match all the old payments that were generated by invoicing with bank statements.
Was task 1829536
Was PR https://github.com/odoo/odoo/pull/24728
* if an encoding is explicitly specified, use it and don't guess
* otherwise guess and return the guessed encoding so it can be
displayed in the configuration UI
* fix less-than-stellar configuration & behaviour of select2 inputs
to properly reflect underlying values as they get modified, to
correctly handle future configuration guesses
Applied 'o_row' class instead of 'row' to avoid indentation issue and
also applied 'button_box' name attribute to group to fix stat button
separation issue.
The 'table-responsive' class should not be used on <table/> elements
directly (this is allowed by BS4 but this is not good practice to me).
Closes https://github.com/odoo/odoo/pull/26148
The char field has a size attribute that is displayed in the interface:
- if the field is added with code, the size is always 0 even tough the
size limit is set correctly in the database.
- if the field is a custom field, the size is correct and can be updated
With this commit, a base field show the correct size.
opw-1869282
closes#26204
Consider the following:
``` python
from datetime import datetime
from dateutil import rrule
import pytz
dt = pytz.UTC.localize(datetime(2016, 9, 2, 15, 42, 43, 205))
rset = rrule.rrulestr('FREQ=WEEKLY;INTERVAL=2;BYDAY=SU,FR,SA', dtstart=dt, forceset=True, tzinfos={})
test = [d for d in rset]
```
This will generate the following error:
```
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 1164, in _iter
advance_iterator(ritem)
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 1091, in __next__
self.dt = advance_iterator(self.gen)
File "/usr/lib/python2.7/dist-packages/dateutil/rrule.py", line 649, in _iter
date = datetime.date.fromordinal(ii.yearordinal+i)
ValueError: year is out of range
```
If such an event is received from Google Calendar, the synchronization
crashes. To avoid this, we enforce a `COUNT` condition if the latter or
`UNTIL` is not explicitly specified. This gives:
``` python
rset = rrule.rrulestr('FREQ=WEEKLY;INTERVAL=2;BYDAY=SU,FR,SA;COUNT=100', dtstart=dt, forceset=True, tzinfos={})
```
Note that this was supposed to be fixed in
https://github.com/odoo/odoo/blob/9dcc32c3041e7ad3549a09c5ed68ee3ef22c7a26/addons/calendar/models/calendar.py#L1287
However, this was working with the old API. The new API and its computed
fields does something different:
1. create the calendar event with the provided `rrule`
2. trigger the inverse method `_inverse_rrule` => `count=100` is added
to the computed parameters
3. however, doing so won't recompute `rrule` for obvious reasons (it was
the initial value provided, so we don't recompute it)
4. the crash is met in `_get_recurrent_date_by_event` when using
`self.rrule`
The fundamental issue is that `_inverse_rrule` is not strictly the
inverse of `_compute_rrule`.
Fixes#25189
opw-1861658
It was introduced in 2013, but it's not needed in 2018. According to library's
note:
"As of late 2015 most mobile browsers - notably Chrome and Safari - no
longer have a 300ms touch delay, so fastclick offers no benefit on newer
browsers, and risks introducing bugs into your application. Consider carefully
whether you really need to use it."
PR #26200
In resource.calendar.attendance, we store the start and end hour of an
interval as floats.
eg: 17 hours 9 minutes is stored as 17.15
When converting this float to a datetime object, the method
float_to_time always rounds down the value, which may be wrong if, due
to float imprecisions, 0.15 hours is converted to 8.999... minutes (and
was then rounded to 8).
We do fix this behaviour by rounding to the closest integer.
Thanks to @jem-odoo for his help troubleshooting this issue.
opw-1872166
Purpose: Give the ability to people to directly sign (sic) an email template
without opening the mail composer.
Specifications
* do not display 'email' in activity view: either there are emails and new
display applies, either there aren't any and do not dispaly anything;
* update display of template choice: https://www.awesomescreenshot.com/image/3531694/7f6ac0250009599089ec62b6951a88b4;
* add an "mt 16" between activity and first mail template;
Tests have been updated to new specifications.
This commit is linked to task ID 1872169 and PR #26185.
Purpose of this commit is to have a shortcut allowing to send an email based
on an email template in the activity mixin. Its use will be to integrate
the sending of emails directly in chatter-activity widget.
This commit is linked to task ID 1872169 and PR #26185.
Because we converted buttons into tables so inline buttons was
breaking into multiple lines so we need to add display inline and vertical align
properties in tables.
We allowed display property from mail sensitizer whitelist.
Because in this commit https://github.com/odoo/odoo/commit/cf15030ed09f7479f5b2701ba101a5bed71f7409
we use display property for align items
- Email generated from mass mailing will have its own layout with internal css.
- strip_classes is removed from mail_message because mail client are now supporting
internal stylesheet. we need it for make mail responsive.
mail: manually removed classes from incoming mail body
Because we removed strip_classes from mail message body field because we want to
allow classes in outgoing mail to make it responsive but classes are not removed
from incoming mails so here we manually removed classes from incoming mail.
opw-1836556
commit 47654e98e0 modified a defaultdict by an OrderedDict.
When multiple orderpoints use the same location the key is the same and
location_data dict entry is removed for the new one.
This commit only call makedefault when there is not current entry for
the dict.
The to_refund attribute is set to copy=False.
However when splitting a move to create a backorder, a new move is created as
a copy with the remaining work to do.
This attribute is needed so that the backorder refund is consistently applied.
opw 1865324
From this commit onwards, Date fields will return datetime.date objects and Datetime fields will return datetime.datetime objects, this implies a number of things that are clearly explained both in the ORM API for master.
This commit also introduces a number of helper functions for dates and datetimes that are exposed in tools.date_utils and fields.Date[time], explained in the documentation as well.
Task-ID: 47189
Finished product moves from a MO where created without warehouse_id.
It implies that push rule based on warehouse where not trigger on those
moves confirmation.
This commit adds warehouse_id on unbuild/production's finished/raw
moves. It also add a test for this behavior.
Task ID - 1865574
Due to this commit: 6e93fe0de1
the stock user has the all rights on model 'product.pricelist'
As the repair order model has the field pricelist_id on it,
the stock user must have the right to read it.
opw:1865814
Xavier Morel