Introduce official support for SVG files in the framework, including the
following parts:
1. When client-side SVG images are uploaded, the content is displayed until
you save using data URI scheme according RFC 2397 [1]. This scheme requires
to specify content format. Using hardcoded "image/png" works for all images
types except SVG.
Type-sniffing is done using "magic byte" detection via the first base64
encode byte, so that the proper data URI scheme can be used.
This should not cause SVG-related security problems as the file is
displayed through `<img>` tag, which does not allow SVG scripting [2].
2. Make /web/image controller compatible with SVG
3. Add support for SVG files for company logo, which uses a dedicated
controller.
4. Resizing of SVG files is a no-op, as it makes little sense for a
vector-based format. We also want to avoid micro-alterations to the SVG
document (in "natural" viewport parameters) as we would store multiple
copies of the files in the filestore.
5. Because SVG files are inherently dangerous, upload of SVG files is
restricted to administrators, either by blocking it directly before
saving it in the database (binary fields with attachment=False), or by
neutering them to text/plain mimetype (for binary fields with
attachment=True)
6. Add tests for the SVG upload cases and for the non-admin uploads.
[1] https://tools.ietf.org/html/rfc2397
[2] https://www.w3.org/wiki/SVG_SecurityCloses#26635
On an AccessError, the relevant message is passed as the first arg. But
the import error handler would only check for the second arg (if any)
then fallback on error.message, which is missing entirely when the issue
is raised as an except_orm subclass.
Auth can now report errors less trivial than "incorrect password", the
wizard should report them instead of just assuming the original
password was not correct.
* generic strenght meter widget which can be included in various
places
* password field, taking over the isPassword special cases strewn
throughout the codebase, this should probably become an actual thing
in core /cc @ged-odoo, the meter is opt-in as most uses of
`field[@password=True]` are passwords & secrets for third-party
services or external servers for which a meter would not make sense
* separate override of the ChangePassword wizard which isn't a regular
view for some reason
* direct implementation for signup pages (create user & reset password)
Skip/comment/remove existing testing of @password fields: the policy
replacement/augmentation needs to make an RPC call and does not
support readonly use (because it doesn't seem to be used anywhere so
that made sense?); and there currently is no way to augment or
override/replace existing tests, so the tests will either fail when
auth_password_policy is installed (current situation) or fail when
auth_password_policy is not installed (if updated to be compatible
with APP).
Revision on bus refactoring: https://github.com/odoo/odoo/commit/6448420c5dd160470e465dee7729d19d8d5e7bab
Before this commit, when a user was disconnected for a very long
time, he would receive lots of chat notifications on his next login.
Here is an example of weird behaviour with this issue:
- User folds and unfolds a chat window 50 times
- User disconnects for more than 50 seconds
- User reconnects
==> the chat window rapidly folds and unfolds itself 50 times!
This issue comes from the fact that after 50 seconds without any
longpolling, the web client ignores the last tracked notification
and sents the ID `-1` to the server.
The web client always provides a notification ID to the server
on a `longpolling/poll`. Usually, the server returns all
notifications of the user with an ID greater than the provided ID.
There is an exception with ID `0`, in which all notifications since
the last connection of the user are returned.
The cause of the issue is a mismatch of the special notification
ID between the server and the web client. For the web client, the
ID `-1` is used for not tracking any notification, whereas the
server uses the ID `0` for this case. As a result, when the server
receives the value `-1`, it returns all notifications having an ID
greater than `-1`. In other words, it returns all notifications
related to this user, even the ones received long time ago!
This commit fixes the issue by enforcing the special notification ID
`0` on both the webclient and server.
Note that this logic is similar to 11.0:
- The webclient uses the ID `-1` most of the time to define 'untracked':
https://github.com/odoo/odoo/blob/11.0/addons/bus/static/src/js/bus.js#L154
- However, it passes the ID `0` to the server:
https://github.com/odoo/odoo/blob/11.0/addons/bus/static/src/js/bus.js#L193
Purpose of this merge is to add activity view on main actions of models
inheriting from the activity mixin. Purpose is to help using activities
by having access to the summary activity views.
This merge is related to task ID 1889413 and closes PR #27381.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated :
* survey main menu action;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* purchase and RFQ main actions;
* specific product actions defined for some menu actions in purchase;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated :
* project all tasks main menu action as tasks coming from project already
had the view;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated :
* point_of_sale main menu action;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* employee main menu actions;
* leave and allocation request main menu actions;
* applicant main menu actions;
* expense and expense report main menu actions;
* contract main menu action;
* attendance employee main action;
Following @est-odoo advice the Next Activities menu entry in hr_recruitment
is removed as there are already a lot of ways of managing activities: using
the systray, using activity view present on most actions, ...
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated :
* fleet vehicle and contract main menu actions;
Some menu entries are also renamed to ensure coherence in all menu entries
that all use vehicles, with an 's'.
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* CRM and Sale/CRM main menus: pipeline, leads, quotations;
* Sales main menus: quotations, orders, to invoice/to upsell, products;
* Website Sale: quotations, orders, to invoice, abandoned;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* main invoice menu actions;
* product actions specific to account related to main menu action;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* product variant main menu action;
* product main actions used in various apps;
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated :
* note main menu action
This commit is linked to task ID 1889413.
Purpose is to extend the use of the newly-introduced activity view allowing
to see at a glance activities to perform on a given model. It eases daily
job of people working with activities.
Updated
* main partner menu action (Customers);
* membership partner main menu action;
* customers / vendors main menu action used in various other apps;
This commit is linked to task ID 1889413.
This merge fixes blacklist mechanism, mixin and its use in mass mailing.
Some fixes are related to https://github.com/odoo/odoo/commit/2ff9b379ef80ba6a8744fb9702a8088284372ddd. Tests are added in a
new module that will gradually hold more complex tests for mass mailing.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and closes PR #27330.
Purpose is to fix the comparison between mass mailing record email field
and blacklist entries by sanitizing email to ensure comparison is done
on same basis as what is stored in blacklist table. Also fix the action
merge where the extraction of email is needed before comparing to the blacklist.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Until now, a recipient with a formatted email like 'John Doe
<john_doe@example.com>' could be reached by email even if its email address
was blacklisted. Now when sending a mass mail using the composer, the email
is sanitized before comparing it to blacklist entries.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to make search coherent with sanitize of emails
done when storing blacklist entries. We parse search terms in order to
find something related to email field and sanitize it to avoid issues
linked to case insensitivity or formatted addresses.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to correctly extract email address from the email
field of models inheriting from the blacklist mixin. Indeed email field
could contain a formatted address like "Raoul Grosbedon <RAOUL@example.com>".
Related blacklist entry would be raoul@example.com. We have to extract
the email from the email field and lowerize it in the SQL query or the
computation in order to have a fully working blacklist mixin. This fixes
some bits left at commit 2ff9b379ef.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
This commits fixes the use of email field in blacklist mixin as it was based
on 'email' field instead of the one coming from the _primary_email class
attribute since commit 2ff9b379ef.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Now that blacklist records are set as lower case be sure all checks in
blacklist are done accordingly by using the sanitizer before comparing
email adresses.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Currently blacklist is configured to have unique emails. Notably when creating
new entries it checks for existing records with same email to avoid crashing
about duplicate entries.
However it does not check if given values use unique emails. When importing
a big list of emails you are not sure emails are unique. This commit ensures
values given to create are correct to avoid crashing when importing a lot
of data.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to standardize content of blacklist records and
ensure only real email addresses are stored.
We introduce a sanitize method to extract email address from string (like
Raoul Grosbedon <raoul@example.com> -> raoul@example.com) and return a
lower case version of it.
Purpose is to gradually get rid of lower() that appear a lot in the code
and speedup computation by being sure everything is always lower case.
Moreover indexing on blacklist model will be more performant is using
directly email field content instead of having to lowerize it.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to add some tests linked to the blacklist mixin
itself, notably the computed fields and its search method.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to enforce blacklist use and base mechanisms. This
commit may break on runbot as fixes will come after having introduced tests.
It notably add tests for a8ce59ce36.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose of this commit is to add the skeleton of a module holding models and
tests for mass mailing. It is build on top of test_mail in order to use
data, models and parameters already defined in it. Moreover having a
separate module allow to define test models that will not bloat production
databases.
It will soon hold unit tests for blacklist mechanism. Future commits will
gradually move tests from mass mailing module and improve them.
This commit is related to task ID 33224 (original blacklist implementation
done for v12) and its PR #25966 as well as task ID 1889703 (tests and fixes)
and its PR #27330. Done with collaboration of @dbeguin.
Purpose is to separate tests related to access rights (low level), base
activity features and mixin itself. It eases understanding of tests and
prepare future addition of tests.
This commit is linked to task ID 1856417.
It is not necessary to limitate UTM-based statistics based on the mailing model.
Indeed a mailing on contacts could for example generate leads and sales that
people could want to see the mailing view.
Commit linked to task ID 1889754.
Pedro M. Baeza