This commit improves the JS code of the mail module,
which comes maily from the new coding guidelines
and the addition of "JS services".
JS services are important objects that do not fit
well in the component tree, such as chat_manager
or ajax.
The benefits of JS services are improved readability
of the code, reduced coupling, and more testable
modules. In particular, discuss was hard to
Summary of the changes:
- ClientAction has been renamed into Discuss
- Clear instantiation of chatManager
- New coding guidelines in most mail modules
- JS Services can interact with each other
- Chat Manager and Window Manager are services
- Window Manager renamed to Chat Window Manager
- bus.bus is now encapsulated in Bus Service (a service)
- The test infrastructure has been tweaked with JS Services
- Chat Mixin has been removed
A future improvement would be to translate some 'trigger' into 'trigger_up'.
Before this commit the bootstrap version we used was inconsistent.
Indeed, the javascript files were the 3.3.4 ones and the less files
were the 3.3.5 ones. This was due to a failed merged resolution in 9.0.
This should however not cause any issue as the difference between
3.3.x versions are very minor.
Basically, this commit is more of a fix than an improvement and may
even be backported if we find reasons to do so. This commit is mainly
made to prepare the transition to version 4.0.0, which requires to
switch our LESS files to SCSS first (and it will be easier to go by
bootstrap 3.3.7 with SCSS files first).
This commit add a help message in the column to indicate that pressing
escape will discard the current column creation. Note that some JS had
to be added to make the message disappear when the input is no longer
focused. The reason is that the create column widget may still be visible when
the input is no longer focused (for example, because the user clicked on
the fake records, or clicked on the example link)
* analytic accounts can be shared among companies
* amount on analytic lines always refer to amount in company currency of which it belongs to
* add analytic groups (hierarchical way to classify analytic accounts)
* analytic tags:
- only present on analytic lines, not anymore on analytic accounts
- can be used to distribue/split an analytic lines among several analytic accounts
- enabled by a dedicated res.group
- added on several objects (vouchers, expenses, analytic defaults...) as well as in bank statement reconciliation widget (manual counterpart and account.reconcile.model)
* bunch of fixes made related to analytic
Was PR #22124. Was task 32386. Original work by tbe.
- remove the upstream/downstream logic, always display the most recent
move at the top and the least one at the end
- color in move in green, out move in red
- better integration with repair and mo
- when trying to drill down an untracked component, don't display all
the possibilities
- few usability fixes overall
Closes#19737
task 36338
- Optimized _lines() to fold/unfold mechanism and use stock move line in get lines.
- Merged into single method (make_dict_move and make_dict_head) to get parent & child traceability result
and use unfolfable to make line unfoldable.
- Removed _get_produced_or_consumed_vals method and move mechanisam into _line method will do same for this.
- Make some methods private.
- Removed useless vals from dict.
- Outgoing moves should be in red (if going out of the stock).
- Incoming moves should be in green (if entering the stock).
- Internal moves should be in black.
- No lines in bold anymore in the report.
- When unfold down MO, Repair Order, Unbuild Order to display produced or consumed materials even product is trackable or not.
- Normal products(not trackable) are directly displayed with source and destination not foldable.
- Unfoldable line has no caret icon to unfold, so move it to margin-left 15px to make parellel.
- Invisible source and destination location on head lines if product trackable.
In the transient model 'Change Password Wizard User', the many2one
`wizard_id` was not set as ondelete cascade even though this field was
required.
This was causing issues in the auto-vacuum cron if by chance this model
was cleaned up before the wizard ('Change Password Wizard').
Courtesy of @rco-odoo
Issue #813289
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.
Aaron Bohy