Before this commit there were few cases in which
is_html_empty method was not working as our expectation.
In cases such as "<p class=""><br/></p>", "<p id=""><br/></p>"
and many other cases.
In this commit we improves regex of is_html_empty method.
Mow from this commit all kind of attributes will be consider
in this method.
In this commit we also have added is_html_empty in mail template, portal
values and in report values also for rendering templates.
Task id: 2499504
X-original-commit: fd0a05f2955b9f7e9ae7233afebfd6240c9244dd
Mail holds a "Pay Now" notification template holding notably customized
links to portal for records like sale orders or invoices. It allow to
give a more personalized button than a plain simple "View document" link.
Currently frontend / backend links are not always correctly computed in this
template. This commit fixes that behavior.
Task ID-2513724
COM PR #69607
ENT PR odoo/enterprise#17849closesodoo/odoo#69714closesodoo/odoo#69744closesodoo/odoo#69774
X-original-commit: c417ea6243cb968d17f5db0919ec8cd034f4cb5f
Related: odoo/enterprise#17889
Related: odoo/enterprise#17902
Related: odoo/enterprise#17916
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to fix computation of access link. In some cases
msg_vals modification leads to invalid URL computation, notably for frontend
or backend differentiation for target recipients.
Followup of odoo/odoo#63292 .
Task ID-2513724
COM PR odoo/odoo#69607
ENT PR odoo/enterprise#17849
X-original-commit: e618597876692f2d24f8e9308c747b8d1f2d8905
PURPOSE
Notification may be sent using a generic mail.thread record, notably when
sending user notifications. In that case links to view document are
incorrect.
HOW TO REPRODUCE
Issue
- Install "Approvals"
- Submit new approval with you as "Request Owner"
- Click on "View Approval Request" in your mailbox
The link redirects to a 505 error
Cause
The model is not the correct one and the res_id is undefined
Solution
Specify the model and the res_id to _notify_get_action_link
when creating the link with kwargs
SPECIFICATIONS
Propagate message value through various notification sub methods. That way
we can rely on them if model seems void.
Also limit values given as URL parameters to some white listed values.
LINKS
opw-2358846
Task ID-2379766
Followup of odoo/odoo#60998
Followup of odoo/odoo#61545Closesodoo/odoo#63292Closesodoo/enterprise#15585closesodoo/odoo#64229
X-original-commit: 58bac5d242d6548d54f0163328fa64b319852e40
Related: odoo/enterprise#15634
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Achraf Ben Azzouz <abz@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
The method _notify_get_groups is called to determine how a user should be
notified based on the groups he belongs to.
If a record is shared via portal but the model does not have a field named
`partner_id`, the method was failing.
With this patch, the presence of the field is checked first. No additional
access_token is computed if the field is not present.
Forward port of #59123closesodoo/odoo#59310
X-original-commit: 6612c7ae766e996c57bda5c4c23132797f162f1e
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, the time to compute all counters was making the rendering
of the portal page slow.
Now the count is done in rpc after the loading of the page.
Now you can decide which part you want to show on the portal, and only compute
for these one.
It is not because you have purchase installed for your internal process, that
it means that your supplier use your portal and it avoid the computation for
all end users.
We parallelize the counters in arbitrary 3 rpcs.
closesodoo/odoo#55999
Related: odoo/enterprise#12456
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Before this commit, each module override _get_translation_frontend_modules_domain
from ir.http to add its own translation in website if needed and that module
is not starting by website_. Updating the domain from the super() call.
Since we know in most of the case the name, it is useless to do a:
select name from module where name = 'name1' or name = 'name2'...
Now we support a new override of _get_translation_frontend_modules_name that will
allow to add the known module name directly in the list instead to make a search.
In case nobody override _get_translation_frontend_modules_domain, we don't need to
make an extra rpc to find the module.
Related to #47257
task-2211013
X-original-commit: 0dc54814161ab55c34dd2242f65dea23d19fdfca
from `message_format` and from `_message_read_dict_postprocess`.
The reading and initial formatting is done by `_message_read_dict_postprocess`,
which has been renamed more simply to `_message_format` due to its new goal.
This makes the methods easier to follow and does not increase the query count.
It actually reduces it when the data were already in the cache, by not always
reading them again.
Part of task-2180311
PR: #43841
PURPOSE
Clean posting process and improve mail.message definition and comprehension.
SPECIFICATIONS
Website mail defines a website_published field allowing to publish / unpublish
comments on the frontend of some modules. This field has several drawbacks :
* it is used only for front-end people (portal, public) and has no real
effect in chatter / classic discussions;
* it is used only in some advanced front-end module and is not available
in portal by default;
* its naming is not really correct as it is not linked to fields coming
from the website_published mixin and its behavior is not really
the same;
* its use is a bit duplicated with internal flag coming from subtype
allowing to hide messages related to an internal subtype;
* there are overrides of standard mail.message methods just to handle
this flag;
In this commit we change that field by an is_internal flag directly on
mail.message model itself. It tells if share people (customers, share users)
are allowed to read the message. This field can be given through posting
API or set manually using widgets. It is also used in access rights custom
methods and managed like the internal flag of subtypes.
Mailgateway was already using an internal flag for internal note replies. It
is renamed to is_internal and propagated as it is now a standard field. It
also eases code understanding.
Portal is updated to allow managing the flag directly. It means customer portal
now natively allows to moderate customer comments without any need of website
modules.
Rating is updated accordingly. An is_internal field is added, replacing the
related on website published.
LINKS
Task ID 2071556
PR #38692
Spec
====
Before this commit if a user has access to a document thanks to an access_token,
he would already be able to see the chatter for the document, but he would not
be able to download the attachments that are shown to him on that same chatter.
The goal of this commit it to let the user download those attachments. This
makes sense especially since messages publicly posted in the chatter might
generate emails to the user, and the attachments will already be attached to
those emails, so this PR is not actually granting access to more information to
the user in a typical flow.
The only difference is when said user was added as a follower after the
attachments have been posted in which case he will be able to read them even
though he didn't get the original emails, but this is consistent with how he
will also be able to read the existing messages even though he didn't get them
by email.
Technical
=========
To solve this issue we could have used the access_token of the main document,
but this would allow any user with the token to access all attachments of the
document, including those he should potentially not be able to see such as those
from internal notes.
Instead we ensure a different access_token is properly set on each of the
attachments that are going to be shown and we update their links accordingly.
This allows for a more granular access control, and it also takes advantage of
the existing /web/content route without having to adapt it.
opw-2040455
Also discussed in task-37264
closes#34384closesodoo/odoo#35121
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Co-authored-by: Pratima Gupta <pgu@odoo.com>
Co-authored-by: Sébastien Theys <seb@odoo.com>
Create a quotation and send an email to the customer, let the customer
reply by email, as a portal user go on the portal view of that
quotation, he does not see the emails.
opw-2008653
closesodoo/odoo#34611
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit fixes multiple issues regarding the /shop/address and /my/account
forms where both are displaying `vat` and `company_name` fields.
1. For a company's child partner, the `company_name` was empty instead of
showing its company name (the name of its parent_id which is the commercial
entity).
2. It was possible for a child partner to edit its `vat` (which is a field
synced from parent to children, but only parent should be able to edit it as
it is the commercial entity, see 4a1bc45934 and 98b1fffd4e).
3. Company name now share the exact same condition than the vat field in order
to be editable (as it should have been). It was possible to edit vat but not
company name on /my/account.
Steps to reproduce the bug:
- Create a company contact CO with a VAT number
- Create a contact C in CO with portal access
- Log with C and go to the shop
- In the checkout, try to edit the address details
opw-2007368
closesodoo/odoo#34564
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* http_routing, portal, rating, survey, website, website_survey,
website_slides_survey
Before this commit, the final base layout of website was a fully
overridden layout of the one in portal, which was somehow a duplicated
one of the login one in web, which... so lots of duplicated code.
This commit is a first step towards a better organization:
1) The web app defines a frontend layout (to include base frontend
assets), with a base company logo as header.
2) The portal app modifies that layout in place to include the base
header, footer, ... It also uses a primary extension of it for
portal pages.
The survey app simply uses the above layout instead of defining its
own (by primary extension to include its own assets for its own
pages)
Same goes for the rating app and pages.
3) The website app modifies that layout in place to include the UI
assets, to add website UI, ... This allows to create frontend apps
which do not depend on website, with a non duplicated layout that
will be automatically adapted if website is ever installed (this
therefore allows to get rid of website_survey definitely)
This commit also fixes the session info system and the translation URL
on the frontend side to not require to redefine the whole session_info
for portal, website, ... Now the frontend session_info is defined in web
and http_routing extends it to add translation informations, then
website extends it again to add its own elements (not to redefine them
all as before). Note: before, http_routing defined the translation route
but only portal was adding it in its layout...
This is an adaptation of the work that was done with commit
https://github.com/odoo/odoo/commit/99821fdcf89aa66ac9561a972c6823135ebf65c0
Note 1: Many frontend but non-website apps (not only survey / rating)
could probably use this too but this would be the topic of another task.
Note 2: survey currently depends on http_routing but does not add itself
in the list of frontend apps to translate, it probably should.
Note 3: web_editor does currently not depend on http_routing but does
add itself in the list of frontend apps to translate, it thus uses a
function it does not really depend on... to check after its work-in-
progress refactoring.
task-1961045
closesodoo/odoo#33825
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Purpose of this commit is to clean notification process: calls, methods
API, method name, variable propagation.
Contains notably
* simplify API of methods used to group recipients when sending notification
emails;
* improve and rename methods used in email notification process;
* move some methods on model itself as non mail thread records could be
mass-mailed and _notify_email_headers could be called on other records;
Related to task 1943901
Linked to PR #32404
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'`
Before this commit, when we want to make an external url, we need to know
if the record is related to a specific website or not, and choose base_url
or website domain.
Now each model have a fonction get_base_url (public to be callable from email
template, ...) and website override this function to add the website domain if
the record is website specific.
closesodoo/odoo#34089
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The field website_published is not ensured when module portal
is installed because the module portal doesn't depend on module
website_mail.
PS:The module website_mail depends on the module portal because
website_mail depends on website and website depends on portal.
opw:1997478
closesodoo/odoo#33452
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Generate a unique URL for translations and cache them forever in the
browser. This reduces the number of requests, in exchange for computing
the hash of the translations when the session object is added to the page
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
Before this commit, it was possible to post a message on a document
the user has no access, thanks to a token. In addition to this token,
if a hash (signed token with a partner id), the author_id of the message
was forced.
This commit change a little bit that logic by distinguish 2 cases:
1/ Token only: anyone with the token can post a message on the document. If
the user is not logged (public with token), the author_id will be the
customer of the document (or the public user). This case is moslty used
for business document, through the portal or with the "share link" for
instance.
2/ Signed token: user has no write access to the document, but can post a
message on it. The user have to be logged, as the token is signed with its
identifier. The goal here is to avoid leaking the access token's document
to all visitors. This case is mostly used for public content, such as blog
posts, slides, ...
The token case was already existing. The second is now working with this
commit. To do so, it was required to
- move `_sign_token` from the portal mixin to mail.thread.
- transfering 'pid' and 'hash' parameters from the controller to template
to js widgets.
This commit also change the `_message_post_helper` signature by making
the 3 first parameters required, as to post a message you need at lease
res_model, res_id and the message body. The optional argurments and kwargs
are here to check the bypassing access rights mecanism.
Task-1902304
- The value returned by the method `_portal_ensure_token` is False due
to a cache issue.
The value is generated written using the `sudo` environment while in
the current user environment the cached value is `False`.
After generating the value, the cache is not cleared, thus letting the
method return `False`
closesodoo/odoo#28836
Allow to generate an access token even on records where the portal user does not
have the write access.
e.g. a customer can access its invoices but is not allowed to modify it
Fixesodoo/odoo#27454closesodoo/odoo#27455
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
The goal of this commit is to fix the various views and reports of sales and invoices.
======
Portal
======
Fix breadcrumbs
Fix BS4 issues, alignment of various elements
Better auto resize of the invoice iframe
Fix invoice list for draft invoices
Fix previous/next document pagers
Remove unnecessary monetary widgets (not needed when using t-field if the field is Monetary)
Standardize invoice and sale routes:
- especially when related to displaying: html, pdf (print and download), text
- by using the get_portal_url() also for invoices
Add the total on the left column of sales order
================
Section and note
================
Improve general style:
- notes in italics
- sections: less padding, darker background, no borders
=========
Demo Data
=========
Fix sales order demo data to appear for the admin (instead of system)
PR: #25997
task-1869469
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.
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes#25629
web (tagged with `openerp-web`) translations are loaded in the backend, in
`odoo.addons.web.controllers.main.WebClient.translation(mods=None, lang=None)`
method (through `/web/webclient/translations` controller).
In website, the controller `/website/translations` is called used, fetching
the translations from modules with the (fragile) clause `name ilike 'website'`
This commit fixes two bugs:
1. Install `website_sale`, activate discussion on products
-> the chatter is not translated as the portal translations not loaded in the
`/website/translations` controller
2. Install `helpdesk` but not `website`, go to portal view of a ticket
-> the heldesk chatter is not translated as the `/website/translations`
controller is not called (only provided by the website module)
This patch implements a modular approach to translate the web resources of the
right modules only.
The controller /website/translation is moved to http_routing and each module
override the new _get_translation_frontend_modules_domain method to adds its
translatable module
Closes#23618Fixes#23610
This commit prevent VAT and company name edition if an user has already at
least one document (SO or invoice) for his partner or his related company
partner.
Any module can override this feature to add their own condition to prevent
campany name/VAT edition.
task-33088
Closes#23420
This commit renames some internal mail.thread methods linked to the
notification process. This is the next commit of a series aiming at
improving code readability and method finding through prefixes. See
notably cae1c3977f, cdfe479e2e and fc1348dd3d.
This commit does not change any functional feature. It does only
rename notification-related methods, using the _notify prefix to
ensure they are private and to mark they are part of the notification
process.
Purpose of this commit is to allow customer portal to have an access link
containing an access token. Portal mixin now override the default mail.thread
behavior when classifying recipients of a notification email in groups.
If the model has an access_token and a customer field correctly defined
the recipient that matches the customer will have an access link in its
notification email holding the access token. It will also contain an
auth signup token if it is enabled.
After removing the `sha_in` params a while ago, we get rid of
the deprecated `token_field` option.
- Make `token_field` a model attribute, so that each model can easily
define the token field that should be used, and it does not need
to be passed around all the time anymore.
- Rename `_special_access_object()` to `_has_token_access()`, much more
readable since it returns a bool
- Do not forward the `attachment_ids` keyword arg to message_post,
as it sometimes contains unrelated IDs (the helper is not meant
to post attachments anyway)
- Update callers accordingly
This mixin holds the replacement for website_published.mixin
website_url field. This field is called portal_url to avoid confusion
with the website and enforce the new portal use.
It also contains get_share_url method that will be used to generate
the URL to use in emails or various communication for customers.
dht-odoo