This message is not linked to any real subtype and will never be notified
to someone. It creates a notification with subtype note. It is however
different from user-created notes and should not be propagated.
Tracking triggering subtypes are managed differently as they have a
business related meaning. It makes sense to notify them to followers.
This message is not linked to any real subtype and will never be notified
to someone. It creates a notification with subtype note. It is however
different from user-created notes and should not be propagated.
New record creation suck as new task or new ticket are linked to subtypes
people can follow and defined in their own module.
This commit introduces _message_log to use when logging notification-based
notes on a document. Its main purpose is to provide a shortcut to the
complex mechanism of message_post. As it is a lighter code and as it
performs less checks and value computation it allows to clearly gain
queries when logging notes.
It does
* skip the notification process completely. Side effect is that followers
following note subtype are not notified of document created and pure
note tracking. This is considered more as a fix than a feature change.
Indeed following notes means that followers want to receive notes
logged by other users. The fact that system notifications without a
specific subtypes are also notes is a side-effect of the current
implementation;
* support only notification-based notes and should not be used currently
when logging real notes as those could trigger the notification
process;
* skip access rights checks as it creates the message as superuser. It
is therefore defined as a private method and should be called within
a method where access rights are already granted;
On community runbot installing all 203 modules takes 580K queries instead
of 690 at the time of testing. It is a 15% performance increase based on
the 'all modules installation' metric.
In a distant future message_post and message_log could be merged after
some cleaning but it is easier currently to have this shortcut available.
Moreover as there are clouds on the mail module some developers prefer
to already have some optimization and code cleaning done to avoid
loosing all their hair.
This commit includes a small test. In a same distant future more tests
will probably be added depending on how mail API evolves.
Only messages as comments and email template should keep a white backround since they are not internal.
It is also enough to display fields that changed on subtypes (update message) since emails will be reworked soon and more information will be given there. The support of 'always' track can be removed. (is now considered as a simple tracked field)
The use of self.env.ref('mail.mt_comment').id add some query and the performance tests needs to be update since message_format is called by notify_by_chat. This code will be refactor later
This commits adds two tests in test_mail performance tests related to
the write operation. Indeed create a often tested but there are less
performance tests related to the write. Those two tests are
* first one is a simple write on a chatter-enabled model without any
tracking or specific feature; nothing should happen when performing
a write in that kind of model;
* second one is a write on a complex tracking-enabled model linked to
templates and auto subscription. It allows to have some figures for
real world use case.
The is_portal flag was used before to define if a group is a portal group. This is not true anymore since the default portal group should be used for this purpose. All logic associated to this flag can be removed.
TASK: 47937
Due to last commits that aim at improving Odoo performance all complex
tests of test_mail now take less queries to execute. Counters are
updated to match the current runbot behavior.
There is quite a big improvement when posting using a template compared
to other tests. As there are not enough tests to ensure all results
are correct let us stay careful by saying "it seems there are
improvements".
This commit refactors the computation of the delivered quantity
on sale order line, using a computed field and a manual field.
This quantity is automatically computed when using stock moves,
timsheet or expenses (through analytic line).
This simplify code, avoid having trigger in `create` and `write`
method of many models, ...
Once this big clean done, we wanted to go futher and clean the
reinvoice flow for analytic line (vendor bills and hr expenses)
by :
- using the reinvoice policy has it should be
- flagging sale order line generated from expenses
- clarify 'reinvoice policy' and 'can be expensed' fields usage
- erase some usability issues (with onchanges and views reoganization)
This commit also add tests suites for reinvoice flow, and
delivered quantity computation.
See sub commits for more details.
Thanks @rco-odoo for the onchange fix, and @tde-banana-odoo for its
review.
Task 40226
Since we need to set the cost price when reinvoicing
'at cost, the field should be displayed almost
everytime.
This commit is thus a partial undo of 6ba6ff8e8c
This commit adds tests for reinvoicing flow,
to check reinvoice service does not generate
task/project and delivered quantity still
depends only on analytic entries and not
timesheet.
This commit also unify tests in sale_timesheet,
by making them extend the sale common class.
They are now launched at module installation.
Since the reinvoice policy and delivered quantity fields
on SOL have been refactored, it is now time to provide
some tests for the new reinvoice flow.
The reinvoice test should be execute at install, since
delivered quantity computation change when stock/service
are installed. They should provide their own test suite
for reinvoicing flow. Here, we test the vendor bill
mecanism: setting an AA on invoice lines will create
SOL when validating invoice.
A product can be sell or expense, but for some cases the product
configuration make both flow incompatible. Indeed, when expensing
the delivered qty was computed based on the AAL total amount, and
manually editable.
Before the delivered qty refactoring, reexpensing erased the manual
value.
This came from the fact product expense policy is wrongly used: the
delivered qty of expensable product is not manually editable, which
is a problem for milestones (and other consumable product when stock is
no installed).
The new refactoring of deli qty API force the expense line to be
completely
readonly, but the problem is not completely solved; we still can't sell
properly a expensable product.
To do so, the SO line must be flag as coming from an expense or vendor
bill, and the reinvoice product policy should only be used to calculate
the price of new SO line.
This commit:
1) reinforces the readonly caracter of expense SO line, by making the
expense policy independent of the computation method for delivered qty
on SOL.
2) prevents generate picking when updating ordered quantity on a expense
SOL with a stockable product.
3) allows service to sell a task with zero hours as ordered quantity.
(it still prevents task/project creation for expense SOL).
4) does not increment anymore an existing line when expensing product
at sales price and invoicing at 'delivered qty'. The only line to be
incremented will be the expense line (and not the native SOL).
Impacted modules: sale, hr_expense, sale_stock and
sale_expense.
The reinvoice policy has nothing to do with the
fact a product can be expensed or not by employee,
because of the vendor bills use case.
You can only choose reinvoice policy of your product
when hr_expense is installed, which is not very intuitive
for users. So this commit makes reinvoice policy field
always visible when sale is installed. 'can_be_expensed'
field determines if the product can be used in HR expense.
However, since reinvoice policy does not make much sense
for stockable products, we hide this option and reset
it to 'no' when sale_stock module is installed, as we
don't handle stock for those expensed products (when
confirming expense, the product is already delivered).
We want to see the related expenses from employee
linked to the current SO, even the ones having
no reinvoice policy (so no SO line created) for
reporting purpose.
We can not group them by SO line yet, it could be
a futur improvement.
Impacted modules: sale, sale_timesheet, sale_expense, sale_stock
and sale_mrp
This commit uniformizes the API of computing the delivered quantity on a
SO line for expense, manual, service and stock lines.
The delivered qty of so line can be computed differently. This is the
role of the 'qty_delivered_method' field:
- manual: the quantity is set manually, when creating or editing the
line
- analytic: handle in sale module, the quantity is the sum of the
unit_amount of analytic lines coming from expense or vendor bills
- timesheet: handle by sale_timesheet module, the quantity of a product
service with timesheet is compute as the sum of the hours of timesheet
lines linked to the SO line.
- stock_move: handle by sale_stock module, the delivered quantity comes
from the validated pickings of the SO line, for stockable or consummable
products.
When the computing method is 'manual' the value is stored in
'qty_deliverec_manual' field. This field is 'technical' and should not
really be used, as the real field to read/write is 'qty_delivered'.
To extend the mecanism of computing delivered quantity on SO line, a
module should provide its own method for 'qty_delivered_method' and extend
'_compute_qty_delivered' method to compute the effective quantity.
We fell on a strange situation in method `onchange`, where some data was
missing from cache when serializing the result. In that case, the
prefetching
overwrites so many stuff in cache that the results of the onchanges are
lost.
Don't let that happen.
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.
All those templates are basically the same except some bug fixes that
were not propagated about company. Let us use just the one we just
defined in the mail module.
Various modules use another template when sending notification emails
for some specific case. For example sending sale orders or invoices
using the 'Send by email' button encapsulates the content in a layout
different from the base one.
As all modules basically uses the same copy-and-pasted template we choose
to define another email template directly in mail.
In this commit we change notification templates used to render
notification emails from jinja-based mail.template to pure QWeb
templates.
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
template 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 commit does not change the functional purpose and layout of the
templates. Behavior should be the same before and after this commit.
* note, payment, sales_team, website_forum, website_sale(_options)
Get rid of the remaining sass files and their corresponding css files
and convert the meaningful ones to less files. Ironically, this is done
in prevision of converting all less files to scss (a sass syntax).
One sass file remains though: description.sass. This file is indeed
particular and needs more work to be correctly converted (odoo.com/apps
semi-depends on it and the file is not used in an asset bundle).
Purpose of this commit is to clean the use of custom_layout in context
in order to have more explicit argument.
Several mail.compose.message instances are called using the
custom_layout magic key. As this parameter is now managed directly
by message_post API we can remove its management in the notification
process and add it explicitly in the wizard's message_post call.
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
* note, payment, website_forum, website_sale(_options)
This is a simple renaming of sass files to less files. The real
convertion will be done in the commit that follows.
This commit adds the possibility to chose between pounds and kilograms
to express the weight field on the product. This is done so that
companies that worked internally in pounds do not have to convert their
weights back to kilograms for a consistent computation of the rates in
delivery.
We complete the general settings with the selection of the weight's uom.
Validating the setting will create an ir.config.parameter. A static
method defined on product template will return the chosen UOM.
We display "weight_uom_name" on the form view so that the UOM is not
clickable/editable because we fear user would want to edit the UOM
instead of changing it in the res config.
We move the view definition allowing to fill the product's weight from
stock to product to help the generation of the intrastat report without
installing inventory.
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.
Notification emails contain a link to the record. Before 6187ffa258
it was necessary to choose whether to display leave or allocation as
button label. It is not necessary anymore since each concept has its own
odoo model. Standard behavior is now sufficient as it displays the model
description, now leave or allocation. The unnecessary code is therefore
removed.
Notification emails contain a link allowing to follow or unfollow
documents directly from the notification email. However there are
several issues with this button
* it require people to login to follow or unfollow documents;
* it is not linked to the email;
* if the customer does not have a login it is not possible to perform
the action;
* there is no confirmation step;
This commit removes the follow / unfollow button in the notification
emails. Indeed as people have the "Access document" button there is
only one more click to perform in order to subscribe or unsubscribe.
Concerning customers adding a complete control of the follow mechanism
would be costly in term of code and access rights checks. We therefore
decided to remove this button.
It also allows to simplify a bit the notification process as there
are less parameters to take into account when grouping recipients. It
allows to lessen the number of required template rendering when sending
notification emails.
The first day of week is a cultural habit usually linked to the language. An additionnal option could be added later on the user preferences to allow a user to change the first day of the week in his calendar view.
- create new repair instead of using the demo data to make further
extensions easier
- integrate the fees testing in an existing test
- test the created moves of a repair order
This commit removes the location_dest_id on repair orders. This field
was used to move the product to a specific location after the repair was
done. It makes the usability of the repair order smoother and the user
can still make a transfer to move the product to another location
afterwards.
The user is able to specify a route on a SO line. The pull rules are
correctly used however the push rules are not apply.
This patch adds a check in order to apply possible push rules associated
to the route specified on the SO lines.
Closes#22141
Previously, it was only possible to make a return in
- the location the move was coming
- a return location that is child of the parent_location, actually
meaning a return location in the warehouse
This commit now allows making return in all return location, even one
located in another warehouses.
When trying to save an employee without working calendar, we
get an error message, since the resource_calendar_id of the
related resource object is required. To have a better error
setting the field required on view is more explicit.
We don't want to set it directly on the field as it is
a related stored field, to avoid recompute problem.
Using a working calendar, you might want to know
how much hour correspond a work day. This depends
of you working calendar. This might be usefull to
compute leave duration (half a day is not 8 hours,
but 4).
The hours_per_day field is not computed as the
average of working hour of all work day of calendar
to allow customization. By default, it is 8, as
the default attendances are the one from the
40h/week calendar.
A constant is also available to handle case where
resource calendar is not available.
*: mainly crm, hr_recruitment and project
This branch improves the RecordQuickCreate and ColumnQuickCreate
widgets of the Kanban view, in order to ease user onboarding.
The RecordQuickCreate is no longer limited to the display_name: it
instantiates a real form view, whose xmlid has to be referenced in the
root node of the Kanban arch (attribute 'quick_create_view'). This
branch already defines quick create form views for models 'crm.lead',
'hr.applicant' and 'project.task'.
The ColumnQuickCreate's main change is that it may now contain a link
leading to a dialog with examples of how to configure the columns (by
specifying a JS registry key under attribute 'examples' in the root node
of the Kanban arch, and by defining the examples to display in the
dialog in that registry). Examples have already been specified for the
'project.task' Kanban view. Several other tweaks have been done on the
ColumnQuickCreate (e.g. it now opens directly in grouped Kanban views
with no column, its style has been improved...)
Tasks #27475 and #38740.
Thibault Delavallée