l10n runbot builds are all failing when running at least one test depending of AccountTestCommon because it:
- doesn't create a sandboxed testing environnement to manage the multi-currency, multi-company, the default company's currency, the exchange rates...
- doesn't setup a testing user then all tests are done using the superuser.
- doesn't provide a fully setup chart of accounts: exchange difference journal is not set, accounts have bad types, etc...
- is run sometimes at-install.
--task: 2301180m
Purpose
=======
The goal is to avoid duplicate code between portal and sign (enterprise), and
also to allow the user to use the signature mode 'auto' and 'load' in portal
(before this commit only 'draw' was available in portal).
The sales order signature (currently the only portal signature) has been changed
to use this new code.
This signature widget has been improved:
Improved style:
- better structure and use of BS classes
- removed most of custom CSS
- made it more responsive
Changed code to follow guidelines, added JSDoc.
Technically
===========
New widget NameAndSignature common to portal and sign (enterprise).
Reworked existing portal signature form to use new widget.
Related to enterprise PR https://github.com/odoo/enterprise/pull/3266
task-1894903
closesodoo/odoo#29453
This commit has several parts:
- fix ordering of attributes and values
- fix/create python logic (notably for checking the possibility of a combination
and for price computing)
- fix currency
- display correct info on the views without the need of JS (prevent flickering)
- fix various issues with website and SO
- add a lot of tests (both unit and tour)
================================================================================
*** Make consistent the filtering and ordering of product variants ***
Filter & Check possibility
==========================
The first variant shown on the website should always be possible.
When activating the customize "list view of variants", we don't want to show
impossible combination on the list.
We also don't want the user to be able to add to cart an impossible variant.
Show appropriate messages when no combination is possible.
Order
=====
We want the variant order to be consistent with what the user selected with the
sequence fields. The display order on the website should be the same than the
display on the various backend views.
This implies also fixing the order of:
- product.attribute
- product.attribute.value
- product.template.attribute.line
- product.template.attribute.value
The general order is now: (parent,) sequence, id.
Before, it was already a mix of those, but not always in the same order, and not
every key for every model. The name has been removed from the order: either we
sequence them correctly, or we want them in the creation order.
On the website, the first combination shown by the python should be the same as
the one that will be computed by the JS to prevent flickering.
Ideally there should be no RPC at page loading if the python has computed
everything correctly, but it is currently not possible to achieve because the
view logic for website_sale_stock is only in JS.
================================================================================
*** Fix product template and variant price computation ***
Move and improve the get_combination_info method:
- take into account tax included/excluded settings (B2B/B2C)
- take into account pricelist discount policy (striked price)
- fix inconsistencies when price after pricelist would be 0
- use proper rounding and discount compute with the currency helper methods
- fix an issue where context "partner" would have a mix of id and recordset
================================================================================
*** Fix currency conversions ***
The list_price and lst_price of a product are always encoded using the currency
of the product.
The results of "combination info" are always returned using the currency of the
pricelist if given, or the currency of the product.
The prices on an order (line) are encoded with the currency of its pricelist.
================================================================================
*** Fix dynamic variants access rights ***
Public users on the e-commerce should be able to create product variants if the
configuration of the attributes of the product template is set as "dynamic".
This uses "sudo" to bypass create security rules for public users.
Multiple checks are done to ensure that it creates a valid product variant.
================================================================================
*** Miscellaneous bugs, tracebacks and necessary improvements ***
In general:
- correctly show warning when no variant is possible
- don't let user add to cart an impossible variant (from optional product
modal or from any RPC), both in interface and controller logic
- fix as much flickering as possible by correctly pre-computing in python/views
- move business logic from controllers to models
- correctly add no_variant and is_custom values on the SO line description
Sale order:
- fix traceback when emptying the product_id field from configurator
website_sale:
- correctly compute first image / carousel, and correctly swap images when
changing variants, without duplicate image or zoom problems
- don't use list view of variants when it doesn't make sense
- added missing product info when adding a no_variant attribute to cart
- fix cart accessory product computation
website_sale_wishlist:
- fix it with dynamic variants, no_variant and is_custom
website_sale_comparison:
- fix it with dynamic variants (comparison and alternative products)
website_sale_stock:
- fix it in general (some flickering still present)
================================================================================
Authored by @seb-odoo with contribution from @awa-odoo
task-1910821
closesodoo/odoo#28079
When creating a credit note from an invoice coming from a Sales Order,
only the "modify" mode links the refund lines with the sale lines. This
link make the invoiced quantity decreased on the sale line, which is
a willing behavior.
The 2 other modes ("cancel", and "create") does not do that link.
As the behavior of the "modify" mode was introduced as bugfix years
ago, it was time to clean that !
This commit
- extends the behavior to every mode: all refund lines are now
linked to their origin sale lines, so the invoiced quantities
are correctly applied
- clean the bricolage used to determine the invoice of the
sales order (`_get_invoiced` method) by avoiding searching
on the document source field.
- provides some tests. The old one was moved and extended.
Task-1859308
closesodoo/odoo#28471
This commit provides a test suite for sale flow and unit tests.
We split tests in different files to try regrouping them by
testing purpose:
1/ test_access_rights.py checks employee, sale person, sale manager
and portal access rights. It is executes in post-install mode to be
sure other addons does not break the security rules.
2/ test_onchange.py checks the onchange using the SFF mecanism in
order to simulate what a sale person really does in its day-to-day
job.
3/ test_sale_pricelist.py execute a sale flow with different pricelist,
as this is a delicate aspect.
4/ test_sale_to_invoice.py contains tests about refund, discount and
downpayment, as none of those were tested.
Task #43928
Since the reinvoice policy and delivered quantity fields
on SOL have been refactored, it is now time to provide
some tests for the new reinvoice flow.
The reinvoice test should be execute at install, since
delivered quantity computation change when stock/service
are installed. They should provide their own test suite
for reinvoicing flow. Here, we test the vendor bill
mecanism: setting an AA on invoice lines will create
SOL when validating invoice.
Since quantity to invoice and quantity invoiced
already take into account refund invoices, the
calculation of those amounts can be simplify.
Also, we simply need those on the sale.report,
so removing them from sale.order.line model
will ease performance.
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
This reverts commit 9ab421d99a.
We should use the active field on the ir.ui.menu with the root menuitem instead of moving all the menuitems into a new module
Purpose
=======
Don't display sales app icon in Odoo homepage when installing ecommerce (only website should be visible)
it's confusing to have sales icon -> where do I manage my sales? In sales or in website? -> in website
Specfication
============
We need one new modules to add Sales menus to the homepage. Currently they come with "sale". So when installing "website_sale", we get them (because sale and account are dependencies of website_sale). We don't want that anymore. Along with that you need to replace modules in Apps menu:
sales menu items must be in the new sale_management module, no longer in sale
- create new app "sale_management"
- Currently 3 app icons when installing ecommerce (Sales, Invoicing, Website) -> too many icons, where to start? -> GOAL: Only 2 icons > Website, Invoicing
- new module to display Sales Icon (like account_accountant): "sale_management"
- move menu items to sale_management
- sale, sale_management: move app description, rewrite the manifest file
- sale, sale_management: move tour from sale > sale_management
- Changes in some dependency module "sale" > "sale_management" modules: event_sale, mrp_repair, pos_sale, report_intrastat, sale_crm, sale_expense, sale_stock, sale_timesheet, website_quote
Menu items to move 'sale' --> 'sale_management'
===============================================
Sales
Quotations
Sales Orders
Invoicing
Orders to invoice
Orders to Upsell
Catalog
Products
Product Variants
Pricelists
Reporting
sales
Configuration
Settings
Products -Attributes, Attribute Values, Internal Categories
-account:_fix_tax_included_price
If a fiscal position mapped an included tax on a SO or on a PO line
then the price unit of the product must be recomputed.
-purchase: onchange_product_id test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
-sale:product_id_change test
Test that when an included tax is mapped by a fiscal position, the included tax must be
subtracted to the price of the product.
opw:647321
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
Laurent Smet