summaryrefslogtreecommitdiff
path: root/addons/product_email_template
AgeCommit message (Collapse)Author
2021-04-25[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-03-28[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-02-21[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-02-14[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-01-31[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-01-17[I18N] Update translation terms from TransifexOdoo Translation Bot
2021-01-10[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-11-15[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-11-08[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-10-27[I18N] *: Update translation terms from TransifexMartin Trigaux
Except Spanish, waiting for cleanup closes odoo/odoo#60848 Related: odoo/enterprise#14421 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2020-10-21[FIX] product_email_template: use superuser account to send email in su modeNicolas Galler
Behavior prior to the fix: The email template associated with a product on an invoice placed via the web portal is sent with no email_from, resulting in a failure. The reason is that before 13.0 .sudo() before sending a mail would send it as superuser user (which was the intention in this case), but since 13.0 for the same intention we need .with_user(SUPERUSER_ID). Behavior after the fix: When sending the product email, if we are in SU mode, we'll switch to the super user account, emulating the pre-13.0 behavior. Similar fix to b12bcfbb1b44cc72cdf73506c540c387f00a37e9 opw-2346415 closes odoo/odoo#60409 X-original-commit: 7749fec536bd1533f0da0a2bc0df084e4e80ed4d Signed-off-by: Nicolas Galler <nicocrm@users.noreply.github.com> Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
2020-10-21[REV] *: revert fb7407c for spanish translationsOlivier Dony
There was a problem in the Transifex translations for Spanish and all translations were overwritten by mistake with english defaults. This commit reverts all modified es.po files to their previous version while we work to restore the translations on Transifex.
2020-10-18[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-10-11[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-09-27[I18N] Update translation terms from TransifexOdoo Translation Bot
2020-09-01[I18N] export saas-13.5 source termsMartin Trigaux
Without demo data closes odoo/odoo#56839 Related: odoo/enterprise#12821 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2020-08-05[IMP] account: soft post entries in the futurewilliam
Add an easy way to not post the entries in the future when calling post() on it, but rather set it to be auto-posted at accounting date. This is useful when we are creating a lot of entries in batch and some might be in the future, some in the past, and we don't want to separate that in two batch every time. (asset, accrual, transfer,... )
2020-03-25[FIX] product_email_template: use correct parameter for notification layoutSwapnesh Shah
Message post with template has to be called with a notif_layout parameter in order to have a layouting correctly set through the call chain. closes odoo/odoo#48359 X-original-commit: 077f58027e29a50cd9a9bf455b5ca5c482503686 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
2020-02-19[IMP] account,* : Change type field to move_type in account.moveAnkita Raval
task-id: 2028z813
2019-12-10[FIX] product,(_email_template),sale: fill the blank hole for empty groupnje-odoo
before this commit when we installed website_sale and event_sale module. it will display blank hole before Events group because 'email_template_and_project' group is define in product/product_views.xml as invisible. So fix this issue by moving this group into product_template_email/product_view.xml and also rename the group as email_template because this group is not related with project. Also keep sale group empty in 'sales' page so other views updated to make compatible with new group changes. To keep groups in ordered, set the priority in view. task-2150643 closes: #41308
2019-12-10[I18N] *: remove es_AR translationsMartin Trigaux
Followup of a425695e The terms were back in 12.0 Courtesy of Juan José Scarafía closes odoo/odoo#41624 X-original-commit: 85d0c7001a997748d7691205bbb8d066597591a5 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
2019-12-03[FIX] product_email_template: use proper parametersNicolas Martinelli
`custom_layout` should be set as a context key, otherwise it crashes at creation because of non-existing field. opw-2146695 opw-2149726 closes odoo/odoo#41238 X-original-commit: f9837eb08a316965057fe239f434b1c6d5c0196c Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
2019-10-07[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-10-01[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-29[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-25[IMP] * : manifest module categories cleanupVictor Feyens
closes odoo/odoo#35754 Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
2019-09-15[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-09-01[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-08-14[MERGE] forward port branch saas-12.4 up to 98a55917a60Christophe Simonis
2019-08-13[I18N] *: export saas-12.4 source termsMartin Trigaux
2019-06-28[IMP/REF] accounting-pocalypse yeaaahhLaurent Smet
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
2019-06-03[MERGE] forward port branch saas-12.2 up to 995aa1685eeChristophe Simonis
2019-05-31[MERGE] forward port branch 12.0 up to 8f21148e1a8Christophe Simonis
2019-07-17[REM] *: calls to @api.multiAdrian Torres
Multi is the default api for methods, it is not necessary to explicitly decorate methods with it, adds clutter and most people use it because they see that the rest of the code uses it. Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
2019-07-01[MERGE] manual forward port of accounting-pocalypse ↵Laurent Smet
(beaa30a3d1843de43a45f419bfbc1bfa7613a920) 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
2019-05-27[FIX] sale,product_email_template: match the help with the behaviourJorge Pinna Puissant
Before this commit, the help of the product_email_template module said that the email is sent when the invoice is paid. This is not the case, the current behaviour of the module is that the email is sent when the invoice is validated. Fine-tuning of : 4b5265b9b99a7ded943c5692d927b3a6163d75da, 10eee18a047d35305dc46282e610e88936d81ffc and 33a413eb2944db4a35d035f42161159ae53dd830 opw-1973946 closes odoo/odoo#33686 Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
2019-05-12[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-03-24[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-05-12[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-05-05[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-04-28[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-04-21[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-04-07[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-03-10[I18N] Update translation terms from TransifexOdoo Translation Bot
2018-12-02[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-03-03[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-02-24[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-02-10[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-01-21[I18N] Update translation terms from TransifexOdoo Translation Bot
2019-01-06[I18N] Update translation terms from TransifexOdoo Translation Bot