Purpose is to prepare addition of UTM statistics in mass mailing view.
Specifications
* add a hook on stat buttons to add some of them in sub modules;
* add UTM information in debug mode to be able to see them and update
them if necessary;
This commit is linked to task ID 1872198 and PR #26188.
Purpose of this commit is to avoid having tests depending on demo data.
Especially those tests are recent, introduced at 967d228a44 and should
have been made independent before merge. File is renamed according to
guidelines.
This commit is linked to task ID 1872198 and PR #26188.
Purpose is to be able to have invoice_id information on accounting report.
It allows notably to filter reporting result by invoice. This will be
used notably to have reporting information about invoiced amount linked
to UTM-based sale order subset.
This commit is linked to task ID 1872198 and PR #26188.
The complete name on stock location is computed base on the
location name. However the location name can be translate and then
the complete name is often half translated.
This commit remove the translation on location name.
Purpose
=======
Clean menus structure in website frontend and backend, for an easier navigation.
Specification
=============
Website
-------
- Restructure menu
- Enterprise: Keep google analytics view in a dedicated menu item when ecommerce is
installed:
- Sales Dashboard(ecommerce dashboard)
- Analytics (google analytics)
- Community: Keep both sales orders and google analytic dashboard on the same
dashboard view
- Restore google analytics api option in website settings when ecommerce
is installed
E-Commerce
----------
- Website > orders > orders: add default filter "from website" and remove it in
the action. That way if you create an order manually there is still a way
to find it from the menu (the salesteam is different)
- Default filter for abandoned cart menu
- Improve setting text and tooltip. It's not obvious that recovery emails must
be sent manually. Replace with:
- Title: Abandoned Carts
- Subtitle: Send a recovery email when a cart is abandoned
- Tooltip: Abandoned carts are all carts for which no transaction has
been confirmed while the customer has filled in their address.
You can find them in *Website > Orders > Abandoned Carts*.
From there you can send a recovery email to stimulate the
customers to resume their order.
- Tooltip email template: This email template is suggested by default
when you send a recovery email.
- Tooltip hours: Carts are flagged as abandoned after this delay.
- Hour label: Cart is abandoned after .... hour(s).
Task ID: 1859170
Each line that contains a manufacturable product displays its
BoM (clickable with an html report). _get_bom_reference function
is used in order to add information about BoM in report (e.g plm
module add its version).
Task id: 1857701
Show all the documents related to products in the Bom Structure and costs report.
On click of the icon attachments, open all the documents/attachments related to product
and its template.
Task id : 1857701.
- If ordered quantity is less than what supplier/vendor supplies then the price unit should be set to 0
- If vendor does not supply the ordered product then the unit price should still the same
TASK-34233
When the quantity of a purchase line id is changed, the unit price is
set to 0.0 if the PO partner has a seller line on the product and the
quantity choosen on the line cannot get a seller.
TASK-34233
- Change label Pickings to Transfers to be consistent with the stock
module
- Improve landed cost error message when they cannot be applied
TASK-1819891
- Change "Force Accounting Date" label in "Accounting Date" on
inventory adjustments.
- 'accounting_date' only visible in debug mode
- Improvement tooltip of accounting_date,date
TASK-1819891
The purpose of this change is to make the code clearer and testable.
In this change, the 'tab_manager' static object was merged with the bus
cross tab.
Cleaning was done to clearly define private and public functions as well
as handlers. The methods are documented and the constants are now defined
on the class. The bus use the service behavior with 'trigger_up'.
'bus.CrossTab' who extend 'bus.Longpolling' are instantiated by the
bus service.
The class is always instantiated with a parent, or root in the case of the website
(im_livechat), to use the ajax and localstorage services. So the behavior, perhaps
logger or redefined by the parents.
This change is usefull to convert the bus.bus into a sweet bus and cross tab bus service.
Actually, if we use the _rpc mixins in the bus, the long polling can't be abort, and
raise an exception.
If the service bus are called and destroyed the rpc can be returned after, to
avoid a useless call to the database and unexpected behavior, we abort the
connection.
- Receive products in 2 steps
- The product has a reordering rule
- On the PO generated, the source document should be the name of the reordering rule
Task-1838639
We don't want to use the name of the rule that created a move anymore,
so we propagate the origin of previous move if it has any and, use the
picking name of the previous move if doesn't hav any origin.
This behaviour make more sense as it will alway keep the origin of the
document that trigger the creation of a move.
TASK-1838639
Purpose
=======
If the model on a reference fields is not modified from the interface
by the user but by the server, the selection is not correctly
recomputed on the interface.
Specification
=============
By calling super first on the '_reset' method, the new model
is taken into account when resetting the selection.
Purpose
=======
When you update a record on a server action, you can modify a field
value (like the partner id). It's boring to be forced to specify
the id on the server action line. It would be easier to search on the
record name.
Specification
=============
A a server action line type 'Reference'. It allows to select the partner
name (Agrolait) instead of being forced to specify its id (3493).
Purpose
=======
As a server action could add followers on a record, here the goal
is to be able to add a next activity on a record.
Specification
=============
Based on the configured trigger, we can add a next activity on a record
by specifying :
- The activity type
- A summary
- A note
- A due date in x days/weeks/months
- A responsible
Purpose: better display duration. Label for hours / days is not very user
friendly when displayed left compared to the value. In this commit we
move the unit display right of the value and correctly display choices
related to the leave request date options.
This commit is linked to task ID 1871812 and PR #26180.
Purpose: new menu organization
* Dashboard (only for officer and manager like currently)
* New Request (= leave requetss in calendar view)
* My Leaves
* Leaves Summary
* Leaves Requests (in list view)
* Allocation Requests
* Managers (current menu is ok)
* Reporting (current menu is ok)
* Configuration (ok)
This commit is linked to task ID 1871812 and PR #26180.
Purpose: better display duration. Label for hours / days is not very user
friendly when displayed left compared to the value. In this commit we
move the unit display right of the value and correctly display choices
related to the leave request date options.
Part of the spec: https://drive.google.com/file/d/1XQtw5ZiAebycXbeHmfbDYYwrFTRmkBNU/view
This commit is linked to task ID 1871812 and PR #26180.
* product_product, product_template :
- Add `uom_name` field to display stat buttons with UoM's name.
* delivery:
- Move field 'HS Code' from `General Information` to `Accounting`.
* hr_expense:
- Make checkbox `Can be Expensed` visible for all products.
* mrp:
- Stat button update, we now count the uom quantity of product we have in our MOs
limited to the last 365 days. Before that we were counting all the MOs.
To achive this,
- Add a stored compute field `product_uom_qty` on `mrp.production`.
- Stat button now uses `action_view_mos`
- The field was called `mo_count`, renaming it to `mrp_product_qty` as its
function changed.
* point_of_sale:
- Add a new tab (`Point of Sale`) and moved the `Point of Sale` section
previously located in `Sales` to this newly created tab.
* product_email_template:
- Renamed header 'Email' to 'Automatic Email at Invoice'.
* purchase:
- Improved tooltip of field 'property_account_creditor_price_difference'.
- Set `product_uom` to `uom.product_uom_hour` instead of
`uom.product_uom_unit` in demo data.
- Add a stored compute field `product_uom_qty` on `purchase.order.line`.
* report_intrastat:
- Move field `Intrastat` from `General Information` to `Accounting`.
- For product template's form view, inherit from
`product.product_template_form_view` instead of 'stock.view_template_property_form'.
* sale:
- Move `expense_policy` from `Purchase` to `Sales`.
* stock:
- Add a new section in `Inventory` called `Logistics`, and put fields
- `Weight`, `Volume` and `Responsible` in it.
- `incoming_qty` is now only visible in debug mode.
* website_sale:
- Add a new tab 'eCommerce' and move 'eCommerce' section from 'Sales' tab to this newly created tab.
- Rename 'eCommerce Categories' to 'Categories'.
Task: #51125Closes: #23868
In purchase we add a stat button that counts the number of purchase
orders linked to the product.
In this commit we change this count to count the quantity of products
linked to a purchase order.
We basically do the same thing with the stat button of sale (sale
orders) and mrp (manufacturing orders).
Before this commit, the only way to deal with the same tax either with price included or not was to duplicate it, one with the price included checked.
This commit add a new boolean on the reconciliation widget propositions to decide if the tax must be used like a price included tax or not.
PR: 17040
task: 32717
This merge optimizes and lessens query count of notification process. When
posting a message some computation is done to fetch followers and/or people
and channels to notify, then notify them on their Inbox or by email. This
process now takes less queries thanks to several improvements :
* fetching followers / recipients data is now done manually in SQL allowing
to fetch data across several models in less queries;
* computing recipients is now separated from notifying them. Notification
better uses precomputed data in order to avoid fetching and browsing
several time the same data;
When possible code has been made more readable through code inlining. Several
methods have been removed because they are not used in inheritance. Some code
is now more low-level. Optimizing part of the process can make it harder to
inherit or modify.
Performance counters are updated showing gain in nearly all tested cases.
An enterprise branch is linked to this one that also improve notification
process.
This merge is linked to task ID 47934 and closes PR #24033. No functional
change should occur with this merge.
Purpose of this commit is to avoid browsing and prefetching data about
recipients when notifying a message to partners and channels. Mail message
_notify computes all necessary data in a single query. This commit allow
to re-use this data by propagating it through the call chain.
Addons inheriting from classification methods used when sending notification
emails are updated accordingly to the API and data update.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit cleans code about sending email notification to recipients.
Purpose of this code is to prepare notification emails, group recipients
and finally send emails. In this commit we clean and optimize a bit by
* propagating some additional parameter to simplify code, like record
on which the notification process runs;
* inlining some code currently located in sub-methods. It eases code
understanding as there are less code jumps. As those methods are not
inherited inlining them can be done;
* simplifying a bit notification emails preparation and computation;
It allows to save a few query by avoiding to fetch and browse again some
data that were already computed.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
This commit is related to enterprise commit that updated mail_push. It is about
[REF] mail_push: optimize mail.message notification process override
It updates code of mail_push to lessen its impact on mail-related code. It
allows to change a few counters in test_mail. Indeed counters are impacted
by code located in enterprise because those are "maximum queries" counters.
As mail_push is an auto-install module enterprise runbot would be broken
if the counters weren't updated.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
In this commit we update _notify method of mail.message to fetch most data
related to notification process in a single query. Indeed posting a
message can be a costly process, especially when involving several partners,
channels, depending on their notification status, user groups, ... Most
of the required data can be fetched in a single hand-tuned query.
Purpose is to lessen query count. Side effect of this commit is that code
is less recordset based and therefore more low-level. It is also harder to
customize the behavior through inheritance as it implies rewriting a bit
more of code.
This query is located in a private method on follower model. It takes
parameters allowing to either fetch data related to followers of a given
subtype, either related to some partners and channels. First use case is
related to the process of posting a message with a subtype that triggers
notification of followers. Second use case is related to notifying some
specific partners or channels of a given message. It takes notably into
consideration internal subtypes and active field of partners, allowing to
correctly handle corner case for deactivated followers and portal / share
partners.
Notification process is divided into two steps. First one is to compute
recipient data. Second one is to apply the result of this computation and
call the various notification mechanisms accordingly. Doing so allows to
easily re-call notification process or compute some data differently
if necessary.
API of notification methods is updated to allow passing notably the values
used to create the newly-posted message. It allows in some simple case to
avoid browsing message and partners when no notification is necessary. It
saves some queries in simple case like posting messages with specific
subtypes not often followed or logging notes without mentioning people.
This commit allows to save a few queries on several performance tests as
indicated by updated performance counters. Future commits will gradually
propagate the use of this data to further lessen query count.
This commit is linked to task ID 47934 and PR #24033. No functional change
should occur with this commit.
Since date / datetime refactoring done at 960360afe4 we cannot
encode new leave requests or new allocation requests anymore. This commit
fixes that by correctly setting date / datetime on date / datetime field
and correctly computing one from the other.
Payments older than the chosen date won't be proposed in the widget allowing to match payments with bank statements. This is useful if the db used invoicing for years and then installed accounting : users don't want to have to match all the old payments that were generated by invoicing with bank statements.
Was task 1829536
Was PR https://github.com/odoo/odoo/pull/24728
Thibault Delavallée