With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
Community PR: https://github.com/odoo/odoo/pull/91187
## Proposed feature and relevance
Add a new retrieval strategy for gathering products: "Least packages".
The goal of this strategy is to select specific product quantities from stock by using as few packages as possible, to allow for efficient logistics operations and avoid unnecessary opening/unpacking of packages.
This strategy will behave as follows:
- In case a negative qty is requested this strategy will behave as a FIFO strategy.
- Otherwise, the strategy will determine a combination using the least amount of packages that sum to the requested quantity, and adapt the provided domain to select only the quantities in these packages. This way no packages need to be opened to select the requested quantity.
- In case an exact matching of current packages to get the requested quantity is not possible, a selection of packages is made where the largest packages are selected one by one until the requested quantity is reached, or until no more quantities are available. For this approach, one package needs to be unpacked as it will not be used completely. The final selected package that will be unpacked will be the smallest one possible, to try to unpack smaller packages over bigger packages.
- In case the search for a minimal matching of packages results in an out-of-memory situation, the strategy will fall back to a FIFO strategy.
- Loose items (not tied to a package) are considered as single-item packages for the purposes of package selection.
- **NOTE:** To force the selection strategy to "clean up" certain packages that have previously been opened, it is recommended to unpack these packages into single items, as they will then be consumed to "fill up" requested quantities in later retrievals.
## Changes to allow more complex strategies
To allow for the integration of this new strategy the structure of `_gather()` needed to be adapted to allow a removal strategy to provide not only the SQL `ORDER BY` string but also adapt the domain used to retrieve the requested quantities.
This change is reflected in the method signature of `_get_removal_strategy_domain_order()`.
## How the strategy works
The strategy does one extra query of the database, to determine the different packages and their respective quantities (using the provided domain).
Loose items (that do not belong to a package) are added as single-item packages to also consider them.
For minimal exact package selection, an A* algorithm is used with 2 performance modifications:
- Using the information that the packages are sorted by size (large -> small).
- Using the information that the generated subtree for a specific package of size x is the same as all other packages of size x at a specific node.
By using the A* algorithm, as soon as a matching packaging selection is found, it is ensured to be optimal and other combinations do not need to be considered.
In case the A* algorithm runs out of memory the provided domain is just returned, which equates to a FIFO strategy.
In case the A* algorithm does not find an exact matching of packages for the requested quantity, a selection is made using the least amount of packages, unpacking the smallest possible package (or until no more quantities are available, in which case effectively all quantities in the domain are returned).
## Used heuristic
The heuristic used for the A* algorithm exploits the knowledge that our packages to select from are ordered by the highest to the lowest quantity (on the database side, SQL `ORDER BY`).
It assumes the "best case scenario" as an estimate for the amount of packages remaining, which is if we were to "match" the required quantity using fractional multiples of the next biggest package size.
***Example**:
Remaining quantity to select: 27
Remaining package sizes to select from: [10, 10, 5, 5, 5, 1, 1, 1]
Heuristic for choosing package with qty 10 as next package: 27/10 = 2.7
Heuristic for choosing package with qty 5 as next package: 27/5 = 5.4
Heuristic for choosing package with qty 1 as next package: 27/1 = 27*
This way the heuristic is always a "best case" (fractional) for the amount of packages that still need to be selected.
As required by the A* algorithm this also results in an underestimation as the fractional result is not possible, and it is not certain that there are still enough packages of this size that can actually be selected, but favours larger packages to make the search converge more quickly.
## Performance
### CPU
Two test cases were run to evaluate the performance.
***Total nr of pkg**: The total amount of different packages generated during data generation
**Qty to select**: The total quantity that needs to be selected
**Selected nr of pkg**: The amount of packages that was ultimately selected by the algorithm
**Data generation time**: The time required to generate all packages
**Assignment time**: The total time to run `_action_assign()` for the move
**A\* time**: The time to run the `_run_least_packages_removal_strategy_astar()` method*
#### First test case
This scenario simulates a case with a large quantity to select from a large amount of packages, but of relatively homogenous size.
Generate 30 different package sizes between 2 and 1000. For each package size, generate 100 to 250 packages each. Also add 100 to 250 "loose items".
The quantity to select is chosen between 1 and 50000.
| RESULTS | RUN 1 | RUN 2 | RUN 3 | RUN 4 | RUN 5 | AVG |
|--------------------------|----------|-----------|------------|-----------|----------|------------|
| Total nr of pkg | 5298 | 5772 | 5855 | 5533 | 5179 | 5527.4 |
| Qty to select | 10319 | 20762 | 44422 | 39306 | 1783 | 23318.4 |
| Selected nr of pkg | 11 | 22 | 48 | 41 | 3 | 25 |
| Data generation time (s) | 64.59124 | 92.916682 | 133.673384 | 82.711438 | 85.54542 | 91.8876328 |
| Assignment time (s) | 4.060216 | 11.212937 | 4.763776 | 8.60248 | 3.461941 | 6.42027 |
| A* time (s) | 0.28 | 6.88 | 0.21 | 3.96 | 0.03 | 2.272 |
#### Second test case
This scenario generates a large amount of small packages of different sizes.
Generate 250 different package sizes between 2 and 10. For each package size, generate 5 to 15 packages each. Also add 5 to 15 "loose items".
The quantity to select is chosen between 1 and 10000.
| RESULTS | RUN 1 | RUN 2 | RUN 3 | RUN 4 | RUN 5 | AVG |
|--------------------------|-----------|-----------|-----------|-----------|----------|------------|
| Total nr of pkg | 2485 | 2406 | 2491 | 2555 | 2542 | 2495.8 |
| Amount to assign | 27 | 4029 | 3966 | 3049 | 1833 | 2580.8 |
| Selected nr of pkg | 3 | 411 | 411 | 306 | 184 | 263 |
| Data generation time (s) | 18.502933 | 18.692048 | 19.969955 | 19.169106 | 19.16439 | 19.0996864 |
| Assignment time (s) | 1.35635 | 7.958852 | 8.470518 | 6.300406 | 3.895457 | 5.5963166 |
| A* time (s) | 0.01 | 0.07 | 0.77 | 0.56 | 0.31 | 0.344 |
### Memory
In cases with large amounts of different-sized packages (200+ different sizes and 200+ packages required to get an exact match) the memory performance of the A* strategy might become problematic.
When lots of packages have the same size (which would be considered typical in cases where there are large amounts of packages) the specific modifications to the A* algorithm ensure that the strategy still delivers good memory performance for this use case as the tree size can be significantly reduced, even with large quantities.
### IO
This strategy only requires one extra SQL query to fetch the different quantities and their respective packages.
## Limitations
No tests for this strategy were done for non-integer quantities. In these cases the performance of the A* algorithm might not be satisfactory and another approach might be preferred.
More research could be done for specific use cases where packaged quantities are non-integer values.
closesodoo/odoo#91187
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The text and the image were overlapping in the digest tip about "Tip: Speed up
inventory operations with barcodes". This solves the problem.
Technical note: actually, the layout has been broken in 15.2 because the image
has been updated with another ratio (from that version the CDN is used instead
of an image on the server). To support more client and as it looks ok even on
small device even with the 2 columns (text-image), we have used a table for the
layout.
Task-3097167
closesodoo/odoo#111737
X-original-commit: 7b6c82f2bc0f0d3931d6bd7c571cf4854eb4bd86
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
- The `Returns` word should be translated but it has not been
initialized via xml
data so i added.
closesodoo/odoo#98966
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Current behaviour:
When installing Sales, then PoS, we get an error when loading the modules.
Expected behaviour:
No error should be present when installing PoS just after the Sales app.
Steps to reproduce:
(With demo data)
- Install Sales
- Install PoS
- Get Error
Reason for the problem:
When installing Sales, there is the Product dependency that creates a product variant,
named product_product_4d.
Then in the Sales demo data there is the addition of an "exclude_for"
record (basically an exclusivity rule for variant attributes, for ex: A AND B cannot be together).
In our case it happens to be the attributes which product_product_4d was based of. Therefor the ORM
deletes said record (from the database).
Then when installing PoS, it installs Stock as a dependency, which demo data references product_product_4d,
which is not present anymore in the database.
Fix:
Remove the creation of product_product_4d and all the records that reference it.
Affected versions:
- 14.0 (separate PR)
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-2999180
closesodoo/odoo#104184
X-original-commit: 3e49e533892f94eeb094a436fa34cbac3ed7ad6d
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
San Francisco is in data since commit 33950bfdc3
However the task aims to clear demo data but warehouse0 is the default
warehouse in data and should not have a demo name
closesodoo/odoo#101305
X-original-commit: 0fd86c9ab1bbd237b3c7cb3c22b3362612142993
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the delivery WH/OUT/00005 had 16 `qty_done` for the
product "Desk Combination". Now it has no `qty_done`.
task-2666478
Part-of: odoo/odoo#91807
Minor UX updates in purchase and stock:
Reworded (in stock):
- Default name location "Partner Locations" => "Partners"
- Default result for "Apply All" wizard "Inventory Adjustment" =>
"Quantity Updated"
- Individual "Apply" move reference/name updated for individual quants
(i.e. "Quantity Updated / Confirmed") so that the scheduled date is
no longer included
Removed (from purchase):
- Duplicated menuitems, i.e. "Purchase > Reporting > Purchase" showed
the same thing as Enterprise menuitem and both were being displayed in
Enterprise version. Also updated the no records found help message
since old message appeared to be slightly out of date.
ENT PR: odoo/enterprise#29974
"other" part of b2b task: 2882539
Part-of: odoo/odoo#97109
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
By setting a company on the package type, this makes it so the package
type isn't selectable for packages without a company (i.e. Put in Pack
without validating a picking = package without a company). For the sake
of demos, let's make it so any company can use these package types.
Task: 2623434
ENT PR: odoo/enterprise#21179closesodoo/odoo#77597
X-original-commit: 7ec72c3d838dd40aad921b65b998b68c59225e01
Related: odoo/enterprise#21349
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
For `stock`, adds package type demo data (pallet and box).
For `barcodes_gs1_nomenclature`, adds a custom rule (AI 91) to recognize
the package type in the Barcode Application.
As there is no standard GS1 nomenclature's rule for the package as
defined by Odoo and there is a bunch of free-to-use AI (from 91 to 99),
using one of them for the package type could be useful to be able to
scan a new package and create it on the fly with the wanted type.
task-2627002
Part-of: odoo/odoo#75699
Assuming that the only thing cared about when removing items from stock
is the accessibility of the product. Then it would be better to take
products stored on the floor instead of on higher levels of my racks.
In this case current solutions in Odoo are not the most efficient.
Closest location picks items in the 'smallest' location (in alphabetical
order), so it assumes the locations are ordrered alphabetically
according to how close they are to the ground.
Assume we have the following stock :
- WH/Stock/Shelf 2
- WH/Stock
- WH/Stock/Shelf 1
Quants would be looked at in the following order :
1. WH/Stock (due to shortest name for the same stock)
2. WH/Stock/Shelf 1 (due to alphabetical order)
3. WH/Stock/Shelf 2
Task-2568735
closesodoo/odoo#75303
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Add reference of the traceability report's origin (production.lot,
manufacturing order, picking, ...) to the end of the
report.
Change the layout a bit so the data isn't squashed by
the border.
Task-2467686
closesodoo/odoo#74120
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
We introduced new Smart Putaway Rules.
Locations now can have a storage category, on each storage category,
we can specify the amount of products/packages(with certian package
type) that can be stored in the location.
On putaway rules, we can also set a storage category. Now when apply a
putaway rule, we will find a suitable child location of the out
location according to quantity/weight setting on the storage category.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
improved various things into this commit:
- added OPTIONAL email field on the new ship-to address for the eCommerce
- if the email field is empty on the shipping address,
it will send the confirmation email only to their parent
task-2194014
Closes#47347
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Remove unused `sequence_tracking`
- Group data by models when it is possible, which implies
to remove `procurement_data.xml` file (data into `stock_sequence_data`).
- Clean messing comments
- Reorder the manifest (when it is possible)
task-2373638
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#19366
Creates some SO to have more data to display in the product's forecast
report. The purpose is to make the demo of this report easier.
Also, increases the inventoried quantity of the `product_product_10` to
compensate the SO as this product is also used by other app demo data.
task-2058495
[IMP] stock: increase product_product_10 inv. qty.
X-original-commit: cecdc27fdf095374e1e640c5bf04c42a014af663
The purpose of this commit is to increase the acoustic bloc screens on
hand quantity, and in fact, it should be already the case.
But because of a duplicate demo data record's id, the inventory line
about the acoustic bloc screens was erased by an another inventory line.
task-2058495
X-original-commit: 9d6b7af61d35b03d2ab1a55268829d8760570f67
The demo data creates a delivery with qty done but who can't be mark as
done because this picking has a move which has a move line (with qty.
done), but this move line isn't linked to the picking.
To fix that, this commit removes the manually created move line, calls
`action_assign` on the picking (this will create the move line and
correctly link them) then sets the `qty_done` on the move line.
Also, applies the same fix to done pickings who have the same issue (but
as they are done, it is less visible).
X-original-commit: 6732619941b9639897c00a3776429f50b38d1f9d
- The deadline of MO generated via procurements is calculated differently.
Now, it doesn't take anymore in account the manufacturing_lead
of the company (Security Lead Time of MO). The computation of planned date remains unchanged.
- The date_expected fields was duplicated with the date fields
except when the move was done. Merge both fields.
The only information lost is: we can't know what was the
scheduled date before processing move (`state` == done).
Indeed, the date becomes the actual move processing datetime.
- The `date` in `stock.picking` field contained the time of
(purchase) order `date_order` (`purchase.order`).
This field is was wrongly used in the kanban view where we
expected to see date_planned instead. Also, the `_order` used
this date instead of date_planned too.
- The `delay_alert` is activate independently of stock rules.
Then it is now activate in all case.
- Remove the auto-reschedulting process of stock move via
the stock rule (`propagate_date` and `propagate_date_minimum_delta`).
Replace it by a automatic deadline date (`date_deadline`) propagation.
The deadline is the promise done to/by vendor/client (SO/PO)
then it is a readonly fields on picking/move and MO.
- Now the Scheduled date (`date`) of stock move is never propagate
and it is only related to the Scheduled date of
related document (MO or picking).
- Now when a move is created from procurement (sale),
`date_planned` = `date_deadline` - `security_lead`.
- The `delivery_date` of sale is no editable after confirmation
and propagate as the deadline to related stock move linked to order_line
- Adapt filter and decoration of MO and picking.
- Because we are the client in case of purchase (PO), the promise of vendor
can be not respected. Then we add the lead security to the deadline
(inverse the sale order logic) of PO picking (promise reciept date
+ security lead) to match with the replenishment.
task-2246665
PURPOSE
Review the tips and digest layout design to make sure they have a WOW effect
and increase trial conversion/retention.
SPECIFICATIONS
“Speed up inventory operations with barcodes”
See code for specifications.
LINKS
Task ID-2274264
COM PR: odoo/odoo#53580
ENT PR: odoo/enterprise#1139
X-original-commit: d679b6f2807b937c1765f20b8a4fb796aec821a7
Improve onboarding by removing the replenish on order route.
Companies that do MTO process could unarchive the route in
order to have a basic configuration.
closesodoo/odoo#55147
Task: 2245882
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Activate the multi-warehouse automatically when there is more than 1 in
a company. Then remove the multi-warehouse setting in the config, and
allow to create warehouse. Because create a warehouse can change
groups of the user, we reload the page when there is any modification.
Update warehouse demo data accordingly (remove the second warehouse
of the second company).
task-2196687
closesodoo/odoo#49625
Related: odoo/upgrade#1253
Related: odoo/enterprise#9934
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Adds quantities in starting inventory and adds a "Starting Inventory"
for the Chicago Warehouse. The purpose is to avoid to have negative
values in demo data.
Task #1970460
Rename warehouse of compagnies as following:
- YourCompany -> San Francisco
(WH) (WH)
- My Company (Chicago) -> Chicago 1
(MyCo) (CHIC1)
- Chicago Warehouse -> Chicago 2
(Chic) (CHIC2)
Also, can pass a default code through the context when create a new
company to set the `code` value when creating the default warehouse for
the newly created company.
Task #1970460
Before this commit, some tracked product quantities didn't have a SN/LN.
To avoid some issue at the use, it's better all demo data fulfill
requirements like that.
Task #1970460
Demo data product's quantities are no more put in sublocation as by
default, multilocation aren't active.
Also, adapts `test_location_usage` because as we moved quantities from
sublocations to the main stock location, the stock warehouse will have
reserved quantity due to a backorder created by demo data.
In this test, we try to change location as a scrap location, what we
can't do if this location has some reserved quantities.
Task #1970460
Before this commit the demo delivery WH/OUT/0005 is plan then validated.
But as this delivery is the one used as example in the barcode PDF, it
could be usefull for demonstration to keep it as to process.
So, this commit keeps it only as ready, and also increases the stock
amount of Desk Combination to be able to process this delivery without
any issue.
task-2199747
closesodoo/odoo#48320
X-original-commit: 652ee46e8adc35bae4f89bf9802f12bd1c424c8d
Related: odoo/enterprise#9474
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
As a barcode for this location was created into the barcode pdf
(enterprise), it seems logical this location has actually a barcode.
task-2199747
X-original-commit: 661bfffca9ad2aa1357ef031ca983104200d5d1f
Steps to reproduce:
- install sales and easypost shipping
- have a delivery order of multiple packages with easypost
- click "send confirmation email"
previous behavior:
the template does not handle multiple package references
and the associated link is wrong
current behavior:
each reference is set in a separated link
opw-2167037
closesodoo/odoo#45507
X-original-commit: 65eaa3e7daf0b547ae2bb98e335fc5941cb200a6
Signed-off-by: mightyjol <jhk-odoo@users.noreply.github.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Purpose
========
Change www.yourcompany.com default link for the 'Website'
field of the res.company and res.partner to 'www.example.com'
closesodoo/odoo#40727
Taskid: 2129147
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
`action_done`on pickings should be a private method,
and called only trough the picking validation process.
task-1938108
closesodoo/odoo#39174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
All transit locations were set as active by default, confusing some users.
There are now set as active only when when a ressuply route is created
between some warehouses
TaskID: 1873106
Some barcodes nomenclatures and rules are added in the modules that use
the barcode module. We should set them in no update to avoid loosing
modifications when the module is updated.
closesodoo/odoo#37985
X-original-commit: c4251c1c55d010e52b956817c2d4a588ee9379a9
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
There's no readonly possibility on the calendar view so the only way to
prevent updating a done or cancelled transfer is to raise on the write.
We should to raise in the inverse function so that it is possible to
bypass the constraint by writing directly on the move, as we want to
change some date in the demo data.
closesodoo/odoo#36550
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
product.template
- make responsible a property field in order to ensure proper next activities when a product
is used between multiple companies
stock.putaway.rule
- added a company_id field
stock.move.line
- company_id is not related anymore since a move line can exist without a move until its validation
stock.package_level
- added a company_id field
stock.picking.type
- company_id is now required
stock.production.lot
- added a company_id field, adapted the constraint accordingly
stock.quant
- check the consistency only in inventory mode
stock.quant.package
- company_id is now empty if the package is empty
stock.picking
- company_id is now related to the one of its picking type
Added some tests.
Moved stock_traceability in the `report` directory.
Removed useless /tests/tours/route.js.
task-1985992
Mahamadasif Ansari