'slug' cannot be called on records which are not yet saved, aka have no ID.
In this commit we set the website_url to False for records that do not have
any ID.
Code managing those URLs is updated to be defensive, as notably when using
studio you may end up trying to call methods on in-memory records.
Followup of odoo/odoo@da3f4c2aff
Task-3254382
closesodoo/odoo#117255
X-original-commit: 36c734ab37fdf1d6a245e0e29cfefe3cc46c6d92
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
textwrap does the ellision and we don't need to replace newlines characters.
It is done for us already (except that multiple newlines will be replaced by
a single space).
closesodoo/odoo#116778
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Avoid search_count in a loop using a filtered_domain.
Also removed a sudo, as anyway this method is already called in sudo in
most cases.
Part-of: odoo/odoo#116778
Before this commit, the compute method was not returning the value for the
field karma_flag field, and thus it was returning compute method failed to
assign value error.
After this commit, the compute method will return correctly set the value
for karma_flag field from the forum.
closesodoo/odoo#116281
X-original-commit: odoo/odoo@bfa3f2d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently 'forums_count' field on website is not correctly updated. Test
introduced recently show that
* at website create, counter is not computed;
* at forum create, counter is not computed;
Only updating a forum active flag, website value, or unlinking it recomputes
the counters.
Note that manually updating counters is required as forum with False website
are global forum, valid for all websites.
Finally rename 'forums_count' into 'forum_count'. Fields in Odoo are rarely
plural (more like 'forum_ids' / 'forum_count' for example, even if in our
case the 2many does not exist due to shared behavior).
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
Gamification data used in some emails to add links and shortcuts is not
correctly translated. Let us fix it.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
Instead of doing 1 search_count / user in the loop, use read_group to fetch
data in batch.
Also remove an unnecessary import.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
Default value is currently not translated, which is sad. We therefore move
it into its own default method, use translation marks, and Markupize the
whole result.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
Better have a correctly formatted content looking like all other HTML fields.
This is achieved by using sanitize parameter which cleans up html content
according to our standards.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
A strange manipulation is performed when trying to create tags. In this
commit we simply make styling happy by trying to first prepare data
(strip, content) then use it. Feature is untouched currently.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
Mainly reorganize them alphabetically so that execution order matches the
definition order. It helps when debugging.
Also clean some tests from odoo/odoo@f9c2716b3e because they either test nothing
either are not understandable by standard humans. Other tests are left
untouched.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
PURPOSE
Reorganize website_forum module. This allows to better locate code, understand
organization, and prepare future changes.
SPECIFICATION
Reorganize main content of python code
* group compute fields on top, order them following fields definition;
* add section separators, to separate compute methods / CRUD methods /
business methods / Mail methods / Tooling in file and have a way to
sort a bit the code out;
* rename compute methods to start with '_compute', to match guidelines
and be coherent with global odoo naming;
* perform some relining in fields definition, don't enforce any char
length but try to stay aligned with Odoo apps;
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
PURPOSE
Reorganize website_forum module. This allows to better locate code, understand
organization, and prepare future changes.
SPECIFICATIONS
Split python files / model. It is easier to have a global view of a module
organization and content when looking at the models directory. Each model
now belongs to a single file.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
Purpose is to try to keep history before splitting models into separate files.
We first copy a file, then remove extra content in each of them. Let us see
if this works.
Task-3240082 (Forum: Reorganize and lint module)
Part-of: odoo/odoo#114841
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Purpose
=======
Currently the on_delete='restrict' implicit constraint prevents
the user deletion in case it's linked to a forum post vote.
Set the on_delete attribute to 'cascade' as the record is not
really a critical data.
Taskid: 3222941
Part-of: odoo/odoo#114656
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
Purpose
=======
Some users found a way to farm karma points, so we want to be able to
track the source of the karma gain / loss.
Specifications
==============
Now, we added a reference field `origin_ref` which store the record
responsible for the karma gain / loss (e.g. a slide we just completed).
In addition to this origin, we also have a new field to store the
reason (e.g. "Slide completed") so we know exactly what happened and
how the user gains his karma.
Before, the `old_value` of the karma tracking has to be set manually,
but now it's done automatically based on the value of the previous
tracking of the same user. That way, it will simplify other part of
the code.
Add the karma reason in the website modules. Adapt those modules due
to the changes in gamification.
Task-2234179
closesodoo/odoo#76430
Related: odoo/enterprise#23702
Related: odoo/upgrade#3299
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Co-authored-by: std-odoo <std@odoo.com>
RATIONALE
Purpose of this commit is to cleanup main post helpers and have a more easy
and understandable way of calling them.
SUMMARY
We now have two main API methods, based on business flow: either posting
on documents, either sending a mass mailing. Indeed those two flows are
different
* post: create message, then launch notification process by taking into
account subtype, followers, ...
* mail: create mails in batch with recipients being based on template or
given partners. No notifications is involved, only maybe traces if a
mass mailing is linked
Delegate QWeb rendering to the render mixin (i.e. _render_template_qweb_view)
in order to have a single point to forge evaluation context and re-use
existing rendering code.
SPECIFICATIONS
Main API helpers are now
* ``message_post_with_source``: (batch) post on records, using an ir.ui.view
(given a record or its xml id) or a mail.template record (given a record or
its xml id). When using a template, a composer is called to post on each
record (as batch post is not yet supported). When using a view, a direct
call to message_post using the rendered bodies is done, one record at a
time.
* ``message_mail_with_source``: send a mass mailing on records, acting like
invoking the mail composer in mass mode. Same arguments are valid, either
a reference to a view, either a reference to a mail template.
Other helpers are
* ``_message_log_with_view``: (batch) log on records, using an ir.ui.view
to render the body using QWeb (no notification process);
* ``_message_log(_batch)``: (batch) log on records (no notification process);
* ``message_notify``: notify partners on records (creating notifications
specifically for some people while message itself is not displayed in
chatter);
Code migration
* ``message_post_with_template`` in "mass mode": use ``message_mail_with_source``
and set the template record as source;
* ``message_post_with_template`` in "comment" mode: use ``message_post_with_source``
and set the template record as source;
* ``message_post_with_view``: its main usage was to post on a document, in which
case it generally can be replaced by ``message_mail_with_source`` using
the view reference as source;
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
RATIONALE
Purpose of this commit is to be explicit in subtype chosen when invoking the
message composer / calling message_post. As default value may not always be
clear, better be explicit in case the composer default value changes.
SPECIFICATIONS
Add explicit references to subtype when it is not obvious what will be the
final subtype, notably when using helpers (post_with_view or template which
uses the composer that is not crystal clear in its subtype management).
In this commit we also add support of XMLID-based subtype when invoking the
composer. A ``default_subtype_xmlid`` context key is transformed into a
``default_subtype_id``, to be used notably in JS where we cannot easily
use a ``ref``-like statement. Post API now also supports 'subytpe_xmlid'
argument allowing to give the xml id and ease calling the methods.
Use ``_xmlid_to_res_id`` to get directly the ID of subtypes in order to
avoid useless queries from ``ref`` that does an exists.
Also remove useless values given to post API, notably author_id that is by
default the current users' partner.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
The current domain on the forum post child_ids field is not guaranteed to work
since it requires the recordset on which it is applied to be a singleton.
closesodoo/odoo#109596
X-original-commit: d9983167a7c534a08854ad5327e36a8343ef1e5d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: test_website, website, website_blog, website_event, website_forum,
website_sale, website_slides
Reverts this refactoring because it breaks multi-tenancy: if several
databases run on the same server and different modules are installed
in each database, the global variable becomes wrongly populated.
Steps to reproduce:
On runbot:
- Go to the `-base` URL or simply select the `base` DB
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model
On Odoo.com saas DB:
- Drag & Drop the search snippet (and let it set to "Search in
Everything")
- Try to use the snippet -> Crash on unknown model (unless you installed
each and every module related to the search snippet)
Locally:
- odoo-bin -d first -i website --stop-after-init
- odoo-bin -d second -i website_blog --stop-after-init
- odoo-bin -d first,second
- Try to use a search bar on "first" database (using "Search in
Everything") => it tries to access the blog models.
Revert of PR: #98423
opw-3045092
closesodoo/odoo#105077
X-original-commit: 5806f71af1b6f44aac063f7e504be736300f699d
Related: odoo/enterprise#33669
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
* 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>
*: website_forum, website_hr_recruitment, website_sale
Before this commit, most of the backend redirections to the
WebsitePreview, introduced in [1], were using ir.actions.url with the
get_client_action_url util, which was not optimal.
This commit changes that to use a new get_client_action method, which
returns the ir.actions.client record. It will execute the action
directly, avoid to redirect the router before, and improve performances.
Also, it allows to solve bugs, as:
- The back navigation from the WebsitePreview to the ListViews.
Going through the /web controller would add an entry in the history, and
going back on it would reload the client action.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2687506
closesodoo/odoo#102991
X-original-commit: 30fb11e479fb7b3db3649e55fcbdb06bfcdb398c
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
As indicated by previous commits, new custom list views are created to
fill the "Content" area of the main website menu with key app models:
blog posts, events, forum posts, jobs, products and courses (+ some in
the enterprise version, see related commit).
Those list views will act as the page manager one: a click on an item
redirect to the website iframe, the create button acts as creating a
record via the "+ New" systray button while being on the iframe, the
delete button will in the future allow to know the page that mentions
the related object before deleting it, etc etc.
task-2889981
closesodoo/odoo#98937
Related: odoo/enterprise#30782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
* = test_website, website_blog, website_event, website_forum, website_sale,
website_slides
`_search_get_details` extension in other modules can now be performed with
fewer lines of code by updating a search type-to-model mapping, without the
need for method override.
This will also have the benefit of slightly reducing the call stack length,
avoiding some unnecessary `if` statements and list lookups at runtime.
Task-2957361
closesodoo/odoo#98423
Related: odoo/enterprise#30946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* = blog, forum, slides
For performance reasons, allow to increment multiple fields of the same record
within the same query.
With python tests.
Task-2663320
Part of odoo/odoo#79615
A forum tag is always linked to a forum.
But some flows are not considering that part and are returning/using
tags from other forum too.
Step to reproduce, having 2 forum `Cats` and `Dogs`:
- Create a `Food` tag on the `Dogs` forum
- On the `Cats` forum, type `Food` in the tag input
- First error: the `Food` from `Dogs` incorrectly shows up
It means that the user can't create a new one from the `Cats` forum
but will actually have to select (without know it) the one from the
`Dogs` forum.
- Select that tag anyway
- Second error: The tags displayed on the post is redirecting to the
wrong other forum, ultimately not showing the post from all forums
(and the one you just came from).
- Third error: The /tags page won't list the `Food` tag on the `Cats`
forum.
Note that there is probably some access traceback involved in a multi
website and/or multi company setup.
After this commit:
- only the tags from the current forum will show up and be selectable
when creating a post.
- it will be possible to create a new tag for a forum is another forum
already has a tag of that name
- the tag on the post (next to its title) will not redirect to the
incorrect (and possibly not accessible) forum
Note that the method was already reading multiple properties of `self`,
it was already not an `api.model` method anymore.
closesodoo/odoo#94917
X-original-commit: 4ff52d0b9a71d3072f5973d8e900d802e6b129c0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: hoangtiendung <hoangtiendung070797@gmail.com>
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Users with 30 karma cannot use images in their forum post
Steps to reproduce:
1. Install the Forum app
2. Change the portal user's karma to 30 (you can use this command in
psql: `UPDATE public.res_users SET karma=30 WHERE id=7;`)
3. Connect as portal
4. Go to the forum and create a new post
5. Add a title and an image to the post and validate it
6. An error message is displayed preventing the user from posting the
image even though he should be able to
Solution:
Adapt the condition on the user's karma
opw-2648770
closesodoo/odoo#92556
X-original-commit: 43c2cbab6947628f58b5edc33d618e50d927f624
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Currently all iterations share the same dictionary. We have to copy the
default dict in order to have a distinct copy for each id in the loop.
Task-2826303
closesodoo/odoo#89934
X-original-commit: ae145e0909d5f37964eace75053eadf9e8b80c36
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
website{_*}: website, website_blog, website_event, website_forum,
website_sale, website_slides
Since the generic search bar was introduced in [1] all text fields were
truncated in search results.
This caused problems for long URLs which were truncated as well, and
therefore could become invalid.
After this commit URL fields specify `'truncate': False` in their search
detail metadata, which informs the rendering to skip the text truncation
step for that field.
Also added previously missing controller-level tests of the
autocompletion.
Steps to reproduce:
- start odoo with website_forum and demo data
- go to the Help forum
- search for "configure" in the Help forum
- click on the auto-complete suggestion
- => redirected to a 404 page because the URL was shortened
To test the fix on other models, use a long enough name that causes the
problem. E.g.: "This product has such a long name its URL would have
been truncated without the fix contained in this branch".
Note that the problem did not occur on blogs because the URL does not
contain the name, but the same fix was applied for consistency.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2727788
closesodoo/odoo#82621
X-original-commit: 045f741be35e62f5e3a636490c6c1d475b5d78eb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit the `_search_get_detail` result contained callback
functions to handle special behavior during fetching and rendering.
After this commit a `website.searchable.mixin` is introduced that must
be inherited by models that participate in website-based searches.
Custom behavior previously achieved with callbacks is now achieved by
overloading methods of this mixin.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
(*: website_blog, website_event, website_forum, website_sale,
website_slides)
Before this commit the search bar was specific to products.
After this commit a generic search bar is available as a general feature
of website which can be configured to inspect specific models.
The snippet is used to replace the old search bar in blog, courses,
event, forum, page and shop.
The search results of these pages and the autocomplete of the search bar
run through the same search mechanism.
A new hybrid results page has also been created as a target of a search
on "Everything".
In each involved module, `website._search_get_details()` is implemented
to return search metadata for every model related to the `search_type`
parameter.
Search metadata for a single model is returned by `_search_get_detail()`
on that specific model.
The autocomplete runs through the additional
`website._search_render_results()` pre-rendering step that prepares the
data to fit in the autocomplete template.
task-2379555
https://github.com/odoo/odoo/pull/65871
Part-of: odoo/odoo#65871
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
The configurator takes care of the organization of the links to the different
pages. Some links are put in the menu and some are put in the footer. The order
is predefined. If too many links are present in the menu then a sub-menu 'Company'
is created and some links are put in it. For the 'News' and 'Succes Stories' features
a website specific blog is created.
Links have the following order in the menu and are present only if their corresponding
website.configurator.feature has been selected in the configurator excepted for the 'Home'
and 'Contact us' links which are default links:
- 'Home'
- 'Shop'
- 'Event'
- 'Courses'
- 'Services'
- 'Pricing'
- 'Company': if more than 8 links in menu and more than 1 item in this submenu
otherwise the three following links are in the top menu.
- 'News'
- 'Success Stories'
- 'About us'
- 'Appointment'
- 'Contact us'
Links in footer:
- 'Privacy Policy'
- 'Help': if website_helpdesk installed. This is not a website.configurator.feature.
- 'Forum'
Community: https://github.com/odoo/odoo/pull/71993
Enterprise: https://github.com/odoo/enterprise/pull/18930
task-2518565
Co-authored-by: Sébastien Mottet (oms) <oms@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
This commit changes the sanitization of the welcome_message to be on par
with other modules that take advantage of web_editor.
Part of https://github.com/odoo/odoo/pull/67140
task-2381049
Rémy Voet (ryv)