According to
www.agenziaentrate.gov.it/portale/web/guest/schede/istanze/richiesta-ts_cf/informazioni-codificazione-pf
The tax identification number of natural persons
consists of an alphanumeric expression of sixteen characters.
The first fifteen characters are indicative of the master data
of each individual in the following order:
- 3 alphabetic characters for the surname;
- 3 alphabetic characters for the first name;
- 2 numeric characters for the year of birth;
- 1 alphabetic character for the month of birth;
- 2 numeric characters for the day of birth and sex;
- 4 characters, 1 alphabetic and 3 numeric for the Italian municipality
or foreign state of birth.
The sixteenth character, alphabetic, serves as a control.
The main fix is about this part:
When two or more individuals have master data generating
the same tax code (homocodes), the tax code is differentiated
for each of them. For this purpose, systematic substitutions
of one or more digits starting from the right one are made
within the seven numeric characters contained in the code
with corresponding alphabetic characters according to the
following table:
0 = L 4 = Q 8 = U
1 = M 5 = R 9 = V
2 = N 6 = S
3 = P 7 = T
Also the check for iva number format was incomplete.
Indeed, The three penultimate digits correspond to the region of the
VAT office and must be between 001 and 100 inclusive,
or equal to 120, 121, 888 or 999.
We use the stdnum library's methods for the validation of fiscal code
and iva number format.
opw-2797408
closesodoo/odoo#97633
X-original-commit: 262eb7bd021d177d9a05397f9cda3fc76a21d4cb
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
1. Add a few products to your cart.
2. Go to the checkout page, and stop right before clicking on 'Pay now'
(ie: customer goes to find the credit card and comes back later)
3. On another tab, go to the backend and cancel the sale.order
4. Go back to the website tab, and click on Pay now
5. Complete the payment process
Result:
* The customer is able to pay a cancelled order.
Expected:
* It shouldn't be possible to click on 'Pay now'
closes odoo/odoo#97630
Forward-port-of: #96549
X-original-commit: 37c3cf55d507e0bccf9db3e63503dfec896dfaef
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, milestone is still visible in project burger
menu even if we disable the milestone feature and due to that while
creating the milestone it was generating the traceback.
So in this commit, add groups on milestone option on project burger menu.
task-2918411
closesodoo/odoo#97629
X-original-commit: 1a7e2a298c2cbf076ce96dae85805f9dd77c7e0d
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
When issuing a refund for a reverse charge bill, the document type
should be the same as the parent bill type (either TD16, TD17 or TD18,
rather than TD04), and the values of the lines and totals should be
negative.
To fix this the values are made negative dependent upon whether the
invoice is a 'rc_refund' as in a "reverse charge refund". The way that
the document type is ascertained is also changed in order to include the
'in_refund' (for the case of the reverse charge refund).
The way document_total (ImportoTotaleDocumento) has been made
conditionally negative in the case when the invoice is a reverse charge
refund.
A test has been added for the reverse charge refund case, and the test
taxes have been adapted so that the correct tags are being used (and so
that tags are used on the refund lines).
closesodoo/odoo#97619
Ticket-id: 2936967
X-original-commit: ca2f4c8e1babe9444bc2c6a7421eafb63f1c9346
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
Before this commit, opening a misc journal entry resulted in an error because we tried
to compute the tax totals as if it was an invoice.
This commit ignores the computation of these tax totals in case we have a misc journaly entry.
opw-2946634
closesodoo/odoo#97600
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
2-steps receipt. A reordering rule created a picking from Input to Stock
and a purchase order to fulfill the need from Input. The user now
decreases the quantity of the purchase order and then confirms it: an
unexpected picking is created.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
- Incoming Shipments: 2 steps
3. Create a product P:
- Type: Storable
- With a vendor
- Routes: Buy
4. Add a reordering rule to P:
- Min = Max = 0
5. Create and confirm a planned delivery order with 5 x P
6. Run the scheduler, it should create:
- An internal transfer IT (Input -> Stock) with one stock move SM
- A purchase order PO
7. Edit PO:
- 4 x P (instead of 5)
8. Confirm PO
9. List all transfers related to P
Error: There is a transfer from Stock to Input with 1 x P. It should not
exist and its stock move should be merged with SM
As explained, when running the scheduler, a stock move from Input to
Stock is created. Let SM01 be that stock move.
When confirming the PO, two stock moves SM02 and SM03 are created, both
from Vendors to Input. The first one has a quantity equal to 5 and the
second one to -1. When confirming these stock moves, we apply the 'push
rules'
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1233
Since SM02 already has one `move_dest_ids` (i.e., SM01), we skip it.
However, we can apply a push rule on SM03. It creates an new stock move
SM04 with -1 x P from Input to Stock:
https://github.com/odoo/odoo/blob/7e8a038e3a08e32a9a32ac66ef0dc67800af95cb/addons/stock/models/stock_rule.py#L192-L196
And, as shown in the above code, we then define this new SM04 as a
`move_dest_ids` of SM03. So, at that point, here is the situation:
| Name | Qty | From | To | Dest |
|------|-----|---------|-------|------|
| SM01 | 5 | Input | Stock | / |
| SM02 | 5 | Vendors | Input | SM01 |
| SM03 | -1 | Vendors | Input | SM04 |
| SM04 | -1 | Input | Stock | / |
Back to the confirmation of SM2 and SM3, we eventually try to confirm
the moves created from push rules (i.e., SM04):
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1268-L1269
As shown, we don't define any `merge_into`. During the confirmation of
SM04, we try to assign it to a picking. However, because of its negative
qty, we skip it:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L1077-L1081
Then, still in the confirmation of SM04, we try to merge it with some
other SMs. Because there isn't any `merge_into`, we try to find some
candidates:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L839-L840
And because SM04 does not have any picking, we don't find any candidate:
https://github.com/odoo/odoo/blob/0183298293192538a801f52262c047ea34a1b76a/addons/stock/models/stock_move.py#L826-L828
As a result, we don't merge it and we will create the unexpected
picking.
=> In such situation (when confirming a negative push move), we should
suggest some candidates.
Last but not least: suppose the above issue as fixed and reproduce the
same steps, but this time the product P has a description. Again, when
confirming the PO, the same unexpected picking will be created.
When running the scheduler, SM01 is created and its field
`description_picking` is defined thanks to the description of P:
https://github.com/odoo/odoo/blob/f11d9c3ea08fc98e62459602d9bce004e83898db/addons/stock/models/product.py#L237-L243
However, when creating SM03, we use the name of the purchase line (i.e.,
the product's name) as description because, in our case, the product
does not have any `description_pickingin`:
https://github.com/odoo/odoo/blob/c18b2ce767dd5a5b4dbe766b849b56243dffb723/addons/purchase_stock/models/purchase.py#L523
And, as shown before, SM04 is partially a copy of SM03: it has the same
`description_picking`. As a result, SM01 and SM04 doesn't have the same
value for that field and we can not merge them.
OPW-2861605
closesodoo/odoo#97599
X-original-commit: 43ca47cdfec696b847f716984f76df16de7b97b7
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Steps to reproduce:
- Open Online Appointment in list view
=> a "double-border" is visible above the optional columns button
closesodoo/odoo#97592
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, modifiers containing conditions on the `id`
field weren't always correctly evaluated in form views. This
happened on new records, when the `id` field wasn't present in
the view. In this case, its value in the evalContext was
`undefined`, so a domain like `("id", "!=", "False")` was always
evaluated to true. The `id` field is handled a bit differently
than the other ones, as we do not require for the field to be
present to use it in modifiers (mostly because we don't need it
to be present to know its value).
This commit fixes the issue by forcing a `false` value for `id`
when the record has no id yet.
closesodoo/odoo#97587
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
odoo/odoo#87678 redesigned part of the search_panel however one of the
old bootstrap calsses was still used which resulted in sub categories
rendering poorly.
This commit changes that class to the new name.
closesodoo/odoo#97585
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
When #96517 was merged, it was missed that if hr is *not* installed,
then the user profile opens in a dialog in edition mode (always, can't
be readonly).
Since half the tours of `auth_totp` end in the profile screen (to
check that the totp state is what we expect) this means they work fine
in most test contexts where `hr` is installed, but they fail as soon
as `hr` is *not* installed.
Fix this by adding a helper function which checks whether the profile
screen uses a dialog or not, and closes the dialog if so (otherwise it
does nothing as the "form" profile screen is not in edition mode).
While at it, improve a bunch of steps:
- fold check steps which were really `extra_triggers` (something we
wanted to check but not manipulate, in the same screen as something
we do want to manipulate)
- convert a few promise-based functions to `async` (tours don't
support promises but async functions work either way and lead to
simpler code here)
- make better use of the tour action helpers (no need for explicit
`_get_action_values` calls for the most part, and no need to
call the internal versions either)
- clarify a pair of fixmes as I'd completely forgotten what they meant
closesodoo/odoo#97567
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, the column customization icon sometimes covers the
last column header in list views (or the 'ordering carret' icon).
Steps to reproduce:
- open Survey in list view
=> Avg Score column header overlaps with the icon
This commit adapts the headers last column's padding and the
customization icon's width to match each other and avoid overlapping.
It also adapts the vertical positionning of the icon.
task-2816987
closesodoo/odoo#97562
Related: odoo/enterprise#30165
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
`webclient/*` defines the main infrastructure for views and as such also
global components/utilities (like Odoo Icons variables/utility classes).
But, as the `views/*` are included *before* `webclient/*`, they can't
use SCSS variables defined in `webclient/*`.
This commit fixes it by interverting their order, which has a
significant effect on the SCSS output, but not the JavaScript (as the
modules system is responsible of the imports order, not the bundler).
Part-of: odoo/odoo#97562
When starting the import contact wizard from an active mailing list, the
mailing list to which the contact will be imported was not set. This solves the
problem.
Task-2924241
closesodoo/odoo#97560
X-original-commit: cdd102f30d2092fa31911ab2f00e90fec846165b
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When importing email in mass mailing through the form (not with an excel file),
incorrect email lines were concatenated with the following next valid email
line, resulting to an incorrect import.
This solves the problem by ignoring incorrect email lines.
Technical note: the test test_mailing_contact_import has been slightly modified
to include invalid lines in the text to import, not only at the end but also at
the beginning and in the middle (the test fails before the fix and not after).
Task-2924241
X-original-commit: bd4a933f2b3259c3482b811227de0e06c7018969
Part-of: odoo/odoo#97560
Before this commit, if the header of a column (X2many/ListView) has the
focus, a record is being edited and a key is pressed, then a crash is
displayed.
closesodoo/odoo#97559
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adapts the agenda template to avoid displaying a complete column
for a location if that location is unused for this specific day.
This allows having multiple different locations for your different event days
without cluttering the display by showing empty columns for unused locations.
Task-2942630
closesodoo/odoo#97537
X-original-commit: 129b91027700313066db0305876adcf9b2a3817d
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Steps to reproduce:
1. Go to Inventory-->Settings-->Check option to "Display Lots & Serial
Numbers on Invoices"
2. Go to Rental App
3. Create a new Rental Order for a product that is tracked by Serial
Number. Pop up shows up. Also something to note here, though not
necessarily related to this ticket, but you cannot select available
serial number from this pop-up. It doesn't let you choose anything
even when there are multiple serial number available/in stock.
4. Confirm the order.
5. Validate the Pickup and set the Serial Number in the popup.
6. Create the invoice.
7. Confirm the invoice.
8. Print "Invoices without payment"
Bug:
in https://github.com/odoo/odoo/commit/7a030f616f7e04b3994fc718840d265b1dd21068
the filter functions were removed. They had the effect
of making sure that the sml is either a delivery or a return
by filtering on `sml.location_id.usage` and
`sml.location_dest_id.usage`
Fix:
check if the product is a delivery or a return by
making sure that either of `sml.location_id.usage` and
`sml.location_dest_id.usage` is `customer`
OPW-2936505
closesodoo/odoo#97532
X-original-commit: 953fefe736bab1cbfa3ecacd33cd1662a4dcf580
Signed-off-by: Adrien Widart <awt@odoo.com>
External images were linked to in the Recruitment email templates,
however those were not showing in the email client.
odoo/upgrade#3670
task-2908038
closesodoo/odoo#95630
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit fixes a glitch on iOS (both iPhone & iPad landscape) where,
when the user attempts to open the datepicker of a custom filter's
field, it pops up and immediately close.
This is due to the desktop behavior which hides datepickers on scroll to
avoid hidding fields behind it.
In our case, a scroll is triggered once the focus is set in the date's
input and the virtual keyboard opens up... which then hides the
datepicker!
Sadly, this behavior's purpose being still useful in desktop, we don't
have much other solution than "just" disabling it on affected platforms
(ie. iOS) as it affects both small screens (ie. iPhones) and
dekstop-like ones (ie. iPad).
Hopefully, a better solution will be found at some point in a future
version, avoiding this kind of "trick"...
Note: replacing the "scroll" event with the "wheel" event seems to fix
the issue at first glance... but actually has side-effects for devices
using both touchscreens and a mouse (ie. 2-in-1 laptops).
Steps to reproduce:
- Open any collection view (list, kanban...)
- Open "Filter" dropdown and add a custom filter
- Choose a date/datetime field (ie. created_on)
- Tap the input
=> datepicker opens up and close immediately
opw-2671618
opw-2819299
closesodoo/odoo#97521
X-original-commit: 1895411d29b2b803c36bded11ba79c92e5c8756d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The widgets related to "custom" image filters in the case of background
images were never shown anymore since [1]. [1] is actually a
forward-ported version of [2] but the bug only appeared since [1] as
the forward-port adaptation created the error: the widgets of this
option were not shown or hidden before... but simply not rendered at
all, kinda by mistake. The adaptation in [1] used the conventional way
of doing things by using the `_computeWidgetVisibility` method to
indicate if widgets should be shown or not. The problem is that an
error was done when writing that visibility condition.
[1]: https://github.com/odoo/odoo/commit/89ce9f9ab5b8db148c273f70be0a06c768892566
[2]: https://github.com/odoo/odoo/commit/7c17d78fbdbb64b1aa5b55f78d3202a64a85ed2fclosesodoo/odoo#97514
X-original-commit: 10a48dc213117c4ac29b1ce56d3f1c02e58111d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Have a color field with an onchange on it.
Change the color.
Before this commit, the onchange was not passed to the server. This was
due to the internal of ColorField, which refreshed its value to the old one
even before owl or odoo did anything.
After this commit, the call to onchange is correctly passed.
closesodoo/odoo#97476
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Spawn a form view with a record and set its props "mode" to readonly.
Click on "Create".
Before this commit, the new record was in readonly mode.
This is never what we want, we always want a new record to open
in edit mode.
After this commit, the new record is in edit mode.
closesodoo/odoo#97451
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, when the kanban view is grouped by m2o field, the
columns can be resequence by doing a drag and drop on one of them. In
some cases, this resequence should be disabled to keep the order of the
columns in the kanban view. For instance, in the project sharing
feature, the views are accessible by the portal users to easily follow
the tasks in the project shared but the actions allowed to the portal
user are restricted to only one model (that is `project.task` model).
So, in that case, the order of the columns should always be the same.
To avoid doing a customization code to be able to prevent the
resequence of columns in the kanban view, this commit adds a new option
in the kanban view called `groups_draggable`. By default, this option
will be true to allow the user to resequence the kanban columns
(if the field used for the group by is a m2o and not readonly).
If the option is false then the resequence of the kanban columns will
be disabled.
task-2941335
closesodoo/odoo#97447
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the parameter sent to the legacy fields were
different if the field was used on the form view, or on the kanban/list
view. Specifically, the attrs were not sent when the field was use on
the form view, and the viewType was not send when the field was use on
the kanban/list view.
Now, we standardize the parameters sent to the legacy fields regardless
of the view they are used on.
closesodoo/odoo#97431
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue:
In finnish localization, partners have by default account payable "2700 Velat saman konsernin yrityksille, pitkäaikaiset" which is incorrect
Expected behaviour: The default account payable for finnich localization should be "2870 Ostovelat"
Solution:
In l1On_fi/data/l10n_fi_chart_post_data.xml, the "property_account_payable_id" is set to "account_2700". Just change it to "account_2870"
closesodoo/odoo#97212
X-original-commit: 4efb8928a4f000dab0b62f84d3a01ee2632f8b19
Signed-off-by: Josse Colpaert <jco@odoo.com>
In the QUnit test suite, we have cleanup code that runs after each
test to ensure that event listeners, setTimeouts... registered
during a test are removed. This is particularly useful for services,
as they do not have a "destroy" function to cleanup those handlers
they would have registered at startup. Side note: they don't
because it would only be useful for tests, as a service lives
forever in the prod environment.
Before this commit, that cleanup code didn't remove callbacks
registered with a setInterval. Moreover, we didn't remove event
handlers bound on document.body either. As a consequence, there
were memory leaks in the test suite (e.g. callbacks of the tooltip
service), and some crashes could occur if the user interacted with
the window after test completion.
closesodoo/odoo#97100
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
There can be many accounts in self and the "search_read" is currently breaking because of self.company_id in the domain.
This commit addresses two problems:
- Creating accounts in a multi-company environment
- Setting a default account_type when there is no parent found.
Account codes should however be still limited to the current company even though for performance reason we batch the searching part.
closesodoo/odoo#96832
Signed-off-by: William André (wan) <wan@odoo.com>
This adds a series of tests for the editor's Powerbox and its
integration with the editor.
closesodoo/odoo#96287
Related: odoo/enterprise#29649
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The upgrade from Bootstrap 4 to 5 broke the display of the Powerbox when
the editor is in a modal. This adapts the Powerbox's z-index to make
sure it always displays above a modal.
task-2901697
Part-of: odoo/odoo#96287
Odoo Editor's styles were defined in CSS when it was all still part of
a separate repository. They can now be converted to SCSS, which will
allow us to use Odoo's SCSS variables in the future, and allows us now
to refactor the styles in the more readable SCSS format.
Part-of: odoo/odoo#96287
This introduces a new API for the Powerbox, which allows to order its
commands and categories. The order is based on the priority assigned to
the category or command. If two items have the same priority, they are
ordered alphabetically.
To order categories, pass said categories in the Powerbox's params, each
with its own priority. If a command declares itself as part of a
category that was not itself declared, said category will be added
automatically, with the lowest priority.
task-2901697
Part-of: odoo/odoo#96287
- Merge `_check_barcode_unique` and `_check_barcode_uniqueness`.
- Simplify the code and avoid costly read_group
- Add missing index on barcode of `product.product` (before there was an
unique constraint)
(Note that the constraints isn't transactional safe because it is not an
SQL contraints)
closesodoo/odoo#96043
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
This commit improves the helper message in team member action
task- 2583755
closesodoo/odoo#92616
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When we open the 'CRM > Configuration > Team Members' menu, if there are no
members in any of the teams, we see the empty screen(no dummy data, no
action helper), which looks a bit ugly.
This commit improves the behavior by displaying all the (accessible) sales
teams, even if they are empty. So, even if there are no members available,
we will get to see the dummy data and action helper.
Note that in the data, we already have one sales team available, so this
should be okay. But if someone intentionally removes all the teams, it
will still lead to an empty ugly screen. Since this is a rare case, we
haven't considered it for now.
task-2583755
Part-of: odoo/odoo#92616
Before this commit field `visits` was not displayed on form view.
With this commit, Field is now readonly at model level and
added on form view.
closesodoo/odoo#74336
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The redirect field in website does not work properly in the new views.
With this commit, we just reimplement it to make it work with the new
code.
closesodoo/odoo#96865
Related: odoo/enterprise#30178
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the rules on oe_stat_button only applied if the stat
button was a direct child of the button box. However, this is a problem
with the way fields are now wrapped in a div, so it is no longer
possible for a field to be styled like a stat button.
With this commit, we simply make the rule less restrictive.
Part-of: odoo/odoo#96865
With the new views in owl, we wrapped every field in a div with the
class o_field_widget. This is a good thing in general, but it has the
issue that before this commit, the display property was set to
inline-block, in all cases.
With this commit, we set it to 'contents', which means that it will
simply get the correct display value from its content.
Part-of: odoo/odoo#96865
Before this commit, the isVisible helper would most of the time work as
expected, except if an element has display: contents. In that case, it
has no bounding box, but it may still be visible if one of its child
is visible.
This is particularly important since we want to set the display property
of all field components to "contents".
Part-of: odoo/odoo#96865
* Clean tests setups
* Use setUpClass instead of setUp
* remove useless test data or move it to the place(s) of use
* when possible, use existing test data instead of creating another custom setup for the current test
* remove unnecessary dependencies on accounting common
* make tests work without demo data (when not relying on accounting common)
* run base product/sale tests without triggering mail logic
* create records in batch to improve performance (reduced queries, batched operations, ...)
* Create the base of a clean test architecture for those modules (with dedicated commons in the right modules)
* Improve some tests (mainly prices/pricelist tests in sale)
* Add `mute_logger` contexts in some tests to reduce useless test logs
* Try to improve tests consistency (fixed test currency, archiving existing demo data to avoid side-effects, ...)
* Move most `product` tests `post_install` to benefit from the split of `post_install` tests on runbot.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#96791
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
New common based on new common infrastructure (base, uom, product, sales
team).
* Conversion of existing tests to use the common
* Remove invoicing tests common dependency when not needed (overkill
setup for most tests)
* Move tests to the correct test file.
* Rename test_sale_pricelist into test_sale_prices and add tests to
improve coverage of price computation.
* new file test_controllers to regroup all tests covering the routes.
* Speed up tests setup by creating records in batch
* Reduce tests setups and use more the common tests data.
Part-of: odoo/odoo#96791
Guillaume (guva)