Adjust the height of the HTML field for the email body
On the survey sharing email.
Regression introduced in 607c5ea4 (#75863)
task-2586137
closesodoo/odoo#76016
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Define `data-hotkey` on most used action buttons.
For the modals, the following keys are dedicated for "special"
actions:
- Alt+G: add
- Alt+V: save
- Alt+Z: cancel
closesodoo/odoo#73275
Taskid: 2588233
Related: odoo/enterprise#19464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
In this commit we fix some glitches in slide invite process
* prevent from sending without recipients as it makes no sense;
* hide Invite link in kanban like Invite button on form view, when not
being invite-based;
* fix small issues in various templates, notably escaping in subject;
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
Using this mixin allows to hide details about jinja-based computation for
main fields used when posting messages or sending emails. Notably subject
and body computation that was duplicated in several addons are now done
in a mixin. It also eases their maintenance or evolution when qweb rendering
will be available. It also eases support of lang when necessary.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
UPG PR odoo/upgrade#2496
To reproduce the error:
Create a survey (title must contain ") and send it
Error:
The mail subject is incorrect: the character " is replaced with "
OPW-2536206
closesodoo/odoo#71388
X-original-commit: 37cea376cc2069388b07b91f50caa6044fa6c932
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Purpose
=======
Some computed stored editable fields are computed in the same method.
In that case, when one of the value is provided in a create / write call,
the computed method is not called and other fields computed in the same
method do not have the right value.
Task 2377119
COM odoo/odoo/pull/65772
ENT odoo/enterprise/pull/16221
X-original-commit: c9c64fa740fea31964f433a05d37a0f869b8e9d3
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
render, render_template, load, activity_schedule_with_view,
get_website_pages should all be private:
It should not be possible to render an aribtrary template only with
its name or id
Still need to render some qweb views from js so the method
render_template is kept public.
This explains why the website editor still need read access on
ir.ui.view as we want to allow any snippet to be rendered.
Issue
- Install Survey & Contacts
- Have 2 contacts with the same email address
(e.g. test@example.com)
- Create a survey, send it only to that
email address
Email sent 2 times
Cause
When looking for partners linked
to that email address, we do not
provide any limit so the system
send the email to all partners
found.
Solution
If I set one email address,
I expect one email to be sent.
So, the solution would be to
apply a limit of 1 when login
is not required.
OPW-2247693
closesodoo/odoo#51155
X-original-commit: 55b1cc3108d6b672f10ece26db7e13a65ff655d3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
PURPOSE
Try to move from onchange / default_get to stored editable computed fields.
Behavior should be the same (computed or set by user), with support of
create / write / onchange field update without additional code.
SPECIFICATIONS
Update classic fields updated in some cases by onchange and/or default methods
by fields with store=True, readonly=False. It means their value comes either
from manual user input, either from trigger based computation.
Remove onchange and default_get when possible, leading to an unique computation
method and clearing fields definition.
Also clean some fields definition inconsistencies, notably required fields
that should instead be correctly computed or default that have no real meaning.
SURVEY USE CASES
- On survey.question, the question_type field should be emptied if the question
is a page (is_page = True)
- On survey.survey, if scoring is configured, the minimum scoring success
should be between 0 and 100 (added SQL constraint).
- On survey.survey, the certification field cannot be True if we're in no
scoring mode (scoring_type = 'no_scoring')
- On survey.survey, the attempts number cannot be limited (is_attempts_limited
is False) if the access mode is public and the login is not required.
- On survey.survey, we cannot give a badge (certification_give_badge is False)
if it's not a certification or if the login is not required.
- On survey.invite, the "subject" and "body" field are based on the template
used (template_id field).
MISC
- As "validation_email" works with "validation_required", we removed the
onchange on "validation_email".
- To avoid extra complexity with an onchange on "is_time_limited" and
"time_limit", we simply default the time_limit field to 10.
LINKS
Upgrade PR odoo/upgrade#847
Task 2187377
closesodoo/odoo#46291
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Move links shortening tools on mail.render.mixin to have rendering and
post procesing tools available on that mixin.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
We also have to update code calling directly the rendering itself. Indeed
some code bits does some rendering directly on jinja-enabled input and not
through templates. Those calls have to be updated accordingly.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
As new features are about to land in survey, notably live interactions [1]
and new survey building [2] performing a pre cleaning is necessary. In this
PR we clean survey models by: removing unnecessary fields, cleaning some code
and finally renaming models.
SPECIFICATIONS: QUESTION FIELD ON SURVEY.SURVEY
On survey.survey, remove question field, unnecessary related on title.
Question model holds two fields for its title: ``title`` and ``question``.
Question is simply a related on title, making the two fields completely
redundant. It is mainly due to historical reasons, when updating models for
certifications and eLearning. In this commit we keep only title field and
remove the question related field as it adds unnecessary complexity to the
model.
SPECIFICATIONS: INPUT_TYPE FIELD ON SURVEY.USER_INPUT
On survey.user_input, remove input_type and its garbage collect.
``input_type`` field exists on user input model to tell whether answer has
been created through invite or through manual click on a survey page. It
has been added a long time ago when surveys were either open to everyone,
either closed and on invite only.
Since eLearning and certification surveys access mode on surveys has evolved.
Notably being able to distinguish invite from manual survey user input is not
necessary anymore. Indeed what is important is the way people can reach the
survey, not how they created their user input.
Invitation creates token and this can be used if people effectively want to
find invitation-related user inputs.
Since 09ea5c7d49 manual entries still in draft are garbage collected.
Reason is still unclear as it is not obvious that tons of unnecessary entries
will be created. As this seems like unnecessary optimization this commit
removes that feature along with the input_type field.
SPECIFICATIONS: REPLACE URLS FIELDS BY METHODS ON SURVEY.{SURVEY, USER_INPUT}
On survey.{survey, user_input}, remove url fields replaced by methods
In this commit we remove some remaining of URL fields that are better found
using methods. Both survey and user input holds a "start" url field that is
replaced by a method call ``get_start_url`` on both survey (generic) and
user input (token specific) models. We also introduced a ``get_print_url``
method doing the same for the printable version of survey / user input.
SPECIFICATIONS: REMOVE CATEGORY FIELD ON SURVEY.SURVEY
On survey.survey, remove unused category field.
Survey model holds a ``category`` field whose purpose is to be able to somehow
categorize surveys according to their use. However using this field is not
easy as it is hidden and is a simple selection field. Module should add their
own key. Its sole use is in ``hr_recruitment_survey`` which is a niche module.
Let us clean models and lessen model complexity.
LINKS
[0] Related to Task ID 2061901 (survey models cleaning and preparation)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
PR #40765
PURPOSE
Purpose is to perform some cleaning in survey models: naming, ordering,
dead code [0]. As new features are about to land in survey, notably live
interactions [1] and new survey building [2] performing a pre cleaning
is necessary [3].
SPECIFICATIONS
Code move main points
* move fields to have them grouped by main use;
* move methods to have them grouped by main purpose;
* reorganize some line breaks to ease reading files;
Globally this code move is done according to our famous guidelines.
No functional changes should occur with this commit. It contains only
code move, not any change at all.
LINKS
[0] Related to Task ID 2144393 (surveys split / cleaning)
[1] Task ID 1972640 (live interactions)
[2] Task ID 2119587 (new frontend for building surveys)
[3] Task ID 2061901 (survey models cleaning and preparation)
PR #40623
[PEP 594] is going to depreciate the legacy `email.message.Message` API
and its related modules. Among them the `email.utils.formataddr`
function, this function takes a `(name, email)` pair and returns a
string value suitable for From, To and Cc headers.
The stdlib function is capable of handling several character encoding
and two binary-to-ascii encoding. Odoo only uses `utf-8` which is
compatible with the base64 b2a encoding. The re-implementation of that
function has been simplified to only support base64-ed utf-8 and ascii.
[PEP 594]: https://www.python.org/dev/peps/pep-0594/\#email-lagacy-api
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'`
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
As both `survey_url` and `public_url` are `Char` fields, the correct widget
to use is `CopyClipboardChar` (`CopyClipboardText` is for `Text` fields).
This was causing a display issue (the style of mentioned widgets is different).
Task 1935577
closesodoo/odoo#31624
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Task #1902306
Purpose
=======
When you invite people to take a certification multiple times, the user will have his "attempts" count reset
with every invitation.
This is important when there is a limited number of attempts available.
ex: A user invited twice will have 2 x allowed_attempts_count to succeed the survey.
Attempts are now separated in different pools using a "invite_token" field on the survey.user_input.
Purpose of this merge is to clean the way we manage exiting answer when
inviting partners or emails to participate to a survey.
When wizard finds that some recipients are already linked to answers it
displays a bootstrap warning with the name of duplicate recipients and
display the field allowing to choose between two options
* resend: send the same token and answer;
* new: create a new token and answer;
It will be useful notably with certifications support as number of attempts
to succeed is limited. Allowing people to retake certifications should be
made clear to survey managers.
This commit is linked to task ID 1935176 and PR #30689 .
A field exists to differentiate answers done manually through frontend of
survey and answers created through invitation. The field was not correctly
set by the invite wizard. This commit fixes it.
This commit is linked to task ID 1935176 and PR #30689.
Purpose of this merge is to improve access mode and authentication management
introduced at 9771fdfe8f . Purpose of this cleaning is to simplify options and make
them clearer. Instead of a selection with 4 entries we propose to use two
fields on survey model :
* access_mode: everyone with a public link can access and answer; or only
invited people;
* login required: whether people have to login to answer or not;
All main use cases are covered with combination of those two options.
This commit is linked to task ID 1932508 and PR #30508.
Purpose of this merge is to remove the ugly __URL__ hack of survey templates.
It is solved by making template rendered on user_input model. This means each
invitation recipient will received its own rendered mail. Small jinja code
allows therefore to include the url in a clean odoo-style way.
Subject and body in survey invite wizard are not rendered anymore. It means
jinja could be displayed. This is necessary as this wizard will work in batch
mode, rendering the body on each recipient.
This commit is linked to task ID 1911586 and PR #28986.
Purpose is to clean and simplify invite wizard on surveys. Main purpose is
to simplify options.
Public link is displayed for public surveys, allowing to quickly share
it. When sending emails a token is now generated for each recipient. There is
no "batch public link" sending option anymore as it is not really necessary.
Check is done on recipients and emails to match the access mode option. Having
a restricted survey gives the same limitations on people to invite (users,
employees, ...).
Code is cleaned to ease its understanding and prepare future evolution notably
with appraisals.
An existing mode field is added on invite model. All options are currently
not used but it prepares future addition to survey, notably for certifications.
Its purpose is to know what to do with existing tokens when inviting new
recipients. It is used notably to resend tokens through the user_input form
view instead of relying on a custom context key.
This commit is linked to task ID 1911586 and PR #28986.
This commit holds several improvements on survey models.
[IMP] re-order fields in survey models and update strings / helps
Purpose is to ease understanding and future modifications of survey models
by reordering fields in survey, question and user input models. Those are the
main models we want to clean in future updates.
Some comments have been moved into help and some labels and helps have been
updated to clarify a bit the use of various fields, notably in question model.
No functional or technical change occur with this commit. It is just pure
code move. Reordering them allow to already understand a bit more the logic
of this module.
[REF] survey: remove unnecessary/unused fields on answer models
Purpose of this commit is to remove unnecessary and/or unused fields on survey
answer line model. In this commit we
* remove useless date_create field on answer and answer lines models. This
field is basically a renamed create_date. Let us remove this dummy field
as it adds nothing to the answer and answer lines models;
* remove useless URL-related fields and actions on answer and answer lines
models. Having those fields actually bloats the model without really helping
understanding survey models. As changing routes should not occur frequently
hiding routes in fields does not really help. Templates are update to
directly include links instead of fields;
We also remove a button on user input that redirects to the survey global
results. Surveys results are available on survey kanban and form views. It
makes no sense to have that kind of button on a specific answer.
[REF] survey: remove unnecessary/unused fields on survey models
Purpose of this commit is to remove unnecessary and/or unused fields on survey
model. In this commit we
* remove useless is_designed field on survey model. We remove is_designed
field that is based on having page and/or questions. It is just used to
make some links inactive in kanban view. Having fields just for that
purpose bloats the model and is not necessary. Testing void surveys will
just lead to a void page;
* remove useless email_template_id field on survey model. This field is
completely not used anywhere in survey codebase;
* remove useless urls field in survey model. In this commit we remove support
of both relative and global urls computation. It was used only in invite
wizard but was actually not really necessary as knowing the survey access
url is the only really necessary thing to display;
* Print and results URLs are removed from survey model. Having them inlined
directly in code is simpler that actually hiding them behind field. As
changing routes should not occur often it is not a big deal to write them
when necessary. We therefore remove public_url_html, print_url and
result_url fields;
This commit is linked to task ID 1911586 and PR #28986.
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
Purpose is to have a somehow cleaner name for this wizard as its purpose
is to send invitations. Email and composer are details on how it works.
This commit is linked to task ID 1909804 and PR #28783.
Purpose of this commit is to clean survey composer model. It currently
inherits from mail.compose.message which also inherits from mail.message.
That means a lot of fields and behavior coming from both models are present
on the survey composer. Most of them are not necessary as
* send_mail method of mail composer is overriden and super is not called.
Nothing from the complex behavior of mail.compose.message is used;
* templates are just basically supported in survey, notably mass mailing or
mass posting mode are not used;
* methods from mail.message should not be available on survey composer;
* most m2m fields coming from mail.message and composer have no use here;
In this commit we simply add the required fields and template behavior on
the survey composer and remove inheritance on mail.compose.message.
This commit is linked to task ID 1909804 and PR #28783.
Purpose of this commit is to rename some files before going into some more
work. No split or cleaning is done here, only preparing by doing some pure
renaming.
No functional behavior change should occur with this commit. Only move
has been performed.
This commit is linked to task ID 1903617 and PR #28166.
Purpose of this commit is to rename type column to something matching the
the real business use of the field. That way it is easier to find and grep
in the code. It also lessens potential conflicts with type build-in python
function. It also lessens conflicts when using the field in JS as type
is a build-in attribute.
Renaming type column is a long-living issue. We choose to do it at the
beginning of the v13 development to catch errors as soon as possible.
This commit is linked to task ID 1896245. It is also a subpart of community
PR #27599.
In this commit we improve templates used in survey. Purpose of this commit
is to have templates that embed or use standard Odoo email layouts to make
them look modern and have a common style across all emails.
Main guidelines
* better use of div / p / br to try to lessen layout issues, especially
when updating templates using the editor;
* correctly sequence the templates fields definition;
* correctly set templates values notably auto_delete and user_signature
fields to avoid confusion;
* correctly layout the email content using light notification email. It
can either propagate the layout choice through various send mail methods
or directly embed the styling in the templates for more technical or
complex templates;
* use email_formatted computed field when possible to avoid having hand-made
from / to addresses;
* fix various typos and improve subjects when necessary;
Content of emails is not necessarily updated as the purpose of this task is
about styling, not content itself.
This commit is linked to task ID 1843224 (and 1868112) and to PR #25313
(and #25889).
This commit adds possibility to add a notification layout when sending
an email in survey using their specific composer. Purpose of this task is to
allow to send some technical template-based emails using the default
notification layouts defined in mail. It allows to avoid redefining the whole
layout in the template itself. This way email body content is simpler.
This commit is linked to task ID 1843224 (and 1868112) and to PR #25313
(and #25889).
Purpose
=======
The Contact form is one of the most used/important view. It is quite
important to find the piece of information easily and to navigate in
a few clicks to the related views.
Specification
=============
Stat buttons
------------
- Restructure stat buttons with the following order:
Opportunities -> sales user
Meetings -> sales users
Sales -> Sales users
POS Sales -> pos users
Subscriptions -> Subscription users
Events -> event user
Tasks -> project user
TIckets -> helpdesk user
Purchases -> purchase user
Due -> billing: user
Invoiced -> billing: user
Vendor Bills -> billing: user
Customer/Vendor Partner Ledger -> accounting: billing
Analytic Accounts -> accounting: billing
Credit Cards -> sales user
Direct Debit Mandates -> accounting: billing user
Publish
- Use better/more relevant icons
- Check that the proper access rights are set
- Remove the bank accounts stat buttons and replace it by a one2many
tree on the Invoicing page.
Fields
------
Move some res.partner fields from the "Accouting" page to the
"sale & Purchase" page:
- Fiscal positions
- Payment terms
Miscellaneous
-------------
- Remove dead code.
- Display nothing instead "Please complete customer's informations and email"
on the popup when sending an email to a contact without email address.
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
Change color #a24689 to #875A7B
Commit https://github.com/odoo/enterprise/commit/8ac1c19fac7615fecd51e670f798d13158a4e53c
changed the odoo interface violet by changing the main LESS variable
but forgot there was many direct occurences in XML/HTML/... (for
example for the mobile browser color).
Even if it's community the odoo interface violet is used at many places
(module description, XML demo data, ...).
Sébastien Geelen (sge)