Before this commit, owl was in the linter's accepted global variables.
This allowed direct access to owl global object.
For instance, to use xml from owl, you could do :
`const { xml } = owl;`
or you could use it directly:
`owl.xml`
Now, owl is not accepted on linter's global variables anymore, so to
import xml, now you need to use a proper import:
`import { xml } from "@odoo/owl";`
task-id 3498859
closesodoo/odoo#137517
Related: odoo/enterprise#48364
Related: odoo/design-themes#709
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Small issue in 7032917771. account_avatax supports the US and
Canada. l10n_br_avatax supports Brazil.
closesodoo/odoo#136893
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When sending a single invoice, if an error was raised in the middle of the
process we wrongly displayed the banner "This invoice is being sent
in the background".
task-id:3515915
closesodoo/odoo#137571
X-original-commit: 844f9b672b91c50affd783253b2b8ee4b816cef7
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
[Genesis]
while forward-porting tests for an issue (not present in the master
anymore), found changes causing the following error:
ValueError: not enough values to unpack (expected 4, got 3)
in line:
kind, rhs_table, condition, condition_params = query._joins['account_move_line__account_id']
Follow orginal PR (#135884) to learn more.
[Problem]
To reproduce:
- run odoo master with module: account_accountant
- go to: invoicing app -> Vendors -> Bills -> New
- pick a vendor -> add a line -> click on dropdown in the Account column
- upload and observe an ERROR
[Solution]
- Since query._join will always return 3-element tuple, I'm removing additional variable "condition_params"
- query._joins can't be filled with Strings, it needs SQL instances; replacing strings with odoo.tools.sql.SQL objects
- forwarding tests checking for deprecated accounts
[Testing]
Created test in test_account_account:
It runs function with modified sql query twice:
- with certain account not deprecated -> extected that this account appears in the results
- with the same account deprecated -> extected that this account won't appears in the results
opw-3485768
closesodoo/odoo#137110
X-original-commit: da9583be8c1fb3cd4d4dfcf6932d4e8debcc0b42
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Add the `@` on the compute decorator of
`_compute_days_sales_outstanding`, it was probably due to a typo.
closesodoo/odoo#137425
X-original-commit: cb9bdd717f1ceacaecc29eaf8e7a1898405f2c1d
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
We align how the date is computed on exchange differences on
how it already works when unreconciling. See _get_accounting_date().
closesodoo/odoo#136911
Task-id: 3516687
Related: odoo/enterprise#48058
Signed-off-by: Laurent Smet (las) <las@odoo.com>
improve the flow of invoicing tour by:
- moving some bubble to a more clear position
- rewrite some text content
- delete some and add new tour step
closesodoo/odoo#132382
Task-id: 3468585
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
1. Accounting > Invoices > click any unpaid invoice
2. Register Payment (doesn't matter if it's full or not)
3. Click the info (i) button next to the "Paid on" below invoice lines
-> Traceback
Before the traceback the unreconciliation button available was not
refreshing the view, which still appeared with "Paid on".
We fix both problems at the same time.
task-id:3516681
closesodoo/odoo#136383
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Before this PR, the trade partner filter was using a boolean instead of a
selection field. This PR will change the type of the field to a selection.
closesodoo/odoo#135129
Task-id: 3499156
Related: odoo/enterprise#47288
Related: odoo/upgrade#5135
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Since https://github.com/odoo/odoo/pull/110737, it is better to use
`_read_group` instead of `read_group` in the backend. In fact, the
public method is less efficient (it computes display_name of relational
groupby, extra order, ...) and more verbose.
This commit replaces these new uses of `read_group` with `_read_group`.
closesodoo/odoo#136381
Related: odoo/enterprise#47826
Signed-off-by: Raphael Collet <rco@odoo.com>
Before:
When a new product was created in a multi-company setting, if the company field is empty, the product is available for all companies. The default sale and purchase tax of the company was set on the product. The problem is that only the default taxes of the currently active company was set on the product, so viewing the product in other companies showed an empty field for the tax.
Now:
- When creating a new product with the company field empty, the default taxes of the other companies are set on the product as well.
- Tax display_name now shows company name if in a multi-company environment and more than one company is selected to make it easier to know which tax belongs to which company.
task-3375286
closesodoo/odoo#127196
Related: odoo/enterprise#45075
Signed-off-by: William André (wan) <wan@odoo.com>
In enterprise, when doing a comparison between multiple periods with values carried over to them, auditing the carryover values (through the dedicated button in the popup, in debug mode) always opened the latest period.
This was due to the fact the main options of the report were directly used, instead of the ones corresponding to the column group owning the value.
closesodoo/odoo#136868
X-original-commit: e80680e47218f2109c0ba599d4a1f41651f65c62
Related: odoo/enterprise#48030
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Create an expense sheet (report)
Add 2+ expenses with 10% included tax to the same employee
Approve expenses and post journal entries
Bill will be created
Go to the tax report
Group by "Tax > Account" or "Account > Tax"
Issue: Bill line will have the tax basis calculated incorrectly
This occurs because the bill will have 2 separate tax line and the query
does not handle this case
opw-3510371
closesodoo/odoo#136694
X-original-commit: 2ed464bc6bf4fa35e1ad2704ed9db71789c39257
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Auto install AvaTax module for countries that use AvaTax ('US','BR').
Add a checkbox in settings to easily install the module if needed
task ID: 3398637
closesodoo/odoo#136490
Related: odoo/enterprise#47979
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Ease the way invoice report is selected for rendering.
We now only rely on `_get_name_invoice_report()` to decide
the report, and it is automatically selected in the report template
`report_invoice` that is extended by localizations.
Task-id:3492033
closesodoo/odoo#136389
Related: odoo/enterprise#47812
Signed-off-by: Laurent Smet (las) <las@odoo.com>
The 'like'/'ilike' operators automatically add the wildcard character
(`%`) at the beginning and at the end of the value. This commit fixes
the incorrect usage.
closesodoo/odoo#136007
Related: odoo/enterprise#47886
Signed-off-by: Raphael Collet <rco@odoo.com>
On Database having a postgresql server version superior or
equals than 14.0, a feature called memoization is caching
result of the lateral join made in this query.
This cache creates an issue that results that customers
have the same result for their bank journals.
By adding a LIMIT 1 at the end of the lateral join query,
the memoization is not enabled (according to query plan).
Another solution could be to change the condition of this
lateral join (currently ON True) for a condition on the
journal id but it was less efficient.
opw-3422495
closesodoo/odoo#136498
X-original-commit: 0ccdd9344e2192049aa196f419abac7eb59e4f1a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This is just a typo XD
closesodoo/odoo#136536
X-original-commit: 7c5fcf4c631cfcb80786566acae7ca4484fcf048
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the payment providers (e.g., Stripe, Adyen...)
available for payment were displayed on the payment forms. The customer
had to select one to process their payment. After that, the customer had
to select their preferred payment method (e.g., Credit Card,
Bancontact...) from a list of payment methods supported by the selected
provider over which the website administrator had close to no control.
This was making the payment forms confusing because the payment methods
were displayed sometimes more than once, if at all, in a non-controlled
order, and behind the selection of a payment provider that customers
should not have to deal with.
As the payment method was selected in an iframe or directly on the
provider's website, the information on the selection payment method was
not available in Odoo. This posed many problems, among which were the
impossibility of assessing whether a specific feature (e.g.,
tokenization, refunds, manual capture...) was available, not being able
to easily identify payment tokens through the payment method logo,
listing available payment methods on the website, sorting and
fine-grained configuration of the available payment method, subpar
payment method-specific display on the payment form (e.g., PayPal that
requires displaying a "Pay with PayPal" button), etc.
In this commit, the payment providers are thus replaced by the payment
methods on the payment forms. All contextually available (depending on
the country, currency, requested feature...) payment methods are
displayed one after the other on a single-level list and in the order
configured by the website administrator. Each payment method is
"powered by" (i.e., linked) to a single payment provider: the first one,
by model order, to support it. This allows, for example, offering the
PayPal payment method through Mollie, which charges low processing fees,
while also offering Klarna through Stripe, which supports more payment
methods but charges higher processing fees.
While doing so, the two different payment forms, "Checkout" and
"Manage", are also merged together in a new, configurable case-by-case,
payment form that is entirely redesigned to offer a better user
experience.
After payment, the information on the selected payment method is saved
on the transaction and eventual payment record and updated with the
information received from the provider.
task-2882677
closesodoo/odoo#120446
Related: odoo/upgrade#5103
Related: odoo/documentation#5717
Related: odoo/enterprise#40666
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Co-authored-by: Anita (anko) <anko@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
Co-authored-by: Valeriya (vchu) <vchu@odoo.com>
Since the new model (PR: odoo/odoo#114024), updating a record no longer
triggers a deep render and therefore no longer triggers the onWillUpdateProps
for Field components.
The goal of this commit is to adapt the usage of onWillUpdateProps
in Field composents in order to fix the bugs introduced by the RelationalModel
closesodoo/odoo#135842
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit excludes off-balance accounts from appearing in tax
repartition lines.
Previously, off-balance accounts were included in the selection, which
was causing confusion and unnecessary clutter in the interface.
The need for this change was raised due to the observation
that off-balance accounts are never actually used in tax repartition
scenarios.
Including them only complicates the account selection process without
adding any functional value
closesodoo/odoo#136196
X-original-commit: 77871dd434a912fab41e6cec674c272fe37bcf1d
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
=== ISSUE ===
With Milk, our primary buttons received a fresh lifting in term
of design,with different designs according the state the button is in.
Before that, our buttons were green with a white text on it,
and the behavior was identical on `hover`. This allowed us to force
a `color: white` when it was needed, since the background always matched
WCAG contrast standards.
Since the 16.3, these buttons are on a dark background,
and that background becomes light when in `active` state. That means we
cannot use white on these buttons.
=== AFTER ===
We set the color of the link inside the button to `inherit` in order to
fix the active state behaviour.
Note that this should be improved when reworking the widget since having
a link inside a button is not really expected. Instead we should use a
link that allows different actions.
task-3354844
part of task-3326263
closesodoo/odoo#135996
X-original-commit: 572288ccf2244df23c031dd88c47d2807fd06c47
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
In this viewtiverse, the heroes remove the context dependencies for
`get_views`, from the views and python fields (such as domain). To reduce
inconsistencies and the number of rpc.
Current issues:
* There may be inconsistencies in views at the JavaScript level. Some
overrides modify the behavior of get_views or domains on fields via
context keys, therefore by changing the action, the rendering may be
different. However, these views are cached. However, the cache key
(Javascript) does not reflect the entire context, and requires additional
post-processing from the server.
* Multiple rpc for the same rendering. get_views being dependent on the
context, as soon as it changes, a new rpc is performed. In most cases,
when JavaScript needs the same view, there is no change depending on the
context, the rpc is useless.
* Inconsistency when rendering subviews, some views could be different
depending on the context, this context can be modified in the view itself
via the context attributes. However, the JavaScript client does not redo
an rpc for each change of these sub-contexts. Therefore the result may be
inconsistent.
Solution:
Limit as much as possible the number of context keys provided when calling
get_views, and use the context provided as a cache key. The authorized
keys are 'lang' and '*_view_ref'. For the cache key, options are added in
the get_views method.
Instead of using the context, it is inserted into python expressions.
This will be evaluated by JavaScript and thus avoids inconsistencies.
task-3414108
task-3414068
closesodoo/odoo#135145
Related: odoo/enterprise#47584
Signed-off-by: Raphael Collet <rco@odoo.com>
All account.tax weren't delete when we reload the chart template.
It was caused by the fact that we forgot to add the active_test=False
in the context to delete all the taxes (and not only the actives).
This thing caused an issue where an sql constrains was trigger.
This fix comes from another PR (https://github.com/odoo/odoo/pull/132360)
that doesn't solve properly the issue.
closesodoo/odoo#136081
X-original-commit: a92f347318415492357413c577e666785c2cb8a4
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
The stupid aim of this commit is to remove one line.
The smarter goal of this commit is to add a "/" for the root node and
improve the code readability.
Context:
I made an initial modification to this function and created an `AccountTools`
class. Then Laurent was bothered and changed some stuff thus the initial
commit isn't required anymore.
As he isn't bothered anymore and has too much peace of mind at the moment, I
have the responsability to entertain him to keep his brain at its full
capacity for the sake of Odoo's future.
Before the commit:
The code is complicated and LAS is in peace.
After the commit:
The code is sexier and Laurent keeps his brain sharped and entertained.
Task-id: 3326977
Part-of: odoo/odoo#136072
Add a selection field `l10n_mx_tax_type` on account.tax. This field is
used in the CFDI attachment. This allows to avoid relying on the name of
the repartition line tags to export and import a CFDI.
task-3388347
closesodoo/odoo#135215
Related: odoo/enterprise#47321
Related: odoo/upgrade#5136
Signed-off-by: Laurent Smet (las) <las@odoo.com>
The account_edi framework is no more a dependancy.
- Models account.edi.document and account.edi.format have been removed.
All the functions have been moved to the new account.move.send,
account.move, account.edi.proxy.client.user
- The move now holds the l10n_it_edi_state which admits all values that the SdI sends us as a status update
- The sending is now not handled by the cron but by the Send and Print dialog.
- Vendor bills Tax Integration sending by dedicated button
- The move form will now hold the state of the EDI transaction, its number and the EDI attachment as a Binary field on the move itself.
- A new banner will keep the latest message from the SdI, that's not the account_edi old banner.
- All the user messages have been simplified.
IAP-apps PR: odoo/iap-apps#652
Upgrade PR: odoo/upgrade#4893
Task link: https://www.odoo.com/web#id=3339971&cids=1&model=project.task
Task-3339971
Part-of: odoo/odoo#122194
- Proxy user is no longer a computed store=True field, but a proper one.
The type cannot be deduced just by some field on the company.
A company may be Italian and also use Peppol, so the two Proxy Users
must be different.
- The Proxy user `get_proxy_identification` method needs a proxy_type
argument, otherwise the method won't know if the current override
is to be applied or not. It cannot be handled by a field of the user
itself because it is also used contextually to the user creation.
- new `_get_default_enable_send_by_post` function on the Send and Print
wizard, so that it can be overridden by the features of the move
- Renamed `_compute_send_mail_extra_fields`
to `_compute_fields_from_moves_state`
Part-of: odoo/odoo#122194
Steps to reproduce:
* create an invoice with a line
* change the receivable account
* duplicate the invoice
Result: the receivable account is recomputed to the default one.
Expected: we should keep it.
task-3504443
closesodoo/odoo#135723
X-original-commit: 1043d2b790a625590ca21f8e0d6560ceba3d6a84
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Implemented support for the BACS payment scheme as per the latest
technical specifications, enabling the processing of BACS Direct Credits
and Direct Debits. Included the mandatory requirement of a Service User
Number (SUN) for businesses conducting transactions via BACS.
closesodoo/odoo#135696
Task-id: 3326945
X-original-commit: 2e6aeffd7ae9116d3445aa53265919cc29afafc7
Related: odoo/enterprise#47487
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Mohamed Erradi (moer) <moer@odoo.com>
- Added ondelete='cascade' to account_payment_method_line's
field definition.
- Fixes the foreign key constraint failure during module uninstallation
by automatically deleting dependent records.
task-3326945
X-original-commit: 9c10cf4dc1da36a2ef826962887a6538d0c522a2
Part-of: odoo/odoo#135696
Only duplicate emails used to be checked when sending a mass mail.
However it is possible (e.g. using templates) to send a mass mail
to the same person containing different information.
The existing functions to allow models to specify emails
processed in the past by some other means are kept.
A new check is added in the processing that checks the full contents
of the message, subject and attachment ids.
The strings are not hashed as most situations are:
- Sending the exact same mail to everyone
-> Only need to check against one message
-> Same complexity as hashing
- Sending all different emails
-> Checking inequality of str is usually very fast
For attachments, as we cannot compare them easily.
They are ignored for the purpose of equating emails
whenever there are the same number of attachments
in the email values as there are on the composer.
This is because each email should receive its own copy
of the composer attachments. If they have a different
number of attachments, they were generated dynamically
through reports and we assume they are all different.
We can thus remove the 'document based' information
as it is implicitly infered from this check.
-------------------------
Test utils are also updated for two purposes:
1. Add optional body and attachment_name discriminents
assertMailMail assumed all emails could at least be
differentiated by subject. Our test breaks that
assumption, so we use body and attachment to find the
best-fitting email based on the data passed in.
2. Check email_formatted on recipients
When using assertMailMailWEmails, we first find the
email using the non-formatted email of the recipient.
This does not match assertSentMail which checks against
the raw email_to value, which would often be formatted.
Task-2826811
closesodoo/odoo#99541
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When trying to customize Swiss invoice report with QR-Bill
through Studio an error was thrown because it tries to _compute_name()
on a dummy 'account.move' record with self.id=0.
This is part of a more general task in master around report customization
but it make sense to backport the fix in all stable versions.
task-id:3492033
closesodoo/odoo#135722
X-original-commit: d95aae51a23ff163e959a1f3064f42a89cfaf516
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Currently the tax report always opens the previous month by default.
Since tax periods are not always months, it makes much more sense to
open the previous "tax period" (whatever length it has) when opening the
tax report.
In order to allow that, this commit introduces a "This Tax Period" and
"Previous Tax Period" option for reports and sets the default period
for the tax report to "Previous Tax Period". The rest of the
functionality is done in the related enterprise commit.
task-3481913
closesodoo/odoo#133715
Related: odoo/enterprise#46601
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Before this commit, the fiscal position is not used to determine account.
closesodoo/odoo#135559
X-original-commit: 57f71fa2666af591a8d3d28af65fcfab8a7d3785
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Co-authored-by: Miquel Raïch <miquel.raich@forgeflow.com>
Example: Copy the Belgian P&L, try to open the copied report => error message saying some aggregation terms cannot be expanded. If you open the its form view, you can see that line BE_PL_14's balance formula has been translated from this
BE_9906.balance + BE_791.balance - BE_691_2.balance + BE_794.balance - BE_694_6.balance
to this on the copy:
BE_9906_COPY.balance + BE_791_COPY.balance - BE_691_2_COPY.balance + BE_794.balance - BE_694_6.balance
This is buggy ; BE_794.balance and BE_694_6.balance should be BE_794_COPY.balance - BE_694_6_COPY.balance, in order for them to match the other lines of the copied report properly.
This bug touches other reports more generally. It was due to the fact we replaced the codes in aggregations while we were copying the lines, and not after copying all the lines. Because of that, lines that were referrenced by an aggregation expression belonging to a line coming before them in sequence were not taken into account, as they were not part of the code_mapping dict yet.
OPW-3505592
closesodoo/odoo#135585
X-original-commit: 43ed3e69291833ca82cd1257ade021862997828c
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Problem
---------
User want to search on journal items based on the amount. This is doable
through custom searches but that is not user-firendly.
Objective
---------
Add a search based on the amount of an journal item (in credit or in
debit) to make it more user-friendly.
*Secondary objective*: Add a similar search for journal entry amounts.
Solution
---------
Declare a computed field for journal entries that the search will be
based on and add this field in the search view of the journal items.
*Secondary solution*: Add amount_total in the search view of the journal
entries.
task-3439520
closesodoo/odoo#129990
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In case of the user have no access to all account.payment, the record can be deleted.
closesodoo/odoo#135415
X-original-commit: 5086b39e44230a14a6c1c65bde4851f062f10e38
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
* = account, base_iban, bus, calendar, crm_livechat, hr, hr_holidays,
im_livechat, mrp, project, sms, snailmail, test_mail,
test_mail_full, web, website_livechat, website_slides
Add support in `contains` for most operations that we use in tests.
Remove return value from `contains`.
Move into `web` module.
Remove import/export chains, directly import from correct module.
closesodoo/odoo#134652
Related: odoo/enterprise#47064
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When creating a new report and assigning a root report, the filter fields are recomputed to take the same values as the root report by default. This is done to avoid silly mistakes from the user ; for example, when configuring a tax report, forgetting to set the only_tax_exigible field.
However, nothing similar was done with the sections, and that was very error-prone. Indeed, when a report is created as a section of some other report, and not to be used in any other case, it would be convenient that the report's maker (be it a a developer or a UI user) does not have to care about all the nitty-gritty details of the default values assigned to filters. Taking the same example, what was there before this commit makes it so we could very easily face the situation where a tax report is made with multiple sections for its different annexes, and one of them is missing a True value in the only_tax_exigible field (spoiler: this mistake happened on some development branch of ours).
To solve that, when we see a report only belongs to one single composite report, and if it's not callable alone (for this, we check the existent of an action opening it directly, or the presence of a root report fot it), then we compute a default value for the filter fields, using the composite report as source.
closesodoo/odoo#135259
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Steps to reproduce:
- Create an invoice
- Select a partner
- Add an invoice line (without a product): a default account will be computed
- Change the account
- Add a second invoice line (with a product)
- Change the account
- Select another partner
The account for the invoice line without a product will be recomputed, while
the account for the invoice line with a product will not.
The computation of the account should happen when the line is added.
If the account has been changed, it should not be recomputed to a default one
when changing the partner.
The behavior for aml without product should be the same than aml with a product.
opw-3474469
closesodoo/odoo#135411
X-original-commit: 2d5b4998e2b1c9111e7997b6174abf41dc2af02d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
If a bank account is added through the onboarding step and the user creates one instead of linking it,
the dashboard is not reloaded to show the completion of the step and the new account.
To make sure that the view is reloaded to show new data,
the easiest fix would be to return a reload action in `validate`.
task-3431961
closesodoo/odoo#135170
X-original-commit: cc793b303da5ea2dbe931bac1da266a121429ede
Related: odoo/enterprise#47302
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
In 16.1 and before, when you used the Send & Print, you could manually remove the attachments when using
the Send by Email. Even though the use case is weird (sending an invoice by email without attaching the document),
we have feedback of user actively using that option before.
Also, prevent the deletion of the PDF report from the wizard:
- Create and invoice and send it by mail
- Open again the send & print, remove the PDF and send by mail
=> The PDF is deleted from the invoice
closesodoo/odoo#135101
Task: 3476700
Opw: 3378840
X-original-commit: 00dc68955c8e4c35fab29617eed7f03e45fc6643
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
When trying to drop an invoice on a journal on the journal dashboard,
it fails with a message "Could not upload files". The issue is that
commit 6f95be6884 changed a CSS class
where the upload functionality depended on, making it fail.
This commit fixes this issue by adapting the CSS selector of the upload
field.
task-3496997
closesodoo/odoo#134965
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Before: when attempting to print an invoice, the downloaded file had the generic name "Invoice".
Now: downloaded files have the correct invoice number as names.
task-3477659
closesodoo/odoo#135093
X-original-commit: 6b3555d93221ef6db9e3265a95b127a2bb743469
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Ali Alfie (alal) <alal@odoo.com>
The aim of this commit is to prevent reconciliation with credit note to be triggered when a reversed move is reset to draft
Context: reconciliation between credit note and invoice (same for vendor bill)
Previous to this commit:
Post invoice
Create and post credit note
Reset to draft both the invoice and the credit note
Post (confirm) again the credit note
-> User error due to attempt of reconciliation between credit note and draft invoice
After this commit:
The credit note is posted but not reconcilied
task-3492197
closesodoo/odoo#134526
X-original-commit: b61395337ca139b6a663628c70c52f8cce87d76f
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Jorge Pinna Puissant