Steps to reproduce the bug:
- Connect as Admin and select “My Company (San Francisco)”
- Create a storable product “P1” and select “My Company (San Francisco)” in the `”company”` field
- Go to inventory settings and enable the “Storage Categories” option
- Create a new “Storage Categorie” > select “My Company (San Francisco)” in the `”company”` field > save
BUG1: Edit and try to add the product “P1” > Edit and try to add the product “P1”
> "P1" is not filtered correctly with domain, because the `”company”` field of the `"stock.storage.category.capacity"` model is not set.
As it's a related field, the “default_company_id” should be in the context so that the “company_id” field will be correctly set with this value
BUG2: Add a new line > create and edit a new product > the product type is “consumable” instead of storable, so we should add the type in the context
BUG3: Add multi-company security rule
opw-2689426
closesodoo/odoo#80061
X-original-commit: f5554fa94d41d7eae62c4a1271e41012178c4d8f
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Previously this setting was an application setting which meant the
report could auto-open at undesired times (e.g. internal picking when
multi-step). Instead we make it more flexible for the user's desires by
moving it to the picking type setting.
Part of Task: 2632884
Upgrade PR: odoo/upgrade#2815
Part-of: odoo/odoo#76147
This commit introduce Wave Pickings. This new object is a group of stock
move lines related to different pickings. The goal is to group stock
movements having similar characteristics like same source location, same
product category, ...
Wave pickings are created from stock move lines. Those are removed from
their picking to a copy of it. All the new picking are grouped together
in a new batch picking. This batch is the wave.
To differentiate the batch pickings and the wave pickings. This commit
introduces a new menu and a new sequence.
Task : 2411102
Part-of: odoo/odoo#63291
As the inventory adjustments have been removed in favour of the editable
quants, this commit introduced the possibility to import pre counted
quants like non validated inventories back then.
task : 2555118
Part-of: odoo/odoo#74715
New reception report added for non-outgoing transfers. This is intended
to support easier stock allocations by allowing dynamic MTO
assignment/unassignment, e.g. if we have an incoming transfer with
products we want to assign to an existing outgoing transfer, then we can
use the report to create a MTO link to the specific outgoing moves. To
support this assignment flow, the report also allows printing of labels
to place on the product so stock workers know which transfer/MO the
product has been assigned to.
Expected use case is when a product is purchased to fulfil a sale.
Demo data has been added so reception report can be immediately
seen/used for this flow.
Implementation Notes:
- Report has been made flexible to work with batch transfers.
- Only done moves can be assigned to moves that already have quants
reserved (prevents undesired behavior + this makes sense logically)
- Confirmed (+ Done and everything inbetween) moves can be assigned to
any confirmed moves that are not already assigned.
- Report does not affect quant reservation/unreservation at all. It
works only with linking moves (i.e. move_orig_id/move_dest_id) so
move/transfer linkage traceability is stored within db (i.e. this
isn't possible with quants)
Limitations: To keep code simple for now, this assignment flow will
break in certain cases:
1. Done amount of an assigned move is less than the Demand amount
(linked move will not autoreserve correctly when assigned move is
validated, same issue already occurs in multi-step transfer).
2. If a linked move is unreserved after its assigned move is
validated, then another move can reserve its quants and its
assignment link will not be accurate.
3. Already reserved SNs + assign move, may lead to mismatching SNs
between report and what's actually reserved.
4. Changing a linked move's Demand amount after a move is assigned to
it.
5. Potential moves to assign to are only checked for being in same
warehouse, not in a matching source location to destination location.
User is expected to make this match on their own.
Task: 2500844
ENT PR: odoo/enterprise#18268
Upgrade PR: odoo/upgrade#2731closesodoo/odoo#70669
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Infobox to help the user with the replenishment. Allow those actions:
- See the different supplier with their lead time, price and quantity
- Be able to select a supplier and set it on the orderpoint
⁻ See the last delivery by mmonth for the product
- Last purchase date for each supplier
Technicaly it use a wizard and a fields char with JSON used by
a widget to display a static template. Also it creates directly
the wizard in backend instead of just let the view manage the new
object since we need a button on a one2many and if the records do
not have an id, it's not possilbe to use it.
closesodoo/odoo#72039
Task: 2519761
Related: odoo/upgrade#2596
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
General improvements of the new Inventory Adjustment mechanism, among which:
From the Inventory Adjustment page
- A new inventory_quantity_set Boolean field is used to hide the Counted Quantity when not set instead of showing 0.
- Possibile to set 0 as a Counted Quantity directly (not using the set button).
- Allows to provide a name for the Inventory Adjustment when using the Apply button at the top of the tree view. This name is applied on the corresponding stock moves.
- Add warnings when trying to Apply/Set on multiple records when some records are not set/already set.
- Highlight lines when there is a mismatch between Quantity / Counted Quantity / Difference. If the user still tries to Apply, shows the option to either keep the current Difference or the current Counted Quantity for all records.
- Set the user when directly inserting a Counted Quantity (before only when using the Set button)
- Add the possibility to import records.
- Add "To Apply" filter.
- Add a 'Reset' button at the top of the tree view for multiple records.
From the Update Quantity page of a product
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
- Pre-fill a default location (Last used location for tracked products or default destination location in single WH environment)
From the Inventory Report
- Remove the "Updated on Hand Quantity" and can directly change "On Hand" quantity
closesodoo/odoo#71199
Task-id: 2495664
Pr-community: 71199
Signed-off-by: Arnold Moyaux <amoyaux@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
Currently, delivery packaging and product packaging share the same
model product.packaging. In this commit, we make delivery packaging
a new model stock.package.type. The code is also moved to stock
instead of delivery for compatibility reasons.
Task 2341820
PR #63516
ENT PR odoo/enterprise#15363
UPG PR odoo/upgrade#2040
Only administrators can access properties and configure them.
ir.property may contain sensitive information and should only be
accessed via code call to specific methods
New report to easily order missing products in each warehouse.
Orderpoint have a new type: 'manual'. Manual orderpoint are not
trigger by the scheduler but the user could create replenishment
from the report directly. The report use the forecast report in
order to detect missing quantity for today (it does not search
depending the lead time for each product warehouse due to lake
of performance). It compares missing quantity with incoming RFQ
and other ongoing orderpoint. If it still missing a new entry
for replenihsment is created (it's also automaticaly deleted if
the replenihsment has been done another way).
Task: 2161378
Unlinking a return line is convenient and should be allowed for stock
user. Note that the same functionality could be achieved by setting the
quantity to 0 on the line.
related to 65530dfd6aclosesodoo/odoo#48988
X-original-commit: dc77519066993ed245ef863cdf42f6c25e10c99c
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
For stock, purchase, repair and mrp modules, do a small clean of ACL:
Remove duplication and useless line.
Also improve the readability of the stock traceability report.
task-2172399
closesodoo/odoo#45055
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.
closesodoo/odoo#44401
Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Let's say we have a chain of move
wh1 - intercomp transit -> intercomp transit - wh2
The second move will be reserved according to what the first move
brought since they are chained. This behavior resulted in rev[0] which
tries to work around the ir.rule limiting the access of stock.move and
stock.move.line records in multi-company environment.
This patch wasn't perfect since, if the first move brought a lot, the
second move will reserve this lot and it will result in another access
error since the lot will still have the company of the first move.
We fix this by implementing the following logic: receiving from another
company should behave the same as receiving from the supplier, no
reservation is applied. We fix this by marking the inter company transit
as `_should_bypass_reservation` and we break the move chain if the
pull/push rule create an intercompany chain.
[0] 6ff34073153767d449804669f31e26c04de0a670
closesodoo/odoo#45601
Task: 2160847
X-original-commit: 67b45da9d877a5a1bb9adb3ce14051e01f67045f
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value
account*: use account.group_account_user for all transient by default
remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
additional verifications are made to ensure they are executed
only on the documents the user has access to you
give portal access to mail.compose.message as portal still does
some actions like posting messages on the forum
add ir.rule to avoid reading somebody else messages
increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
partner manager for actions linked to partners
avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
event user inherit from sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
manager can set a plan according to group on button
anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
as the source is an account.move
keep the payment.acquirer.onboarding.wizard to system user
only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation
base: base.language.*: allow employee (cf lang_install)
change.password.user: can not read change password wizard of
other users
test.*: no access is needed
Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl
rev[0] aimed to fix an intercompany reservation issue by allowing the
intercompany moves to be seen, however the new domain was too soft and
also allows the visibility of any moves going to a location without
company, for example now outgoing moves to customer from all companies
are visible.
We strengthen the domain to only allow intercompany moves, ie we add the
transit constraint in the domain.
We also fix the same issue for the move line model (see [1])
Now that this one is fixed, the next move is automatically reserved
during _action_done. This didn't work either, so we carefully sudo and
force_company on the destination move.
[0] 3c4bb080c3
[1] f9461c7096a65565a05136a4c6c42ddfa6881926
task-2157248
closesodoo/odoo#42270
X-original-commit: 9a237d1af79519665d0895a30c9ce55a1d835918
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
The commit 3c4bb08 fixed an issue about reservation from transit location
for versions from 11.0 to 12.0 by soften the record rule on stock.move
From 12.3, we need to additionnaly soften the stock.move.line rule
to have the same result as this model has a record rule too since that version
closesodoo/odoo#39859
X-original-commit: b8b63d387b5af5928001ca7a53ef66916bc070b9
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
On a delivery type picking, adds a button to able the partner to sign
the delivery on receipt.
task-1878607
closesodoo/odoo#39183
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Co-authored-by: sle-odoo <sle@odoo.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
-In the action menu, the manager has no rights to delete the scrap order thus
added the access rights for the manager in the main csv file.
task-1959647
Usecase to reproduce
- Create company A and company B with one warehouse each
- Warehouse from A resupply warehouse in company B
- Create a product and check the route MTO and resupply from warehouse A
- Connect as Demo User that only have access to company B
- Do a delivery order in company B for this product -> it creates a
receipt from warehouse A
- Deliver in warehouse A to company transit
- Try to reserve the receipt in company B
-> It does nothing.
It happens because the receipt move is in company A and the delivery
order is in company B. The move is tagged as make_to_order so the
reservation is based on move_orig_ids. However the move_orig_ids is
empty due to record rule that hide since it's in the other company.
In order to fix it, allow to see move from other companies that goes
to transit location.
opw-2033066
closesodoo/odoo#35223
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
This table tracked standard price changes.
It was used to compute the valuation at date in AVCO and standard
through `get_history_price`.
The next commits will introduce the stock valuation layers, separating
the valuation from the stock move. As a valuation layer will be created
when a standard price is updated on the product or when a stock move
impacts the valuation, the information from this table will be
duplicated.
We don't plan to adapt `get_history_price` to work with the valuation
layer since the valuation report at date and today will be the same: a
grouped list on the valuation layers with eventually a domain on the
date.
task-1875873
Create a new report in order to see quantity in the past
and in the future. Also display the planned in and out moves
at their schedule date. The view available for this report is
a graph view even if it could be display with other views.
Technically it's an SQL views based on stock.quant and stock.move
Currently the interval for the report is -3 months, +3 months because
the forecast quantity is based on quants - moves during this interval
in order to keep a linear performance that's not growing with the data.
task: 2000948
closesodoo/odoo#34898
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
This commit adds fields 'company_id' on stock.scrap model.
The company will filter locations and stock moves linked to the scrap
document.
We add also a specific sequence by company.
Task-1930055
closesodoo/odoo#30498
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Commit 240d191ba3 introduced the field
company_id on model stock.move.line and a python constraint that check
if the company is the same on the move line and on the related move.
In order to avoid performance issue, this commit replace the constraint
by a 'related' parameter on the company field.
As the company_id is not editable we suppose this change will not introduced
unwanted errors
Task : 1970012
closesodoo/odoo#32738
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Purpose
=======
Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.
Groups should be reorganised on the users form to be more explicit.
Specification
=============
1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
A category 'Operations/Project' will create a category Project with a parent
category 'Operations', and something smart is already developed (in modules/db.py)
to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category
closesodoo/odoo#29362
Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>
PutAwayStrategy model was deleted and FixedPutAwayStrategy model was
renamed into PutAwayRule.
Now, each location can contain multiple putaway rules, each rule
applying either on product or on product category.
The purpose is to:
- Add more visibility on putaway settings (with a stat
button on product, product category and location views, and a
submenu item in Product configuration menu).
- Change putaway model to avoid redundancy.
Task #1935169closesodoo/odoo#30889
There is no company_id field on stock.move.line and it is so impossible
to restrict easily the access rights on move lines (except by passing
through stock.move, but all stock move line don't always have a
stock.move)
To resolve this we've added a field company_id on stock.move.line, and a
constraint to force it having the same company_id than the one on stock
move.
Task ID : 1905232closesodoo/odoo#28575
The field sale_id on model stock.picking is not defined in stock module.
So the rule was wrong when sale_stock was uninstalled.
opw:1912564
closesodoo/odoo#29145
Targets commit d3530eb07e
Purpose
=======
[Follow up AL review]
Code cleanup and some improved models naming for the product configurator feature (see targeted commit).
Mostly changes the "product.attribute" related models.
Updated models:
- "product.product.attribute.value" to "product.template.attribute.value"
- "product.attribute.filter.line" to "product.template.attribute.exclusion"
- "product.attribute.line" to "product.template.attribute.line"
Updated fields:
- [sale_order_line in sale/sale.py] "product_custom_variant_values" to "product_custom_attribute_value_ids"
- [product_template_attribute_value in product/product_attribute.py] excluded_for is now a o2m instead of a m2m
- [product.attribute in sale/product_product.py] "create_variant" field is now a Selection with "no_variant" (old false), "always" (old true), "dynamic" (new value)
- [product in product/product.py] "product_attribute_value_ids" to "product_template_attribute_value_ids"
Task #1871557
Purpose
=======
- Configure a product from a sales order as easily as in the ecommerce
The backend uses the same template as the frontend to configure a products and its options
- Display optionnal products of optionnal products in the "sale options" section
- Allow adding exlusions to some combinations of the product and/or
to some combinations of the optionnal and accessory products
Specification
=============
PHASE I
1. Improve the "Add to cart" with optional products
- When you add an option to cart, move the product to the cart & show the options of this option
- Don't open the option wizard if no option available (in case this module becomes generic,
it's better to skip this step when it's not needed)
- Display the options right under their related product in the cart
2. Do not allow to add the product as an optional product for itself
Why ?
- No functional sense
- Creates issues in the add to cart wizard
3. Exclude some attribute combinations within the product or with related options and accessory products
- Rename VARIANT PRICES button -> CONFIGURE VARIANTS
- When you click this button and select a value, open form view rather than inline edition
- Form view of variant values:
- Attribute
- Value
- HTML Color Index
- Attribute Price Extra
- Not Compatible with: o2m tab with 2 fields: Product AND Attribute Value (of this product)
[m2m tag selection]
- in any new line, autocomplete the current product by default
- Tooltip: A list of product and attribute values that you want to exclude for
this product's attribue value. Also applies on optionnal and accessory products.
4. New option to configure a product in a sales order line
- This option is only visible if the corresponding option is activated in the sales settings
- It opens a wizard to select a product template, configure related attribute values
and select optional products (based on frontend view)
- Attributes not compatible with other selected attributes should not be selectable
- Must work like in the frontend
William Henrotin