Before this commit, we create a new dynamic action when creating a new
project. This is a problem for various reasons:
- we did not have the nocontent helper properly set (so, the kanban view
could not display the help message just after creating a project
- the dynamic action is slightly different from the one you get when you
click on an existing project (different views, ...)
- the dynamic action is not editable in studio
With this commit, we simply reuse the same action, but with a different
context. This solves all these issues at once, without duplicating
logic.
This merge changes the templates used to send notification emails. They
are currently defined as mail.template using jinja. We choose to make
them QWeb views. There are several reasons to do so
* those are not real mail.template records. Indeed they cannot be used
outside of the notification process as some values are computed
and not available on the mail.message record used to render the
template;
* we do not really need other fields than body. Indeed fields like
subject, email_from or email_to are computed from the notification
process;
* we do not want people to update the mail.template without knowing
the consequences, especially for fields like recipients that may
broke the mail gateway;
* using the html editor easily break the mail.template as it is very
custom and very to break without really realizing it.
It also simplifies template management as it lessens number of mail
templates people have in their list view of mail.template. It avoids
mixing technical and functional templates.
We move to QWeb templates as those are not too hard to customize and
allow to perform body rendering which is what we really need when
notifying people of a new message.
This merge also factorize the "custom layout" used in several addons
to use a single secondary template defined directly in mail. Indeed they
are using the same template. Therefore having it defined only once helps
editing or fixing it.
Please see sub commits for more details about the merge.
Purpose of this commit is to perform a light cleaning of the email
notification process. It renames method by prefixing them by _notify
in order to easily spot them. It also makes them private because they
should not be called outside of other methods. Indeed those methods
are technical and do not provide useful information to external
people.
Future commits will probably improve the notification process in order
to clean it and try to reduce its query count.
This commit perform the following renaming
* message_get_email_values -> _notify_specific_email_values
* message_get_recipient_values -> _notify_email_recipients
* _message_notification_recipients -> _notify_classify_recipients
* message_get_reply_to -> _notify_get_reply_to
Purpose of this commit is to add a new parameter to message post that
is the layout used when sending notification emails. It will soon
replace the context use of custom_layout in some case. It will also
allow to control a bit the notification process from the message_post
API in more or less planned future mail updates.
This commit also slightly changes the way notification process handles
deleted or unknown rendering templates. Before this commit any missing
custom template was replaced by the base template. A missing base
template was leading to a crash. Now it simply logs a warning and avoid
crashing.
The ColumnQuickCreate widget is now automatically open when
entering a grouped Kanban view with no column. Moreover, the DOM
of the quick create has changed. The tour had to be adapted
accordingly.
The goal of this rev. is to improve the user onboarding on the
Project app: when the user creates a new project, he is now guided
to properly configure the stages of its project.
To do so, we added a new mechanism in the Kanban view, allowing to
define examples of processes that can be used in the corresponding
view.
The style of the ColumnQuickCreate widget has also been changed.
Part of task #38740
This rev. defines form views to use as quick create views in the
kanban view of models 'crm.lead', 'hr.applicant' and 'project.task'.
It uses a newly created mechanism allowing to specify a form view
xmlid in the Kanban arch, such that the referenced view is rendered
inside the QuickCreate widget (see parent commit).
Task #27475.
We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
Purpose: When running tests, all the tests for the installed/updated
files are done. This commit adds a 'tagged' decorator that can be used to
tag tests. Combined with a new 'test-tags' CLI option, it adds the ability
to filter which tests are executed. For example, @tagged('slow') will
add a tag 'slow' to the test. The CLI option 'test-tags="slow"' will
only run tests tagged 'slow'.
One can use prefixes to select cases with tags.
'+' or no prefix means that the tests tagged with this tag are selected
for execution. '-' prefix will exclude the tests tagged with this tag.
Exclusion takes precedence over inclusion.
Also, by default, all Odoo tests cases are tagged 'standard' and with
the technical name of the module.
This means that when selecting tests with the 'test-tags'
parameter, if '-standard' is not specified, all tests tags are
going to be executed.
When tagging tests, one can remove such automatic tag by prefixing the
tag name with '-'. E.g. @tagged('-standard') will remove the standard
tag from the test.
Another example, if one wants to test the 'sale' module alone,
even without adding any 'tagged' decorator thos tests can be selected
like that: --test-tags="sale"
Tests are selected or deselected using a TagsSelector. When instanciated,
a string is passed with comma separated tests selectors like
'+slow,-standard'. When the 'check' method is called with a test as argument,
it returns True or False if the test has to be executed or not.
Add contraint to limit the level of subtask to
only one. A task can either be 'mother' or 'child'
but not both ! For now, the UI only prevent this,
but xml rpc script can do whatever it wants.
Also move the recursive check from hr_timesheet
to project, since subtask mecanism is now native
from project module.
This commit aims to improve duration field calculation
with subtask. So this commit :
- provides `subtask_planned_hours`as the total of planned our from
children tasks
- removes useless/unclear fields : delay_hours and total_hours
- makes progress computation independent from the stage (before,
progress
of task in fold stage was 100%)
- split the `hour_get` compute method into smaller ones in order to
improve
performances and code readability.
- makes 'progress' and subtask effective hours not including allocated
hours
Task: 38498
This commit improves subtask mecanism, on several points:
1) Drop the project constraint: before this commit, creating
subtask in non parent project was not possible. Now you can move
subtask to any project.
The default project of a subtask is the one from the parent.
2) When setting a parent task, we want to force some field to have
the same value as its parent, like `partner_id` or the `sale_line_id`.
The idea is here, we work for the same client; a subtask count for the
same goal (SO line or customer). Those fields should be readonly on the
view.
3) Refactor some methods
Task: 38498
Purpose
* move notify in message_post instead of always doing it at message
creation
Specifications
* message create should only create a message
* message post should be in charge of calling the notification process
Thread mixin class adds a message_last_post field. This field may be
updated when a comment is posted, depending on a context key. Since a
while this context key is not used anymore. This means the field is never
updated. As it is used only as a filter in project we decided to remove
it.
This commit remove the field and the context key support. This kind of
specific feature can be done using customization if necessary in some
advanced use case.
First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.
Also including :
* ease default computation for res_model_id of activity types: using
default_res_model in context it is possible to specify a default
res_model_id. It is useful for example to give a specific context
in configuration menus;
* add a domain on res_model_id field in order to limit it to models
inheriting from mail.thread and not being transient;
* various improvement in activity type form view to ease configuration
notably the # days renamed to planned in;
The regional variations are not published on Transifex and hsould be translated
manually.
The translations are mainly from previous versions or contains buggy fuzzy
translations (not matching the real source string).
Clean based on the .pot and delete the empty files
Fixes#21733
Purpose
=======
In a business point of view, it make no sense to merge record. if someone want really to merge record they have to do this manually to think about all corner case. What about id sent to the customer ? what about timesheet ? what about business ?
The idea of the task: remove this feature in both app, project.task and in helpdesk
Specification
=============
Remove both features
"Merge Selected Tickets" in helpdesk
"Merge Selected Tasks" in project.task
Displaying the rating of project is moved directly
in project module, since it does not depends on website.
User may want to display rating of its support project
even without website.
Christophe Simonis