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
This action was not working as the tree view has been removed
This feature was replaced by hr_org_chart module
Just display a list of the employee and subordinates
Fixes#20203Fixes#22312Fixes#22536
* 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.
onchange function getting called when modifying the 'amount' field of account.payment always changed the journal of the payment when this amount was equal to zero. This caused a bug with batch deposits, when trying to create a new payment from the tree view contained in the form view of account.batch.deposit: passed default value for journal_id was ignored.
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.
On a production database with ~10000 products and multiple stock
locations, uunning the 'Inventory at date' tales ~50 minutes. Most of
the time is spent in the loop populating `group_lines` thanks to
multiple search queries.
We get rid of this loop by selecting the stock history lines and making
the match between these lines and the `read_group` result manually. On
the reference database, the duration falls to ~30 seconds.
Based on preliminary work by amoyaux
opw-803460
In df69b5bb the aggregates of a column with currency was shown only if
records were of the same currency when a grouping was closed.
But when the list view is grouped, this would cause a number of issue:
- error if with first grouping is opened, another one is closed
- if the first grouping was closed aggregates were always shown
- the code only acts when closing a grouping
- aggregates could be shown when they should not
- aggregates could be not shown when they should
So this commit change things so this feature is ignored when the list
view is grouped.
There is also a fix so `currency_field` of the column is used instead of
just using `currency_id` that may be wrong.
note: only for saas-14 and saas-15 (feature is not present in saas-16)
opw-810835
closes#22598
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.
The result of the following:
```
float_round(2.5, precision_rounding=0.05, rounding_method='DOWN')
```
is 2.45. Instead, 2.5 is expected.
In case of the `DOWN` method, epsilon should be added, not subtracted.
In the meantime, we introduce a slight reorganization of the method to
make it clearer.
opw-805008
- 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.
jem-odoo