Improve Send & Print general usability by making it more streamlined overall.
Options are not activated but preemptive problematic partners are shown,
and skipped during the sending process.
closesodoo/odoo#131448
Task-id: 3336623
X-original-commit: 4105994e778459c869d885d017118492ffcd2064
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Yosua Nicolaus (yoni) <yoni@odoo.com>
In case of error, the send & print wizard is crashing or log an error on the invoice chatter.
In that case, nothing is sent to the end-customer.
This is problematic for all flows in which we want to send a mail to the customer automatically.
For example, e-commerce with automatic invoicing or subscription/recurring invoices.
To avoid that, the current logic of the send & print has been reshaped. In case of error, a proforma
PDF is sent instead. This is exactly the same document as the PDF but without the legal layer.
To do that, a lot of refactoring has been necessary to always provide the cumulated data for invoices
to be able to access the generated proforma report and to allow the overrides to know exactly in which
mode the hooks are called.
Also, this commit renames the method by something less generic about invoices. Indeed, this wizard needs to be
usable for others documents than invoices. That's the purpose of the invoice_single/invoice_multi mode.
For that reason, all methods about invoices are now expricitely prefixed by 'invoice'.
Fix also a performance issue on multi-invoices since the invoice_pdf_report_id document was invalided for the
whole model instead of the current record. When dealing with X invoices, the whole model was invalidated X times.
Fix the managment of attachments:
- The manual attachments wasn't send when sending a mail 'invoice_single' mode.
- When changing to another mail template, the manual attachments were lost.
Fix the double generation of PDF using a web-service.
When opening again the send & print wizard, the PDF must not be regenerated but reloaded from the previous one.
Task: 3339352
X-original-commit: e9e90811aeee46989a83b21f9b59071a9c7bc362
Part-of: odoo/odoo#124436
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, the invoices were marked as sent only when
sending them via email or post.
After, it is mark as sent once the PDF is being generated via the
send&print wizard, as it becomes computed based on the presence of
the PDF.
Rational, we want to consider a generated invoice via the
send&print wizard as being sent as it can be printed/downloaded.
This also makes the invoice available in the portal.
closesodoo/odoo#117085
X-original-commit: 9e656aabe4f6840ee5c200a21832dad958ea6892
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Detry Thomas (det) <det@odoo.com>
Refactoring send&print wizard.
==============================
Main reason for this commit is that we want to let the user
decide when to generate the relevant documents / approvals
for its invoices. The natural choice is when the information
leaves Odoo. So now, each time the users decide to
download/send its invoices, he will be able to select the
relevant documents to be generated and the approvals to be
requested from the send&print wizard.
This used to happen automatically during the posting with lots
of undesirable behaviors (difficulty to update/revert, hard to
know exactly what will happen,...)
Main changes:
1/ Send&print wizard
- The model 'account.invoice.send' has been replaced by
'account.move.send' and became models.Model to handle
asynchrounous generation of documents (webservice,..) in
case of more than one invoice.
- The wizard is meant to be overriden in order to add
checkbox and document to be generated. A comprehensive exemple
can be found in account_edi_ubl_cii.
2/ Import invoice from attachments
- The decoding logic has moved from account_edi to account
on the attachemnts.
- The function _extend_with_attachments() serve as a common
entry point for import (from chatter, dashboard).
3/ Export invoice pdf / document
- All the specific actions to export attachments should be
implemented on the account.move and called from the wizard in
_generate_documents()
- The official pdf for the invoice is now only generated once
the user request it. In order to regenerate the pdf and
documents, it needs to be deleted.
task-id: 3117238
[enterprise](https://github.com/odoo/enterprise/pull/36757)
[community](https://github.com/odoo/odoo/pull/111857
)
[IMP] web: enable close on ir.actions.act_url in wizard
Before this commit, calling ir.actions.act_url on a modal
leaves the modal open. Which feels ackward in the send&print
wizard.
We now enable 'close' parameter on ir.actions.act_url. If set,
the wizard will close after act_url.
closesodoo/odoo#111857
Related: odoo/enterprise#36757
Related: odoo/upgrade#4387
Signed-off-by: Laurent Smet <las@odoo.com>
Snailmail holds an abstract model 'snailmail.confirm' that implements some
kind of generic confirmation flow. It is nowadays used in a single case
that is the 'snailmail.confirm.invoice' wizard that inherits of it in
snailmail_account.
In this commit we remove the base abstract model, as it is defined once
and does not really add value. This kind of generic model actually adds
more noise than solves issues.
The invoice confirmation wizard is now completely defined in snailmail
account bridge, easing understanding of models.
Task-3046371 (Mail: Better Language Support in Composer)
closesodoo/odoo#111901
Related: odoo/upgrade#4299
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
*: im_livechat, snailmail_account, survey, web_editor.
The callback registered by the bus service method onNotification was
not the same unregistered by offNotification. Since those method were
superfluous, they have been removed in favor of (add/remove)EventListener.
closesodoo/odoo#96684
Related: odoo/enterprise#29819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
on/off are deprecated in favor of addEventListener/removeEventListener.
Calls to the bus service have been updated to reflect those changes.
task-2053917
closesodoo/odoo#96017
Related: odoo/enterprise#29501
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Some legacy services are still relying on the bus_service as a dependency.
However, this service is now a wowl service which means those services
won't start.
closesodoo/odoo#96001
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When clicking on send&print on an account move without
partner, we are getting a traceback because of the
address verification.
Instead, check if any such move is selected and return
a user error.
Task id #2655365closesodoo/odoo#77385
X-original-commit: dfba014189c35f9df0140c57effe9ea45637e0ec
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
Tests now check for the 'error' field in Pingen repsonse
snailmail_external_layout.js now targets the right div
closesodoo/odoo#76288
Task: 2588145 & 2583718
X-original-commit: 64ba95bc847f9db661d0e348f8bca1249da0b960
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit implements improvements in the layout designer, such as addition of a new custom background, adds custom report footer and company details.
task-2355704
closesodoo/odoo#66860
Related: odoo/upgrade#2275
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
If 'send by post' is enabled and the address is incomplete when we send one invoice, display:
"The customer's address is incomplete:" followed by a link to the corresponding partner
If 'send by post' is enabled and some addresses are incomplete when we send invoices in batch, display:
"Some customer addresses are incomplete. [number of incompete addresses] Contacts"
and if we click the Contacts, we will be redirected to the corresponding Contacts
Purpose:
When the user tries to send an invoice by post, the system warns him that the customer's address is incomplete.
But then, it's a dead end. The user doesn't have any tool to rectify the situation.
closesodoo/odoo#69469
Taskid: 2502597
Related: odoo/upgrade#2445
Signed-off-by: Arnaud Joset <arj-odoo@users.noreply.github.com>
When trying to send&print a move without partner_id, which can be done
from the tree view of the account moves, a traceback will be raised when
the address is being validated.
This change will make sure to avoid that and also shows that the adress
is not complete in the wizard if needed.
closesodoo/odoo#69602
X-original-commit: 0ce5f8617fdcf3601f937c35660563cb3c79fbbe
Signed-off-by: William André (wan) <wan@odoo.com>
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Thanks to this setup, we will be able to run the tours independently to any demo data.
To do so, the HttpSavepointCase is born to do the same as HttpCase but with a setUpClass.
--task: 2290120
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,... )
The tests must be only imported in a test context, not in a running
context.
Since 92a7f8c a new test requirement was added but it should
not be necessary to run a module, only to execute the tests.
closesodoo/odoo#53628
Related: odoo/enterprise#11882
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Show a confirmation dialog when a user is sending the very first letter.
=========
Purpose
=========
It happens from time to time that a letter gets sent by accident to a
final customer. This situation is always a bit problematic and is
usually only uncovered when it is too late. Having an additional
warning when sending the very first letter should help avoid that kind
of issue.
================
Specifications
================
Display the following warning when the user tries to send a snailmail
letter for the first time (from an invoice or from a follow-up report):
'You are about to send this invoice/follow-up report by post. Are you
sure you want to continue?' Confirm/Cancel
closesodoo/odoo#47861
Taskid: 2215091
Related: odoo/enterprise#9326
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@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>
Pingen is a service that print (like really, using a printer) pdfs
document in order to mail them (using the real post and postmen). In
order to ensure we are compatible with their API, we send to their
sandbox environment a bunch of standard documents (like an invoice).
Those PDFs documents are generated our side using wkhtmltopdf but as the
test were not started using a HttpCase, the assets were not correctly
available.
This also reverts commit 3f5a0a1ef4.
closesodoo/odoo#40323
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Somehow, the fact that this test has been converted (partially)
to a SavepointCase makes the assets to be rollbacked after generation.
Notify the registry to be in "test" mode, where one cursor serves several
requests, solves the issue (no 404 when getting the assets, and no
registry reloading).
closesodoo/odoo#40243
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
* Ensure compute always sets partner_id.
* Don't show "to" when partner_id is not set
closesodoo/odoo#38334
X-original-commit: 7e122140b13fce5cf466376fe9fcb631e4b6bd75
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Gorash