PURPOSE
This commit is a first polish for event booth modules. It includes:
- wording
- add currency on price fields
- removing booths tab on event view
LINKS
Task-2635461
PR: odoo/odoo#77081
PURPOSE
Before this commit when confirming a registration on the frontend the form
was directly sent to the controller and the user was redirected on the
success page if no errors.
After this commit an ajax call is made after validating the form and the
success page is directly loaded from the response... there is no redirect
anymore.
This way of displaying the success page prevent using the link generated
before by another user and getting private information about the booth's
renter.
Two more advantages are that it's easier to maintain and it's slightly
faster than before since the whole page isn't reloaded.
LINKS
Task-2635461
PR : odoo/odoo#77081
Step to follow:
- Create an Asset Models
- Set up the Fixed Asset Account:
Automate Asset -> Create in draft or Create and validate
Asset Model -> The one you have just created
- Create a Vendor bill
Account -> the Fixed Asset Account of the asset model created
Label -> insert a newline
Price -> (do not forget to set a price)
- Validate
- Go to the asset automatically created
- @ mention a user in the chatter
Cause of the issue:
The generated email subject comes from the record_name and it can
contain newlines
Email headers don't allow newlines and an exception is thrown here
https://github.com/python/cpython/blob/60b93d9e4922eeae25052bc15909d1f4152babde/Lib/email/policy.py#L143
Solution
Replace newlines by spaces in the email subject
opw-2522055
closesodoo/odoo#77712
X-original-commit: ed343998d39ff91a3f73cc8012be498d32c91b2f
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Create 3 websites and set a website domain for each
- Install the website_links module
- Go to Website > Configuration > Settings
- Select the website 3
- Go to website
- Menu Promote > Link tracking
The URL field uses the domain you are logged into the database
rather than the domain of the active website
The expected behavior is:
With an ICP set to URL1, a website 1 set to URL2 and a website 2 set to
URL3, going to the link tracker website page from URL3 but with website
1 selected should:
Show the current website domain as placeholder of the input -> URL2
Create link for that current website the user selected -> URL2
opw-2638494
closesodoo/odoo#77705
X-original-commit: d094d76354d6f46db3dc7f8e716b5f778ca26569
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The img nodes where being wrongly considered empty by isShrunkNode
because the image was not loaded yet.
closesodoo/odoo#77646
X-original-commit: d18d51191bca8f063effd4a216c3963c187a8767
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The exists method (of BaseModel) doesn't work with model
without SQL table but with a table query (see
f2ceef0e2f)
This method is call when we try to read a forbidden
record (`forbidden = missing.exists()` in `_read`)
- Fix it by using a Query object (which able the case).
- Also use a partition method instead of duplicate it in the method.
- Fix the CRM Lead Report which can return a Falsy id
task-2633558
closesodoo/odoo#77644
X-original-commit: 70a68615c722e7145b2ba8bb7ca86a8373b5aa4e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- If we try to delete an answer which is already been selected by attendees,
it throws a validation error saying "There must be suggested value or
text value". The constraint here does important check, which makes sure that
the answer must have a valid value (either selection or text) otherwise the
answer record is of no use, and keeping such records doesn't make sense.
Thus it prevents corrupting the historic responses. For example, if attendees
answered a selection question with particular option and we try to delete the
same option from event question, the constraint will not let us delete that,
because the answers with this option selected will be of no use.
However, the current validation error message does not make it clear to the
user trying to delete the selection options which are present in the answers.
- The same goes for event questions. If we try to delete a question which is
already been answered by attendees, it throws a raw sql error message to
prevent corrupting the historic responses.
With this commit, we simply improve the validation error messages for both the
above cases. While deleting the answer selection, we now raise a UserError from
`_unlink_except_selected_answer` method saying "You cannot delete an answer
that has already been selected by attendees." And while deleting the question
itself, we now raise a UserError from `_unlink_except_answered_question` method
saying "You cannot delete a question that has already been answered by attendees."
TaskID-2635599
closesodoo/odoo#76265
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
These encode/decode shenanigans seem to be unnecessary since we are not
using summernote anymore. Moreover, the encode process was destroying
the html structure of nodes contained in the link, only making a special
case to maintain images. This is not sufficient anymore because the
Cards option of website mega menu does make use of custom html content
inside a link. This content was therefore destroyed on edition and
replaced by its textContent because of the encode function.
task-2652361
closesodoo/odoo#77654
X-original-commit: 80004b1819fa1e1e7cfdd03a285de9d4ee845356
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "Claim Car Report" action was not working as expected.
Now the statbutton "Cars" will show the car history of a specific
driver.
closesodoo/odoo#76550
Related: odoo/upgrade#2882
Taskid: 2646113
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When the crm.lead is of type 'lead', we don't want to display the
"Customer" field on the form view unless it's set (or debug mode).
Indeed, most of the times leads will not have this information set,
since when we assign a Customer we usually convert the lead to
an opportunity as well.
This means that on the lead form, we don't want to display this field
since it may be misleading for the end user.
When it's set however, we want to display it, mainly because there are
a few automatic synchronizations between the lead and its partner
(phone and email for examples), and this needs to be clear that modifying
one of those fields will in turn modify the linked partner.
Task-2596955
closesodoo/odoo#76233
Signed-off-by: awa-odoo <awa-odoo@users.noreply.github.com>
Having the same VAT fiscal position for the same region multiple times doesn't make sense and is not supported by the report enfinge. We should prevent that.
closesodoo/odoo#77663
X-original-commit: d9dfeeb498dab359df52db87ff601d68fcf0ad7c
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The 'Country Group' field should be displayed under the 'foreign VAT' one, so that it its grouped together with 'Country' and 'Federal states'.
X-original-commit: 302586c6b35825e19945b92faa48ccc892179ea6
Part-of: odoo/odoo#77663
* = test_discuss_full
Before this commit if 2 persons are joining the call at the exact same time, the
join RPC of each will return the list of RTC sessions without the other person
included.
In more general terms, the server should actually rarely send the full state to
the JS (in this case "use the replace command") because there is no guarantee
that a concurrent transaction is not changing the data at the same time. In
other words, even the python is actually working with partial knowledge
relatively to the database.
Using a DB lock would guarantee it, but we don't want to lock tables and wait on
locks if there are alternatives. In this case it is acceptable to keep obsolete
sessions for a little bit longer, as long as they are cleared eventually.
closesodoo/odoo#77656
X-original-commit: d3a84172fc78f5783f75aa1155f1a25e4f9614b7
Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
It could take seconds to annotate a simple stack trace, it is therefore not
suited at all for quick logging as we do in RTC.
It's unfortunate but acceptable to just log the non-annotated stack trace in
that case.
X-original-commit: 8b3495c489c274e878d2a0938ea29b4da17710aa
Part-of: odoo/odoo#77656
This commit adds a test in order to strengthen the behaviour of
recurring subtasks.
This test asserts that child with depth > 3 are not copied in a
recurrence, that recurrent subtask are well copied with the recurrence
correctly set.
This commit prepares the recurrence refactoring.
task-2660756
closesodoo/odoo#77632
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Issue: With margin enabled and avco for stock valuation, after
confirming a SO with a product variant which is a bom kit,
when we try to change the variant, there is a traceback
Steps to reproduce :
1) Install Stock, Accounting, MRP, Sale,
2) Enable Margins in settings
3) Configure a Product Category with costing method AVCO
4) Configure a Product with 2 variants and that product category
5) [Important: KIT] Create 2 BoM, one for each variant and set those
BoM to KIT
6) Create a SO for that product and one variant
7) Confirm the SO, cancel it, and set to quotation
8) Edit the SO and change the variant, save
-> Traceback
Side-Note:
This issue is due to the fact that we iterate over the stock_moves to
find the quantity of the BoM, but that stock_move correspond to
confirming at step 7, when we change the variant at step 8, the stock
move has not changed, so still contains the previous bom_line_id with
the quantity, but this doesn't reflect with the new state of the SO
which is for a different variant.
For me since the stock move is canceled, it should be taken into
consideration when computing the average price but I might be wrong,
it's up to the reviewer to decide if it makes sense
opw-2639093
closesodoo/odoo#77606
X-original-commit: c0d4ed5ac641d339a6cd4e23db9667048d35360d
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When invoicing via POS delivery address is missing on the invoice.
This value is needed in some localizations (i.e. l10n_co) to correctly
validate the invoice
opw-2653661
closesodoo/odoo#77556
X-original-commit: d57a44d875eabba0586e24245a9af435169fda22
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Create a promotional program P with 'Fixed amount' discount of $50 and 'Automatically applied' on current order
- Create SO and cancel it
Bug:
P was applied on the canceled SO
opw:2579344
closesodoo/odoo#77455
X-original-commit: 8f11cabcb605cab5c83e4889156e4979d55aa517
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Previously, the land page of Time Off was month view. When you select a leave from Month's view, you can edit/delete it directly.
Now, the land page is Year's view, and you can open the modal form of the leave, but it's not possible to delete it.
Add a delete button on the form view of the leave from the year's view of the dashboard
task-2638305
closesodoo/odoo#76080
Signed-off-by: Kevin Baptiste <kba@odoo.com>
No menu allowed viewing all tax groups at once before. With the new subtotals features, it could become painful for the user if he wanted to change the groups' sequence in order reorder subtotals on his invoices (he had to change the sequence manually on each group, accessing their form view through taxes using them). It is now possible in the tree view opened by our new menu, with the sequence widget.
X-original-commit: 708899fc0e1a793f29884d82b34ba6c492461737
Part-of: odoo/odoo#77662
"Rounded" and "Flat" buttons didn't have their proper styling
if the website module was not installed.
Styles for rounded and flat buttons have been added to theme_default.scss
closesodoo/odoo#77661
X-original-commit: 74540364428e9d5a308a1012ae8614aa37ecb8a6
Signed-off-by: Antoine Guenet <Zinston@users.noreply.github.com>
Let us assume we have a slow network and a (new) search bar with two
items, one of them expandable.
Before this commit, click to expand that item and then hover the other
item quickly would not end in a situation where the item is expanded.
This was due to a naive concurrency management in the (new) SearchBar
component.
In this commit, we allow to focus another item (via the mouse or the
keyboard) without cancelling an ongoing asynchronous operation.
closesodoo/odoo#77655
X-original-commit: 6fc0c5ee2d1d68bf82a034fe1744ac5673e522c9
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Since commit a1f286916d o_cp_action_menus is not centered
anymore as justify-content: space-between; was removed from scss.
with this commit we are making o_cp_action_menus centered again.
task-2628050
X-original-commit: 590d0ca81382d4c3d6007bdf9bf65ed3a0ed795e
Part-of: odoo/odoo#77649
Facturx expects line price to be subtotal, not unit price. Odoo parser
is also dividing the gross price by quantity. So before this commit,
importing PDF invoice rendered by Odoo, results in: unit price / quantity.
The bug was introduced in odoo/odoo#53894closesodoo/odoo#77527
X-original-commit: 3769a6cdda259a839f00267d99a57f2aa3d89aa1
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Given that we have a viewport of 320px and, to simplify the explanation,
we discard the height of the <header> (aka. the top navbar).
Since the refactoring of Discuss [1], a global rule was added to the
'.o_action_manager' to allow the flex to shrink the discussion's list
in Discuss on Mobile.
But this rule change the box sizing of '.o_action_manager' as now it
takes the minimum size (e.g. before 3000px became now 320px +/- the
height of the viewport).
Therefore a limit for the sticky-scroll behaviour of control panel is
set at the end of the height of the element.
Then when the viewport goes outside this limit the sticky doesn't work
anymore until the viewport returns before this limit.
(e.g. <= 320px ok, > 320px ko).
The fix is to change the flex basis of the '.o_Discuss_notificationList'
to be 0 which avoids to alter the global '.o_action_manager' and scopes
rules to Discuss' specific classes.
DOM before this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager' ▲ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ ELEMENT HEIGHT │ │
│ = 'VIEWPORT' │ │
│ 320px │ │
│ ┌────────────────────────────────────────────────┐ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ Control Panel │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ └────────────────────────────────────────────────┘ ▼ │
│ - - - - - - - - LIMIT OF STICKY ELEMENT - - - - - - - │ <- 320px
│ ▲ │
│ │ │
│ OVERFLOW │ │
│ VISIBLE │ │
│ │ │
│ ▼ │
└───────────────────────────────────────────────────────┘
DOM after this commit:
┌───────────────────────────────────────────────────────┐
│ '.o_action_manager' ▲ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ │ │
│ ELEMENT HEIGHT │ │ <- 320px
│ >= 'VIEWPORT' │ │
│ 3000px │ │
│ ┌────────────────────────────────────────────────┐ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ Control Panel │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
│ └────────────────────────────────────────────────┘ ▼ │
└───────────────────────────────────────────────────────┘
Steps to reproduce:
* Open Odoo on Mobile
* Go to a Kanban view with list height at least twice the screen height
* Scroll to the end of the page (the control panel is hidden)
* Scroll a bit upper => BUG the control panel is not visible until we
scroll in the 'box' of the '.o_action_manager'
Note this behaviour is maybe related to an issue from CSS3 [2]
from MDN [3]
Ref:
[1] odoo/odoo@3fea5b2136
[2] Issue 865 on https://github.com/w3c/csswg-drafts
[3] https://developer.mozilla.org/en-US/docs/Web/CSS/positionclosesodoo/odoo#77660
X-original-commit: fdcfaa7b72a4af0d0c3e308e299638fc8fa19bdb
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Description of the issue/feature this PR addresses:
A traceback appears when a time off is at the second approval stage and approved with several employees assigned to the time off.
https://www.awesomescreenshot.com/video/5408638
Current behavior before PR:
When validating a time off that is in the second approval stage with several employees assigned to, a traceback appears
Desired behavior after PR is merged:
No traceback appears when validating a time off that is in the second approval stage with several employees assigned to
task-2657656
closesodoo/odoo#77625
X-original-commit: aaa7c5bf10089eb8953f46cccb2e93aa3a20fa35
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Because test cursors are implemented using savepoints, they should *at
most* be nested (ideally they would be strictly sequenced).
If upon being closed a test cursor finds a *different* un-closed
cursor at the top of the stack, one of its followers / children /
descendants was not closed before it, which is a problem.
The initial version of this would look for the cursor being closed in
the stack but this could lead to incoherent cursor stacks and errors
related to the management of the cursors stack, even though it only
exists for reporting reasons.
closesodoo/odoo#76243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Initialize the savepoint semi-lazily (on-demand) as cycling a savepoint
generates 4~5 queries (depending whether the savepoint is explicitly
released on COMMIT or not):
SAVEPOINT
-- < do stuff>
-- commit
RELEASE SAVEPOINT -- or not
SAVEPOINT
-- close
ROLLBACK TO SAVEPOINT
RELEASE SAVEPOINT
With a lazy savepoint, this is just 0-1 queries (`SAVEPOINT` at the
first explicit query only, creating a cursor and then closing it
immediately is a no-op).
For reliability use a semi-lazy savepoint: always immediately emit a
`SAVEPOINT` on cursor creation, but don't automatically create one
after each `commit`. That limits the issues of overlapping (but
non-nested) savepoints.
Also fix the `generate` API to not use the request: when `website` was
converted to the new API, `cr`, `uid`, and `context` were dropped as
if it were a model... but it's not. So in order to recover an
execution environment, that was looked up on the session.
That, then, turns out to be an issue when `generate` is triggered from
an RPC call: the RPC layer creates its own cursor and environment
separate from the request's which may not have one at
all. Problematically during testing we're in `mono_db` mode, so the
request's cursor/env can be accessed and will be lazily initialized.
This then causes an issue with the `TestCursor`'s savepoints: rather
than be nested, the lifetimes of the request's and RPC's savepoints
only overlap[0]:
|-- rpc --|
|-- request --|
As a result, when the RPC's cursor is committed and released it
automatically released the request's, and the request's explicit
release then fails. This would break `/website:WithContext.test_search`.
By fixing the API of `generate`, it stops triggering the creation of a
request cursor, and therefore the overlap and resulting error.
[0] the laziness or eagerness of the savepointing in the test cursor
has no impact on this issue, as multiple requests have already been
issued on the RPC's test cursor before the request's is even
created
Part-of: odoo/odoo#76243
The query count increases by one because the old code (with
hand-rolled savepoints) never released the `model_load` savepoint.
Part-of: odoo/odoo#76243
Ensure savepoints are *always* released when exiting the context:
rolling back to a savepoint does not release it, so the savepoint
would remain "active" forever (just possibly shadowed).
Also provide a `Savepoint` object to the user, with the following
facilities:
* `name`, in case there are useful things the user can do with a
savepoint name.
The name uses standard UUID representation (rather
than pure hex) because it's otherwise difficult to differentiate
savepoints: in a UUID1, fields 2, 3, and 5 almost certainly don't
change, and the changes between two UUIDs are the last 2-3 nibbles
of field 1 (`time_low`) and the content of field 4 (`seq`, 4 nibbles
at offset 16), with "properly" separated fields it's much easier to
notice the difference.
* `rollback` allows the user to rollback the savepoint to the
initialisation state at any moment.
* `close` allows the use of `contextlib.closing` as well as closing
the savepoint while in the covered span. Closing a savepoint rolls
it back by default (like cursors).
Because there's no such thing as committing a savepoint, it's also
possible to close *without* rolling back, which is similar (but not
identical).
This requires using the semantics of emitting the `SAVEPOINT` during
object initialisation: `closing` was designed to work with non-CMs so
it does not forward `__enter__` to the wrapped object.
Also introduce a CM type for the flushing:
* `_GeneratorContextManager` does not work well when used outside of a
`with`, especially when it yields something: if the CM itself goes
out of scope, the inner generator is `close`d, which raises a
`GeneratorExit` at the `yield` point, which `__exit__`s whichever CM
is held (and in our case would thus rollback and release the
savepoint)
* we probably want to clear() on `rollback`, so having the flushing CM
extend the savepoint one makes a lot of sense
* while it changes the semantics of `Cursor.savepoint` a bit (now
initialises the savepoint at call time instead of delaying until
`__enter__`), it enables the use of `closing` with flushing, and
without having to use the context manager objects directly:
`Cursor.savepoint()` is the only necessary interface, and should
work fine with and without flushing.
Part-of: odoo/odoo#76243
Enabling sql logging for a specific section of code is currently a
pain in the ass as it requires updating both the cursor and the
logger. This utility does that.
This CM is *not* thread-safe as it updates and resets the cursor
without using CAS or anything, so if cursor 1 gets enabled, then
cursor 2, then cursor 1 stops, then cursor 2, cursor 2 will reset the
logger to `logging.DEBUG` which cursor 1 had set, rather than the
probable `logging.NOTSET` it originally was.
Should be possible to fix by e.g. storing the levels in a static
stack (and setting whatever gets popped) buuut... the logging is
already a bit of a mess when multithreaded so I'm unsure it matters
much.
Part-of: odoo/odoo#76243
If `_name_search` is called with `limit=None` it could take time in the loop
because `_name_search` for `product.product` has `limit=100`, i.e. it could be
100 iterations to scan 10 K products. To solve this problem, call `_name_search`
with `limit=None` to get all product variants at once.
As an example, the problem is reproduced on using menu `Manufacturing > Products
> Bills of Materials`, which makes following search query:
```
["|", ["code", "ilike", "XXX"], ["product_tmpl_id", "ilike", "XXX"]]
```
for which ORM calls `_name_search`:
https://github.com/odoo/odoo/blame/9b23864027bc24032993833f213395cb45fe86bb/odoo/osv/expression.py#L863
In a customer database, this speeds up the query from 70 seconds to 3,5 seconds.
---
opw-2631012
closesodoo/odoo#77601
X-original-commit: 038816725a988a0ada3d6f8518a436ea46a81eba
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
For the "Archive"/"Unarchive" button to appear in the contextual "Actions" dropdown,
the field must be present in the view (which wasn't the case until now).
This commit also fixes the indentation of the concerned view.
closesodoo/odoo#77596
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Add _auto_init for stock_picking.sale_id
to speedup the module installation.
Since its related field, group_id.sale_id is also
created in sale_stock, creating the sale_id column is
enough.
opw-2638554
closesodoo/odoo#77546
X-original-commit: bb16d3e9733a669110a16a1341d56eb3420c8ca2
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Armageddon tax being created should include mandatory country_id,
which should be the fiscal country of the test company.
closesodoo/odoo#77295
Related: odoo/enterprise#21208
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
"account_tax_group.xml" and "account_data.xml" data files
have been renamed to "account_tax_group_data.xml"
when containing only tax groups, for compliance with the standard.
AE, AR, AT, BE, BO, BR, CA, CN, CR, CZ,
DE SKR03, DE SKR04, DO, ES, FI, FR, GR,
GT, HN, IL, IN, LT, MA, MX, NL, NO, PA,
PL, PT, RO, SG, SY, TH, TR, UA, UY, VE,
VN.
Part-of: odoo/odoo#77295
Many changes involved several localizations.
Tax groups data files that were missing the country_id:
AR, AU, EC, ET, HR, HU, IT, JP, LU, MN, NZ, SI, UK, ZA
Account_data.xml files being renamed or split to account_tax_group.xml
AT, CH, CL, PE, SK
Tax templates that were missing tax group information:
CH
Tax groups missing that were added:
EC
Part-of: odoo/odoo#77295
L10n_co taxes still needed their correct tax_group,
which has recently become a required field.
The tax groups have been assigned by rate and type.
Part-of: odoo/odoo#77295
The account.tax_group_taxes is the default group for every localization.
Its name shouldn't be overwritten by any localization, otherwise
any company actually using another localization will see the
name of the tax group in a language he doesn't understand.
Part-of: odoo/odoo#77295
The partner created in TestOnchangePostal and the product created in
TestSwissQR were taken from demo data, which might not be installed
in the test environment, so the create_invoice() method could
raise a traceback.
Part-of: odoo/odoo#77295
In Belgium, selling taxes "21% S." and "21%" are exactly the same.
"21% S." can then be removed.
No need to distinguish Services on Domestic Sales.
closesodoo/odoo#77549
Task: 2653824
X-original-commit: 11fd24856e436136236d67f01dd88acc00105e9b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Patrick Hoste