When downloading the digital file, if there exists one SO linked to the
current customer and that contains a Note/Section, the web page will be
redirected to the "Internal Server Error" web page.

To reproduce the error:
(Need sale_management)
1. Create a customer C
2. Grant C portal access
3. Create a product P
    - Add a digital attachment
4. Create a SO
    - Customer: C
    - Add product P
    - Add a note
5. Save, Confirm, Create Invoice, Register Payment
6. Sign in with P
7. Consult the SO web page
8. Download the file attached to the SO line

Error: The page is redirected to the "Internal Server Error" web page.

When downloading the document, the module checks the customer's access.
To do so, it gets all relevant invoices and free products. Here is the
problem, when getting the free products, the domain includes the SO
lines used for Section and Note. As a result, when it tries to read the
product of such a line, this will raise an error.

OPW-2419478

closes odoo/odoo#66904

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

- Install Sales (sale_management) and Digital Products (website_sale_digital)
- Go to Sales
- Create a product
- In product form, add a digital file via "Digital Files" smart button
- Create a quotation for current user
- Add created product
- Add a product with a negative price and make sure that the amount total ofthe order is 0.00
- Go to Website
- In portal, go to "My Account" and "Sales Orders" in Documents section
- Open created SO (with total=0.00)
- In the products list, there is a dropdown download button next to the created product
- Click on the download button and select an item in the list
You are just redirected to the list of SO in portal.

The button to download Digital Files appear for a product if one of these conditions is verified:
- The SO has been paid
- The product is free
- The SO is free (The amount total is 0.00)
But during the download action, a check is also performed allowing only to download Digital Files
from products verifying one of the 2 first conditions.

opw-2265402

closes odoo/odoo#52886

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit and since beaa30a3 it was not possible to download a
digital product.

The `search_read()` would return move line which does not have any `product_id`
which will later crash when accessing `product_id` in the for loop.

Search_read result would be:
[{'id': 20, 'product_id': (38, 'eBook: Office Renovation for Dummies')},
 {'id': 21, 'product_id': False},
 {'id': 22, 'product_id': False},
 {'id': 23, 'product_id': False}]

task-2063307

closes odoo/odoo#38225

X-original-commit: b045be2814cee96c9723f0c9d07462e07cab4773
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

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

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

Before this commit, an Error 500 was thrown to the user upon downloading an attachement
It was due to two things:
- wrong return on a function
- the filename that http.send_file takes shouldn't be a string, but bytes in Py3

In Python 3:

* various builtins and dict methods were changed to return
  view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
  removed altogether

This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).

Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.

issue #8530

- Buy only a free product with digital download content
- It is not possible to access the download link

Since the product is free, there is no invoice created. Therefore, the
product is never considered as paid.

opw-705258

Following commit 1a1efe3f, the module has some troubles to work
correctly. For example, it's impossible to get the download link in the
frontend of an attachment when the product was bought and paid.

Not really a big deal, but just in case the client wants to download
what he bought, we add back the link in the eCommerce.

A more complete fix will land later in master branch.

opw-705725

Those module were almost already migrated, this commit simply modified the import and the xml tags.

Ok it was already written in new api, so what is the purpose of this commit?
Just a nice spring code cleaning.

Closes #10941

Now using a method for the selection. This method is overriden in
various addons to add specific selection entries instead of
completely hardcoding the values. Indeed this breaks inheritance.

Some views have been updated to try to make the various attributes
more inheritable-friendly.

[ADD] website_sale_digital: allows the user to set a product as digital product and use the attachments to sell files. The download link is added on the My Orders page when the payment is confirmed