Automatically activate `group_multi_currency` if there is more than one active currency,
deactivate it if there is only one active currency
retain sale/pos feature of activating group_product_pricelist
adapt tests accordingly
Task 2610735
closesodoo/odoo#74396
Related: odoo/enterprise#20106
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This commit replaces the old online payments API of the `payment`
module with the new one and adapts to it all the implementing modules.
See the merge commit for more details.
task-2085989
task-2119838
task-2165982
task-2289255
Co-authored-by: Victor Feyens <vfe@odoo.com>
If a user has no access to Invoicing module, he can not send and print his invoices.
To reproduce the error:
(Need sale_management,account)
1. Connect with admin account
2. Settings > Users & Companies
3. Create/Edit a salesman
- Remove access rights to Invoicing module
4. Connect with this user
5. Create & Confirm a SO
6. Edit the SO and fill in the "Delivered" field, Save
7. Click on "Create Invoice", "Create Invoice"
7. Connect with admin account
8. Invoicing > Go to the previously created invoice
9. Confirm it
10. Connect with the user account
11. Sales > previously created SO > "1 Invoices"
=> The user can read the invoice, but he can not send and print it. This is an error.
OPW-2389428
closesodoo/odoo#64508
X-original-commit: f64f7ca309f9228e58b1487a286f2302ff8f035e
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
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
Since https://github.com/odoo/odoo/commit/7d8df4bec192e5a2ff3341dcf43d59e06a57f9a9, the groups
managing pricelists features have been updated.
But the onchange feature enabling pricelist on multi-currency activation was wrongly
adapted, it was only activating advanced pricelists, iff basic pricelists were enabled.
The wanted feature is to activate pricelist (basic pricelist features: group_product_pricelist)
when multi-currency is enabled.
Also add an implied_group on multi_currency group to enforce this behavior.
closesodoo/odoo#49633
X-original-commit: f862f9650395b02f6a43c57cdf232a309fa6948e
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the same xml file (meaning one of the two rule is useless, or wrong
if giving less rights than the other).
Removing rules that had no impact will ease the understanding of
security problems, by reducing the number of interconnecting rules.
The field 'type' in the account.move model has been renamed into 'move_type'
but the ir.rules of the sale module have not been updated.
The fix consists in renaming this field in ir.rules.
As another bug was due to this field renaming (see 51b70b6fc4), I have checked
that the old 'type' field is no more used in Odoo files.
closesodoo/odoo#46398
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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
Without any access rights on the 'account' module, a salesperson should be able to
create a new invoice from a sale order.
Since the merge of account.invoice with account.move, we need to manage carefully the
access rights when dealing with invoices. A salesperson must not be able to manage the
journal entries except the one being an invoice created for a sale order.
To make such restriction on the journal entry's type, we need additional record rules
- in sale: to restrict the access to invoices.
- in account: to exit such restrictions when having billing access rights.
closesodoo/odoo#44023
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Remove the "sale.group_sale_order_dates" group and settings, all the date
fields are always displayed but we put schedule_date and commitment_date
(for which the label was renamed "delivery date") on the same line (with
a design to make the schedule date looks like a suggestion for the
delivery date).
task 2057802
closesodoo/odoo#37174
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
Sending a quotation by mail is really rare and the option is still
available in dropdown menu. It is also confusing to see the document status
changed while you just want to print as a draft sometimes. So the PRINT button
is removed here.
Only displayed UNLOCK/LOCK for 'sales managers' if the
option “Lock confirmed orders” is activated in the settings.
Removed the ability to open the payment terms via external button
in edit mode
Removed the left,right and top borders in the field of terms and condition.
Kept only bottom border.
Event and Event ticket will come after Product regardless of it being a
template or the product.
In the sale order's form view, made certain changes like shifting
the positions, removing the field, adding title, keeping the field
in debug mode.
task-2033229
The group 'group_discount_per_so_line' is used on reports in
point_of_sale but is created in 'sale' module and point_of_sale doesn't
depends on sale. So we've move this group on product to be able to
properly use it in point_of_sale.
TASK-ID: 2008468
closesodoo/odoo#35041
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Some modules expect the users having the sales_team.group_sale_salesman group
to be able to read payment tokens (credit cards).
Payment tokens are defined in payment.
Both are a dependence of sale, which is thus the lowest common denominator.
opw 1965213
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
The sales order is a important model. Since it generates invoices and other business
documents, the company_id field should be required as the company must be propagate
to generated documents.
Moreover, a sales order without a company raises a error, and we need a company to
compute the multi currency rate.
This commit fixes that bug, by setting the company_id field required on sales order
and sale order line.
Note: we only simplify the ir.rule of sale.order, and not the one of
sale.order.line. Indeed, when creating an SOL, the creation is done
in 2 times by the ORM: first insert, then UPDATE with computed stored
fields. As company_id of SOL is a stored related, the check access rules
raises during the inconsistent state (between INSERT and UPDATE,
company_id is False).
Maybe this will be clean after the big refactoring of the ORM.
Task-1999686
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
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
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>
Payment providers can be used without eCommerce. Therefore, we should be
able to access the payment transactions with only `sale` installed.
opw-1941591
closesodoo/odoo#31270
Targets commit d3530eb07e
Purpose
=======
Users within the "sales_team.group_sale_salesman" group should be able to
access/add/edit/delete custom attribute values.
closesodoo/odoo#27654closesodoo/odoo#27679
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"
Purpose
=======
Product attrivutes can now have custom values.
These values are specified by the user during the SO creation.
They are also available on the webshop frontend.
Specification
=============
add a new mode to generate variants as they are added to the order/cart
- ability to define attribute extra prices & exclude combinations
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
This commit dissolves module into sale and sale_stock. Indeed
some fields will be needed for services in next development.
- module is replace by a group in sale
- `commitment_date` and `expected_date` are moved into sale
directly, because they are meaningful for purchasing services
- `expected_date` implementation change when sale_stock is
installed, as the picking_policy of the SO determine if the
min or max dates should be chosen.
- `effective_date` is moved to sale_stock
- tests are moved into sale_stock, and tagged to be executed
after install (post install) otherwise it fails (since
sale_order_dates was a leaf module, it makes sense).
From a functionnal point of view, nothing should have changed,
except that user can see `commitment_date` and `expected_date`
even if sale_stock is not installed, by activating a group.
Task #39340
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).
In Sales, we want to merge the `All Channels Sale Orders` report with
the `Sales` report in order to avoid having information scattered
accross two different reports.
Related to task #58961Closes#23324
The goal is to be able to more easily create section and notes on sale order, invoice, and quote.
================================
Problems of the existing feature
================================
The problematic part in the existing feature was that the same section had to be defined again and again for every line, instead of being defined only once where it needed to be. There was also no easy way to move them. Those concerns are solved here.
Moreover, due to the complexity of the feature, it was hidden by default, requiring a setting and multiple overrides. The new feature is simple enough that it will always be present.
==================
New implementation
==================
Sections are lines solely used for display purpose, there is no business logic attached to them. They will show as a nice header at the top of the section, and a subtotal at the bottom of the section.
We also take the opportunity to add notes, which are just like sections except they are displayed differently and don't include a subtotal.
=========
Reasoning
=========
We decided to implement it this way, as opposed to creating a proper section model, because it creates less changes in the code.
Creating a intermediary section model between the sale order/invoice/quote and their lines would have required to rewrite the entirety of the code associated to them. It would also have required to create a new JS widget to handle on the same view a double-level One2many (or a One2many + group by).
The current solution is much easier because it just requires adding 2 buttons, 1 simple field on the corresponding models which even has a NULL default value, and making some business checks (don't apply business to section/note).
We tried our best to impact as less as possible the existing models. Notably we didn't want to add any extra field if this was avoidable. This also makes the migration easier.
No matter the implementation choice the views/reports had to be updated to display the sections and notes correctly, which has been done.
===========
Limitations
===========
The current solution has several limitations:
* since the sections don't have business logic, it's not possible to make any reporting based on them
* any business related to sections has to be computed on the fly by browsing in order all of the lines, notably the subtotal has to be computed on the fly at every display
- when sections are moved (drag&drop) on the back-end, the following lines that are part of the section are not moving with the section
===========
Technically
===========
The commit will:
* update the models to add the display_type field (along with related sql constraints to guarantee integrity)
* add new buttons at the bottom of the lists to allow creating section and note, along with the existing add a line/product button
* add some business checks to not apply business to section/note (product_id and account_id became non-required fields)
!!! The most likely cause of potential bugs introduced in this commit would be to have forgotten to add those checks on some places where they would be needed. This is tedious to check but fortunately easy to fix.
* update the views to display sections and notes correctly, also made various improvements/fixes to those views (notably to apply B2B/B2C setting more consistently)
!!! This is the second likely cause of potential bugs: if the updated views are inherited in a way that is not compatible with the changes. Or if we forgot to apply the changes to some other views. Again this is tedious to check but fortunately easy to fix.
Task #53996
PR #25209
Since sale depends on account and not the other way around, it's better to have this setting inside account.
Functionally it will allow the user to benefit from this setting also if he uses only invoice without sale.
Technically it will allow us to remove all of the overrides that were previously necessary for this setting.
While we moved the setting, we also renamed the different variables so their name better convey their meaning.
PR #25209
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
This commit improves sale management through a better integration of
activities and addition of automated activities. Several things are done
in this commit :
* automatic activities generation is added for sale order upselling.
They are also automatically removed or updated when the sale order state
changes from or to upselling to avoid bloating users with unnecessary
activities;
* a menu to configure activity types is added. Indeed HR managers should be
able to see and configure activity types related to their job;
Technically we choose to override _write in order to catch the invoice_status
computed field update and try to have a lightweight implementation. Indeed
sale.order is a complex model and we tried to have a low-level override
that do not mess with business overrides.
Victor Feyens