Separates the file `model/purchase.py` into two files:
- `model/purchase_order.py`
- `model/purchase_order_line.py`
Since every model should have their own file, `purchase.order` and
`purchase.order.line` have it now.
Part-of: odoo/odoo#135502
The `flanker` python library can be installed to implement optional
email address validation.
Nevertheless, it is not fully supported in python 3 (see https://github.com/mailgun/flanker).
Recent issues point to the fact that the latest pip release version 0.9.11
does not work under python 3.10.
This can lead to features, using the email validation, creating blocking
behavior due to error tracebacks.
As this is more of an issue on flanker's side than Odoo's, we remove the
`pip install` instruction. It can be assumed that someone wanting to go
out of their way to install flanker, should be proficient enough to either
make sure the python <3.10 is running or install one of the Github repo tagged
versions.
After this change, we still inform the user of the optional feature, but do not directly
incite them to pip install it, which should prevent normal users from
inadvertently blocking parts of their Odoo database.
opw-3562596
closesodoo/odoo#139800
X-original-commit: 637e60cb9687e9859d081f7367717c84d29fb82a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
[Here](https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/odoo/tools/translate.py#L1645) If 'en_US' is exist in new_values then as a default language 'en_US' translations are loading due to that translation of default language gone lost
OPW -3482255
original translation look like this
if default language is dutch for example then instead of dutch language english's translations are there
```
en_US : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
fr_BE : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this french</p>
</t>
</t>
nl_NL : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
```
arch_db look like this
```
en_US : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">I transalted to english</p>
</t>
</t>
fr_BE : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this french</p>
</t>
</t>
nl_NL : <t t-name="website.test">
<t t-call="website.layout">
<p class="o_default_snippet_text">this dutch</p>
</t>
</t>
```
closesodoo/odoo#139111
X-original-commit: 542851c50182f32327f9cd3607081515899ddb76
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Sanchit Gupta (sagu) <sagu@odoo.com>
Those are no longer used and should never be displayed
Source: feedback of users that were wondering why they are subscribed
to very old unrelated mailing lists while those are all inactive
closesodoo/odoo#139442
X-original-commit: 35203a93dbb002e2e8c6943073c14acdfc5f90f1
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Description of the issue/feature this commit addresses:
Currently, the payment registration for vendor bills is kinda hard to figure.
Noticing which bills are overdue, which require a payment is not made so easy
by the interface and could be improved. Also there is no way to register a
payment for multiple lines at a time which could improve the UX.
Desired behavior after the commit is merged :
The buttons "Bills to Pay" and "Late Bills" redirect to a Journal Items view
called Payment Items with specific filters to show only the necessary lines.
The order of the columns in the Journal Items has been changed and their
visibility has been changed too.
The default filters of the Journal Items when coming from the dashboard buttons
has been changed. Payable has been replaced by Purchases.
Filters, Group by and Search by options have been added for the Due Date
and the Discount Date fields in the Journal Items.
task-3516496
closesodoo/odoo#138188
Related: odoo/enterprise#48679
Signed-off-by: William André (wan) <wan@odoo.com>
Refactor the "details" part of the portal view to unify with subscription
as well as add different id "hooks" for inheritance.
task-id : 3186629
Part-of: odoo/odoo#137563
Current behaviour:
When your current company is South Korean,
The chart of account is generic.
If you try to create a South Korean company
branch, you'll get an error message:
The Currency of a subsidiary must be the same as its root company.
Steps to reproduce:
1. Install account_accountant
2. Go to Settings
3. Go to Users & Companies > Companies
4. Create a new company
5. Country: South Korea
6. Currency: KRW
7. Switch into the new company (top right)
8. Go to Accounting
9. Go to Configuration > Settings
10. Fiscal Localization: Generic Chart Template
11. Save the changes
12. Fiscal Country: South Korea
13. Main currency: KRW
14. Save the changes
15. Go to Settings
16. Go to Users & Companies > Companies
17. Select the Korean company
18. Create a new branch
19. Country: South Korea
20. The Currency of a subsidiary must be the same as it's root company.
Cause of the issue:
The generic chart of account's currency is USD
opw-3537346
closesodoo/odoo#139796
X-original-commit: 303fde24a62269159def12760e438997f6c6f147
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behavior:
After uninstalling the PoS module, if you try to install it again, you
get a traceback because Odoo is trying to create a sequence that already
exists.
Steps to reproduce:
- install PoS
- uninstall PoS
- install PoS
- you get a traceback
opw-3515647
closesodoo/odoo#139767
X-original-commit: c57bb574721a3610f66320dacdc703abc490d5d4
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Steps:
- Install fleet.
- Create new. Select a car.
- Goto `Model` page.
- Below CO2 Emissions string there is Co2 Standard string.
Issue:
- In the Engine section, there is a `CO2 Emissions` and a `Co2 Standard` field.
If these are both referring to carbon dioxide, then they should be written
consistently in the same format (CO2). Currently, one has a lowercase `o` while
the other (correct) one has a capital `O`.
Fix:
We are adding the necessary string.
task-3498197
closesodoo/odoo#139761
X-original-commit: 8b4a22baa92f196361f1ef622b55312015cf8128
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
At the moment, the efaktur system will consume a number even
for invoices not using any taxes.
This change will try to avoid that by not consuming numbers
for invoices when no lines has a tax_ids set.
task id #3130665closesodoo/odoo#139757
X-original-commit: 59c434773c17f81d3a1c160407e8b4533f48e911
Signed-off-by: William André (wan) <wan@odoo.com>
People must be able to install `point_of_sale` without `pos_restaurant`
if they don't need it. But in order to let users know that they can
install `pos_restaurant` directly, we make it an app, that will also be
selectable from the Start Trial page.
closesodoo/odoo#139733
X-original-commit: 2d9d8ea78f71669486644bdb599d2b4a5cc7a5c8
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
Purpose
=======
Cannot currently save My Profile due to those 2 fields
- attendance_manager_id (allowed for groups 'Attendances / Administrator')
- employee_cars_count (allowed for groups 'Fleet / Administrator')
They are in the SELF_READABLE_FIELDS property, but the method
check_field_access_rights is not taking that information into account.
Part-of: odoo/odoo#139731
Before this commit, a time window of two years was being used for requesting events occurrences from Microsoft Graph API. This way, events that were not being visualized in the calendar view were being fetched from the API many times, wasting requests and decreasing the calendar app's performance.
After this commit, this time window is limited to the range being shown in the calendar view to avoid fetching events not being visualized and then increase performance.
closesodoo/odoo#139721
Task-id: 3525764
X-original-commit: ceab3ee21d3e6eb4cfcf0a0cd8df40873744beaa
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Before this commit, crap sql query were performed with a lot of recurring events were searched:
```
bad query: SELECT "calendar_recurrence".id FROM "calendar_recurrence" WHERE (((((([...]
((((((("calendar_recurrence"."microsoft_id"::text like '%:XX0') OR (
"calendar_recurrence"."microsoft_id"::text like '%:XX1'))
OR ("calendar_recurrence"."microsoft_id"::text like '%:XX2')) OR ("calendar_recurr [...]
```
After this commit, the search method was replaced for a SQL query, thus not exceeding memory limit anymore when receiving many records from Outlook.
Task-id: 3525764
X-original-commit: 2b089ce43a6290865699c3b9167edc9eb9648a3d
Part-of: odoo/odoo#139721
- If an edi user needs cancellation before they were registered on the SMP,
we should let them cancel and return to the very first step.
We don't need the edi user anymore in that case (no messages could've been
received or sent) so we can safely unlink.
Same is done on the proxy side.
- With that, reopening the registration is no longer needed,
as we currently don't let users reopen their application when they're rejected.
closesodoo/odoo#139718
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
- `peppol_move_state` is only useful when sending an invoice/credit note.
Hide this field from the form view and the tree view for vendor bills and refunds
- when getting new documents from the IAP, ignore messages with peppol state
`error` as these are not useful for the users.
Also, if there is an error when creating an invoice from the attachment,
the vendor bill should still have `peppol_move_state` set to `done`,
because we have received the vendor bill after all.
Users can fill out missing details if necessary, by looking at the attachment.
Part-of: odoo/odoo#139718
steps to reproduce:
- create product A with optional product B
- add product A as optional of product B
- create SO with product A and add optional product B in configurator
after this commit choosing optional product is fixed
opw-3388598
closesodoo/odoo#139709
X-original-commit: b416e0b684c3e371d70db3a9f6653f1371acf972
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>
Purpose:
-------
Commit [1] added the properties field on the product.product template.
However, the product.template model is more suitable to hold these
properties as the product.product model already has attributes which
are quite similar to properties.
Task-3570286
[1]: https://github.com/odoo/odoo/commit/70043822103638f651a521bd2da36cfdfd86245eclosesodoo/odoo#139702
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commits add a signature to the website_form.
The purpose of this modification is to allow the controllers to be
able to verify that the form was originally generated from the view.
This prevent the end user to submit arbitrary values to the website_form
controller.
In this commit, email_cc and email_bcc are treated as the same fied as
it holds the same function
This does not offer protection against submission replay. Previous versions
of the form are not invalidated by editing the view.
If one need to completely reset that protection and invalidate the
previously generated website_form, the only solution is currently to
change the database secret.
closesodoo/odoo#139701
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
It seems that the invisible is not working on filter and so the fiscal
country_code cannot be evaluated which causes a Traceback when trying to access
the res_partner form view.
closesodoo/odoo#139698
Task: 3270458
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Without the Accounting app and the Bank Reconciliation part, the menu item "Reconciliation Models" is irrelevant. We therefore move the menu item from account to account_accountant.
task-3540705
closesodoo/odoo#139689
X-original-commit: 17f3fc980bf65f3ca4a02da998afafdfd386e0de
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Currently if a record is not in the cache it raises a `CacheMiss` the
handling of which leads to loading the record from the database (or
something).
If an issue occurs during that loading, because the loading is an
`except` scope the cache miss gets linked with the new one via
> During handling of the above exception, another exception occurred:
This is both noise (the cache miss is not actually relevant) and
misleading, because the wording makes it look like an unrelated error
occurred during handling.
- move the loading of the record out of the `except` to limit the
scope of the `KeyError` and avoid "inheriting" it
- try to `from None` a few specific errors to remove implicit linkage,
as the new error should have all relevant information, the key error
/ cache miss is just an implementation detail
closesodoo/odoo#139680
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps:
- Create a contact with 2 sub contacts Sub1 and Sub2.
- Create a service product with project creation on order.
- Create a quotation for Sub1 and the created product and confirm.
- Go to the created project and create a task.
- Edit the task and change the customer to Sub2.
- Empty the sale order item.
Issue:
The sale order doesn't appear in the drop list.
Cause:
Wrong domain on ``ProjectTask.sale_line_id``.
opw-3441194
closesodoo/odoo#139670
X-original-commit: 8b6bd8c92402a92efed71f97de61eaeffb0caea7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit it is impossible to find the qweb error when you preview an email template.
closesodoo/odoo#139668
X-original-commit: 1f373de5f218a1f43015f4f80e60d1da0188d6b5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Structure `peppol_move_state` according to the following logic:
1. Ready to Send / Invoices confirmed addressed to partners that are Peppol valid and not in one of the other statuses. Default behavior upon posting such an invoice.
2. Queued / In case of asynchronous sending only, the instruction to send has been given via the Send & Print but the cron wasn't run yet. It is still possible to cancel the sending.
3. Pending Reception / Too late to cancel, synchronous or asynchronous sending makes it now impossible to cancel the sending
4. Canceled / Once asked explicitly by the user. It's instant.
5. Done / Upon confirmation or delivery received from the AP
6. Error / Upon confirmation of a notification of error received from the AP
Add an action on sale journals to open invoices that are ready to be sent via Peppol
- Peppol ready filter in Customer Invoices view
- Rename `PEPPOL state` to `Peppol status` for consistency
- Pre-fill valid phone numbers in `account_peppol_phone_number` field
- Fix async sending in demo mode
closesodoo/odoo#139615
Signed-off-by: Laurent Smet (las) <las@odoo.com>
We don't want to allow to send multiple invoices by email if there is
no mail template set. It would lead to unwanted behaviors.
closesodoo/odoo#139612
Related: odoo/enterprise#49477
Signed-off-by: Laurent Smet (las) <las@odoo.com>
- Clean computes to avoid unnecessary recomputations and improve
the readability.
- Various small fixes after this refactor PR https://github.com/odoo/odoo/pull/139311:
wrong usage of `self`, missing `api.model`
Task-id: 3415101
Part-of: odoo/odoo#139612
*: pos_online_payment_self_order,pos_restaurant,pos_self_order
Previously, when self order was set to "pay after each" and a user
ordered an order with a total of $0.00, the order was not automatically
set to paid status, as is the case with point_of_sale.
Now, when the self order is set to "pay after each" and an order with a
total of $0.00 is placed, it will be automatically paid.
Minor fixes:
- A props has been removed from `ReceiptHeader` because it was causing
an error in debug mode.
- In point_of_sale, when an order was placed with a total of $0.00, an
error was raised during validation because no payment method was
selected. Now, before checking this payment method, we first check
whether it exists.
closesodoo/odoo#139555
Related: odoo/enterprise#49442
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
pos*: l10n_es_pos, point_of_sale, pos_hr, pos_loyalty, pos_online_payment,
pos_online_payment_self_order, pos_restaurant, pos_sale, pos_self_order
In this commit we refactor all the pos tours.
Changes:
- Removed the `startSteps`, `getSteps` functions as they were
no longer serving a purpose. We now simply put the tours steps
in the array returned by the function given to `steps`. We
apply `flat()` to this array in order to be able to provide both
single steps and arrays containing multiple steps;
- removed the classes from the tours. Now each helper function
is simply exported from it's file and is consumed as `import * as myHelpers`;
- removed the `do`, `check`, `exec` subpaths as they were not providing
a clearer api. The functions themselves already have descriptive names.
( writing `ProductScreen.do.clickHomeCategory()` is not clearer than
`ProductScreen.clickHomeCategory()` )
- formatted all files.
closesodoo/odoo#139317
Task: 3565443
Related: odoo/enterprise#49313
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Purpose
=======
Make it possible to compare analytic values between plans by inputting
up to one account per plan on each line.
For instance, if we have 2 plans: "Country" and "Product Type", with the
following accounts
| Country | Product Type |
| ------- | ------------ |
| BE | Drinks |
| LU | Food |
And the following invoices:
* 1000€ of drinks in Belgium
* 2000€ of food in Belgium
* 3000€ of food in Luxemburg
We want to be able to display the following pivot tables:
| | Drinks | Food | Total |
| --- | ------ | ---- | ----- |
| BE | 1000 | 2000 | 3000 |
| LU | 0 | 3000 | 3000 |
| Tot | 1000 | 5000 | 6000 |
| | Total |
| ------ | ----- |
| Food | 5000 |
| * BE | 2000 |
| * LU | 3000 |
| Drinks | 1000 |
| * BE | 1000 |
| Total | 6000 |
Implementation
==============
* `ir.fields` are added/removed dynamically on `account.analytic.line`
* Each analytic plan corresponds to one field on `account.analytic.line`
* The fields are added dynamically in the views.
* `account.analytic.plan` doesn't have a `company_id` field anymore,
meaning that all the companies have access to all the plans. This
means that the applicability fields and lines are now company
dependent, and those can be used to know which fields/plans to display
for which company.
* There can no longer be one "Project" plan per company, even if the
accounts of that project can still be owned by only one company.
* There is now only one method to get the default (or "Project" plan),
which is `_get_plan_columns`
task-3497653
closesodoo/odoo#139225
Related: odoo/upgrade#5306
Related: odoo/enterprise#49226
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william <wan@odoo.com>
Co-authored-by: h4818 <ayh@odoo.com>
Currently, users who want to change the visibility of product's
documents need to open their form view and edit it.
The selection widget now allows users to quickly edit the way a document
is displayed to their customers from the product's documents kanban view.
Part-of: odoo/odoo#137975
The rational is:
Currently we have 2 columns. One for reservation, the other
for quantity picked.
However in real time, either you follow the reservation and everything
goes well. Otherwise you pick something else. In the case where you
pick somewhere else than reserved, you would like to modify the
reservation to have something similar and free the quantity you
didn't pick and expect the system to not suggest the ones you took.
In other hand, we always want to have the reserve quantity similar to
the done.
On top, having two columns could be confusing for the end user.
The cons:
-The qty_done column could be use during the picking, to
remember if something has been pick or still to pick.
- For some flow (put in pack), it's easier to write a part of the quantity to pack
and still want to reserve the full amount of product.
We goes back and choose a ligther interface over complex feature.
Changes:
Qty done and reserved qty are merged into a single column.
A new checkbox on the move exists to mark it as picked or not
Since the reservation always follow the quantity, it's now possible
to have more reserved quantity than stock. However the system will
never propose it and the inventory showing reserved > quantity should
be a warning.
The system should never modify a move that has been picked. We don't
want to overide the user action.
Regression:
Not able to pick a single stock.move.line
closesodoo/odoo#137864
Related: odoo/enterprise#48709
Related: odoo/upgrade#5310
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
In this commit a new default floor plan is added along with one table when
creating a new restaurant pos_config. It ensures that the default floor
is removed for the demo data and for the tests.
closesodoo/odoo#139594
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Task Description
o-spreadsheet now allows to insert images in a spreadsheet, and
we also allow to export them inside .xlsx file. However, while this
works as intended in a standalone o-spreadsheet server, it doens't
work correctly in Odoo as the data of the image are not found while
we try ton convert the spreadsheet to an xlsx file. This PR aims to
simplify the request made to get the binary data of the image file.
Related task
closesodoo/odoo#139549
Task: 3524473
X-original-commit: 301a98c
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
The onchange on the stage_id/project_id wasn't triggered when modifing tasks in batch
we are now putting the same conditions as the onchange but in the task write() method
closesodoo/odoo#139491
X-original-commit: 0accffc0eb65f40e44d31402a0a362abaaa9b9bd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Now that some field attributes like invisible are given by Python expressions
and that those can involve some set operations, we have to ensure that
the views can be validated if they use such operations. We do that and
add a test.
closesodoo/odoo#139451
Signed-off-by: Géry Debongnie <ged@odoo.com>
Now that some field attributes like invisible are given by Python
expressions that can involve set operations, we want to be able to easily
edit those expressions in the expression editor. For this we have to
improve a bit the mapping expression <-> condition tree, in order to
have simple rewrittings like
"set(user_ids).intersection([1, 2])" <-> condition('user_ids', 'in', [1, 2]).
Part-of: odoo/odoo#139451
svs-odoo