Allow to redirect on a form view when the user click
on a html tag a with data-oe-model and data-oe-id specified.
In order to avoid code duplication the do_action already existing in
mail_thread is moved in the action_manager and mail_thread and mail_activity
use a trigger_up in order to call it.
The purpose of this commit is to create a generic method in order to
log an activity on following documents or on upstream documents in order
to avoid code duplication.
In order to use it, you have to:
- create a static method in order to generate the string
for the note (it will use an arguement with the format
{'dest_object': ['orig_obejct', (new_qty, old_qty)]}
- 'DOWN' to notify following document. In this case you
have to specify a groupby/sorted method.
- 'UP' to notify upstream document. In this case you have
to specify a specific method call
'_get_upstream_documents_and_responsibles' on the object to
ride up.
Log_activity's operating mode:
destination objects = self.stream_field(passed as arguments)
'DOWN' group destination objects by document on which we want
to log the activity and a responsible to assign.
For each pair (document, responsible) generate a specific note
with only the information relative to object that belong to the current
document. Once the note is returned, it logs the activity on the
document and assign the reponsible.
'UP' instead of sort and group runs the method
'_get_upstream_documents_and_responsibles'. For example on moves
this method is called recursively on all moves orig that are not done or
cancel until it can't find a valid one at this moment it returns its picking.
Then generate the note and log the activity the same way than 'DOWN'.
If two blanket order are active with the same vendor, we have to produce
two separate purchase orders even if the two products are ordered in the
same operation.
If the parameter multi currency is enabled, the field currency is added
in the purchase requisition form. The currency chosen will be the one by
default in the PO attached to the BO
If a there is blanket order in 'ongoing' state and linked with the purchase
order's vendor, we can choose associate it to the PO to retrieve the contrat
price and impact the ordered quantity.
If a purchase order is created from a blanket order, the vendor is
linked to the BO reference. So we forbid its edition once its choose.
When creating a blanket order, it will generate a supplier info for the
associated product. If there is already a supplier info for the same product
and same vendor, the sequence should be adapted to take the one created via
blanket order before the other(s) one(s).
The stages workflow of purchase tender is not suitable for blanket order.
the steps bid selection is use only with purchase tender. Now :
PT : draft -> confirmed -> bid selection -> closed
BO : draft -> ongoing -> closed
The blanket order is a contract between you and a supplier on a
different
price (usually lower than normal) for a big quantity of some specific
products.
The goal is to generate a supplier info for each product of the blanket
order and
remove them when the BO is either closed or cancel.
Purchase requisitions have two different type available : purchase tender
and blanket order. As the behaviours between these two types are very different,
the type is now locked once the requisition is no more in draft state.
When creating a draft purchase agreement, a reference number was generated even if
we do not click the 'Save' button.
Now, the reference is filled with 'New' at the creation and overided with a proper
reference number after clicking on 'Save'. Also, the prefix depends now of the
requisition type. BOxxxxx for blanket orders, TExxxxx for call for tenders.
The vendor is now a mandatory field in the blanket order form
because it's directly linked to purchase orders. So Odoo needs
to know to which supplier the PO is addressed.
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
Arnold Moyaux