Add support for avatar

Feature
#1

Rational

Avatar are good in helping user to identify entities (like users, parties etc.).
Implementing it in Tryton should take care of minimized the load. This should be solved by sending the proper size for the picture, compress it and caching it on the client side.

Proposal

A new internal model is defined to store avatar for any resource (like the attachment or note). It stores the full size binary data of the image on the filestore. The base image is converted into jpeg (using configured quality level) and resized/cropped to be a square of maximum 2048px.
We store in a One2Many a version of the image (in filestore) as cache for a specific size.
A Mixin can be added to any Model which adds a link to the avatar and a Function field that retrieve the image for a defined size. The setter is responsible to set the base image and to clear the cache.
The Mixin provides a method to get a public URL for the avatar without leaking any information. So the identifier of the avatar record is a random string (and not the ID).
A public route serves the avatar and has as parameter for the size. The Mixin provides a method to construct the URL to this route. The hostname is configurable in order to use a CDN and also the cache expiration. The database name will be hidden the same way as in web_shortener module.

On the client side the <image/> is extended to have a type attribute which can be icon (current and default behavior) or url. When it is url, the client get the content using the name as url and cache the result if possible. The size is appended to the url as parameter.
The <image/> tag is added also to the tree view.

By default the avatar feature is added to res.user and web.user. A module is created to add avatar to party.party.

Implementation

2 Likes
#2

I’m wondering if we should add a fallback to gravatar using the record email for the users that did not upload it’s own gravatar. AFAIK this should not be hard to implement.
Of course when an avatar is set for the user gravatar one should be disabled.

#3

If such direction is taken, please add an opt-in for such setting as it could open privacy issue for some users (a third-party will be aware about activity for users).

1 Like
#4

I’m not fan in coupling core feature with external service. We already see with geonames.org the problem that such dependency generate.

Indeed there is two ways to implement such fallback feature.
You can fetch on creation the avatar from gravatar and store it. But this generates many issues about which email to use, what if email change. Also as you can see on the review the image is stored after the creation…
You can just return a gravatar URL when there is no avatar in get_avatar_url but there are still the problem of finding which email to use. And this means that the form will not contain the avatar. Also the gravatar cache period is very low 600s which requires to make a lot of request which does not always succeed. See www.tryton.org: 43b78d783beb

For that I think it is the server that should serve the gravatar and cache it. So there will be only one request per new record. Or maybe just a cron job that refresh them.

#5

Indeed I was thinking in using this fallback mechanism and use the email field.

This is fair for me as the user did not upload any avatar.

If there is a cache there should be cron job that refreshes them.
But then we are making it so complicated so probably we can leave this as future work and using a separate module.

#6

As discussed in IRC here is the implementation extracted from my shop module:
https://repos.mittelwind.de/shop_image
maybe there are a few ideas

#7

I appreciate that you are seeking some solution to avoid the user’s client is reaching out to gravatar. This complies to GDPR. If the user’s client would reach out to gravatar, companies would get into “GDPR compliancy hell” - requiring legal “handstands” (German phrase) just to display some avatar.

Anyhow, if you choose to implement gravatar lookup, there has be to some option for disabling it. For at least two reasons:

  1. When asking gravatar for an avatar image, personal identifiable data (the user’s e-mail address) is transferred to the gravatar service. According to Art. 28.1 GDPR this must only be done if the company has a contact with gravatar (the processor). This contract must exist, even if this is just a single request and even if this request is done from the server, And this contact must exist prior to the very first request (= transfer of personal identifiable data).

  2. Even if there is a contract between the company and gravatar, the company might still not be allowed to submit the user’s identifier to gravatar - as this requires e.g consent (ref. Art. 6 GDPR).

And for the same two reasons, this option shall be set to “disabled” by default. A company can the “enable” it if all legal requirements are met or if the company resp. the data processing is not subject to GDPR.

Side note: Reading gravatar.com’s privacy statement, I doubt it’s a good idea at all to use this service. The statement is somewhat vague (“We may share information …” is not quite transparen) and sounds like they are profiling users (“Inferences we make (such as likelihood of retention or attrition).”)

#8

This topic was automatically closed after 14 days. New replies are no longer allowed.