* web_unsplash, website_forum
With [1], the access errors when a portal user were using the media
dialog got fixed. It also came with the unsplash capability for portal
user in the media dialog.
Still, there was a remaining problematic point: an internal user can't
upload an unsplash image in the backend through the media dialog. It
doesn't really make sense for an internal user to have less right than
the portal user.
This commit corrects that part.
Note that only unsplash images were problematic, not regular uploaded
image as the difference was that unsplash images attachment are saved
with an `url` property, which was triggering due to [2].
Finally, it was chosen to make that "bypass" more robust and opt in, so
forum and unsplash are allowing their use cases to go through, it's not
done in a generic way anymore.
Also fixing a small issue about the res_id not being sent when editing a
forum post, because it was assuming that the URL would end with the ID
which is not the case when you edit your answer.
[1]: https://github.com/odoo/odoo/commit/e10493711879c7f0cc8832db3f1936c622ea605c
[2]: https://github.com/odoo/odoo/commit/bfffe39f1376a56226572295b945a2cc73ba50ce
task-3007844
closesodoo/odoo#103138
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since it was introduced with [1], only the key could be added in the
settings, but not the app id.
Still, both are needed to actually use unsplash, otherwise it won't
work and the media dialog will keep showing the crendentials part, where
one can also add its credentials.
Basically, without the app id field, the access key field was useless in
the settings.
[1]: https://github.com/odoo/enterprise/commit/88746157ca16af4033576361dddae0b694aca70d
task-3004144
closesodoo/odoo#102000
X-original-commit: fa45712eecd2a0fbf6236f611ddffd0b5e81dc31
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
* website_forum
Portal users cannot insert images in the WYSIWYG, eg in a forum post.
Steps to reproduce:
- Install website_forum
- Connect as portal
- Go to the forum and create a new post
- Type '/image' and try to insert an image
- An Access Error is raised preventing the portal user from inserting an
image
History:
- It was possible in version earlier than 15.0 before the new editor, as
it was using a base64 inplace image upload to bypass the access rights
and avoid creating an attachment.
- It was broken in 15.0 with the new editor which doesn't have such a
mechanism. The image upload was then disabled for those users in 15.0
with [1] to avoid that bad UX with those errors/tracebacks.
- It was decided to implement a clean solution in master and see from
there was will be done with 15.0 (as being able to upload an image on
a forum seems quite critical).
Solution here in master to be able to use the media dialog:
- First issue, about opening the media dialog:
It fetches attachments, which is raising some access errors. We now
catch the error silently and return an empty list.
- Second issue, about upload an image (and thus creating an attachment):
We now create attachments with sudo to allow access to portal users,
but only if he has write access on the model.
[1]: https://github.com/odoo/odoo/commit/e453d4c119a69f285d9a014babe485492bbe9c40
opw-2648770
task-2811325
closesodoo/odoo#82612
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Merlin (megu) <megu@odoo.com>
Before this commit, when a restricted editor search for an image, he
will have an error 404 not found, when he try to access to the unsplash
key. Now he can search for image on Unsplash.
closesodoo/odoo#94506
X-original-commit: bbdd91e778a46c68461574dbea146e178f8c3c3f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Website has no dependency to web_unsplash, we cannot warranty the order
of the execution of the overwrite done in 5ef8300.
So to avoid to create a new module bridge, with a lot of code, we prefer
to make a check for website user directly in unsplash module.
It is 'safe' since if you don't have website, the group
`group_website_designer` doesn't exists and so it will do a `or False`.
closesodoo/odoo#93885
X-original-commit: 05f9f5db372b1a3644f85cb1de3c443b722ef309
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When working on qweb fields it is difficult to find some custom override as
they are never in the right file. Finding them is always a bit of random pick.
Task-2607416
Part-of: odoo/odoo#74171
Before this commit, selecting an unsplash image on website, then going
on a product page and selecting that same image in the media-dialog
would not work, and upon saving, the image would be the image
placeholder.
A previous fix in odoo/odoo#31328 added handling so that you could
choose unsplash images for a product, but it failed to account for
unsplash images that had already been added on a public view (for
example on a website page), which the user can choose in the
media-dialog.
This was caused by the fix only searching for the unsplash attachment on
the current model, and not among public attachments, resulting in an
empty search result.
This commit fixes that by adding that the attachment we are looking for
should either be on the current model, or be a public attachment.
closesodoo/odoo#49937
X-original-commit: 196d6b1630fa443bc1d143f76f62f7a719ca4930
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
before this commit:
when creating a product from frontend and editing the product and
delete image, it doesn't get any url thus generating the traceback.
after this commit: if url is not defined then return None from
ir.qweb.field.image field converter
task-2063293
closesodoo/odoo#40866
X-original-commit: 2efad751e66931fd25a41c1b7d46865bccbc774a
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The wysiwyg abstraction layer was introduced in saas-12.2 by
commit f2969923. Its goal was to provide an external interface
for other modules that wanted to use the editor feature such
that the editor core itself could be changed without requiring
extensive changes in the other modules.
This commit is adapting the wysiwyg interface to instantiate
the 12.0 editor below it rather than the saas-12.2 one, thus
reverting the "new editor" part of f2969923 itself.
Part of PR 35677.
Co-authored-by: Nicolas Bayet <nby@odoo.com>
Co-authored-by: Antoine Guenet <age@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Go on the website, create a new product from there
Click on the image to change it, select an unsplash image
Save your product.
Beforer this commit, the image wasn't saved because the qweb field image
did not know what to do with /unsplash/ urls
After this commit, the image is saved on the product (or any object...)
OPW 1936191
closesodoo/odoo#31328
Romain Derie