Maintain the playful tone whilst avoiding nonsensical phrasing.
I will not take comment at this time, thank you.
Task-🤔🙃😬💅😐🤓closesodoo/odoo#138302
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Before this commit error messages in odoo are boring and
not much attractive to user. Those were like odoo is preventing
them from doing something user want to do.
In this commit, we have modified the message to be a more friendly
and humorous tone, making it less tedious and more enjoyable. It
aims to enhance the user experience and ensure that interactions
with any application are both pleasant and informative. As a result,
the messages have been clear, short, easy to understand and informative.
task-3356114
Part-of: odoo/odoo#124820
Co-authored-by: Kamlesh Pathekar <kpt@odoo.com>
With this [commit](https://github.com/odoo/odoo/commit/adb8ec875c9b4e299147c46dc60a87fd26fff91f), we created a new 'Analytic Reporting' menuitem.
But no `search_view_id` was specified, so it was falling back on the one from `hr_timesheet` (when installed), which we don't want.
This commit fixes that by forcing the use of the one defined in `analytic`.
task-3463639
closesodoo/odoo#138165
X-original-commit: ed60f37205acf85c05338b0cd00f4e2f5056de60
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
The aim of this commit is to allow having several taxes with the same
name if those taxes are from different countries.
Context:
With the new taxonomy, it was much more likely for 2 taxes to have the
same name and that was the case for several taxes.
Before this commit:
It was impossible to instantiate some foreign tax because of the unicity
on tax name constrains.
After this commit:
- Foreign tax with same name than national tax can be created again
- UX is improved by appending the country code to the tax name for
display purpose.
closesodoo/odoo#137921
Task-id: None
X-original-commit: 502ec287590b95fdae581cc048ca25eb6699e16d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
1. Add the "Download" option back into the Send & Print in list view
2. If the "Download" option is ticked, the Send & Print is run synchronously.
3. "Download" returns a zip containing all documents that are generated (or previously generated)
4. Remove completely "Download Electronic Invoice"
5. When downloading a single invoice that has multiple attachments (pdf, xml, ...)
we now download a zip with all files instead of only the pdf.
Task-id: 3525932
Part-of: odoo/odoo#137382
Adds demo data for auto-reconcile.
We now have data that can auto reconcile:
- in both modes (zero total balance or opposite
balance one-by-one)
- on payable and receivable accounts
- by filtering on Azure Interior and/or Deco Addict
task-id:3517768
closesodoo/odoo#136252
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Name can be edited more frequently than VAT, and we should
have a dedicated method to check whether it can be edited
or not.
closesodoo/odoo#118428
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Switch to a datetime to avoid a wizard that has been created
at 00:00 to be deleted one minute later.
closesodoo/odoo#137697
X-original-commit: 128e3da4807acbc2275c7e4db3833ce062afae24
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Adds a new boolean field on accounting report to enable the user to select user-defined filter on accounting reports. If activated, the user can visualize its own favorite filter (defined on journal items list view) on a new option selector on top of accounting reports (see enterprise commit). When selected, the domain of the user-defined filter is added to other selected options' domain.
task-3444246
closesodoo/odoo#134966
Related: odoo/enterprise#47200
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
This field is needed by the enterprise counterpart of this commit. It is used to store custom-defined groupby on the report lines without overriding the standard value that's given in data files.
Task 3413437
closesodoo/odoo#133830
Related: odoo/enterprise#46657
Signed-off-by: John Laterre (jol) <jol@odoo.com>
PURPOSE
Simplify 'mail.tracking.value' model and code. Remove unnecessary fields and
computation. Make code easier to handle and more batch-enabled.
SPECIFICATIONS
Rename 'field' to 'field_id' on tracking model. It better indicates it is a
many2one and not a char field holding a field name for example.
Task-3345979 (Mail: Simplify tracking model)
Part-of: odoo/odoo#124182
The corresponding enterprise PR enables sorting account move lines on the bank recon by matching amount.
Unfortunately there is a significant performance impact when enabling this ORDER BY (~300 ms -> ~2600 ms tested on a large db)
In order to optimise the above, we slightly modify the domains used so that the existing index `account_move_line__unreconciled_index` is used.
This is not yet tested on a large DB (due to the index change), however observations on a populated database indicate an improvement:
without index: 80ms
with index: 30ms
closesodoo/odoo#135155
Related: odoo/enterprise#45816
Related: odoo/upgrade#5146
Signed-off-by: Laurent Smet (las) <las@odoo.com>
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>
Damien Bouvy