Only delivery carriers that can communicate with the outside should be deactivated.
Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated.
Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases.
@moduon MT-5612
closesodoo/odoo#161182
X-original-commit: bdaeae0230fe0da7743f8cc4ed9dcb210b994540
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Issue:
- when creating an accrual plan based on attendance,
the duration is not computed accurately when allocating.
- the computation is not correct if you select a different
start date in the allocation without emptying the field "Allocation"
Steps To Reproduce:
- In the time-off app create an accrual plan: where employee
accrue 1h for every hour worked based on attendance.
- In the attendance app create a new attendance for 8 hours.
- add a new allocation to Mitchell Admin with the plan you created.
- Change the date on the validity period, new allocation is 8h.
- change the date again and notice the Allocation not computed correctly.
Solution:
- In `_onchange_date_from` when simulating how many days an
accrual plan would give from a certian `date_from` we don't reset
`number_of_days` to 0. reseting it to 0 fixes the issue.
opw-3793961
closesodoo/odoo#160696
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
We add the following demo data:
-Invoices, credit and debit notes, both from customer and supplier
-Examples of rates
-Data from Uruguayan partners
We also adjust demo data of the company.
closesodoo/odoo#145112
Ref: ADHOC 34810
Ref: LATAM 1132
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
This commit fixes an issue about the search panel content being cut in
some accounting interfaces. This is due to the fact that the searchpanel
with a specific class would get an arbitrary width value in px.
To avoid this issue, we set a `w-auto` to the searchpanel, allowing it
to adapt its width to its content.
task-3560617
closesodoo/odoo#161382
X-original-commit: f90339c0c6fc27bab7e21d2e78bec043f6327146
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
The test test_tz_legacy will fail if the taget does not exist on the
operating system. This is breaking in some versions of the tz-data
package. Don't make this test fail if the target is missing.
closesodoo/odoo#161341
X-original-commit: 276eb0192fdddb736453857c18bf9f0cccecb4a3
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce issue:
1. In settings, activate Timesheets
2. Go to _Project > Tasks > All Tasks_
3. Create a new task
4. Give the task a title
5. Choose an Assignee
6. The title disappeared
Explanation:
The title field, `display_name`, is a computed field that gets its value from `name`. This compute has dependencies coming from other computed values. Those dependencies lead to other dependencies up to `project_id`. Because of it, changing `project_id` will trigger `_compute_display_name`.
Suggested fix:
Backporting odoo/odoo@8178ad79bb, the cause of the issue is the same.
opw-3823040
closesodoo/odoo#161276
X-original-commit: 89b1ff812ecd4186f2196341d72fe7e6380404dd
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
Before this commit, users could not disable the Terms and Conditions display on the product page from the Customize tab of the web editor. To remove it from the product page, the only workaround was to remove the text in that div.
Now, a button will be available in the Customize tab of the web editor to quickly show or hide the Terms and Conditions.
closesodoo/odoo#161354
Forward-port-of: odoo/odoo#161230
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
`_UNSAFE_ATTRIBUTES` was changed from a `list` to a `set` in odoo/odoo#151989.
odoo/odoo@cde2781591
Reset it to a `list` as before, by retro-compatibility concerns,
in case developers used features not working on `set`.
For instance:
- `_UNSAFE_ATTRIBUTES.append`
- `_UNSAFE_ATTRIBUTES.extend`
- `_UNSAFE_ATTRIBUTES + ['foo']`
The opportunity is taken to add `_co_code_adaptive`,
which is a new attribute added from Python 3.11,
hence available from Ubuntu Noble.
Firstly added as `_co_quickened` in
https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7b153de6cdd
Then renamed to `_co_code_adaptive` in
https://github.com/python/cpython/commit/2bde6827ea4f136297b2d882480b981ff26262b6
The opportunity is also taken to move `mro` out of the `Python 2 functions` section,
as `mro` is available in Python 3, hence making the comment confusing.
Part-of: odoo/odoo#151989
Before
======
In E-invoice Value is pass as other values
After
====
No RC value is pass to the E-invoice because not required to pass RC value.
closesodoo/odoo#161125
Signed-off-by: Josse Colpaert <jco@odoo.com>
Description:
Add indexes affecting queries related to `account.analytic.line`.
Based on heuristics like domains in `search`/`read_group` that are
not really selective, or being an inverse of One2many.
Some of these searches are on code-paths that are frequent, like
creation of an SO.
The goal is to reduce the number of Seq.Scan or non-selective Index
Scan.
Reference:
task-3724844
closesodoo/odoo#160472
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Have a form view that has twice the same x2many field, excpet the first one is invisible=1.
The second occurence has a context with the form_view_ref key.
The x2many should have at least one record.
```xml
<form>
<field name="x2m" invisible="1" />
<field name="x2m" context="{'form_view_ref': 'some_ref'}">
<tree>
<field name="display_name" />
</tree>
</field>
</form>
```
When opening a record, the context was not taken into account, yielding the wrong form view to open that record.
After this commit, the form_view_ref context key is taken into account, and the right form view opens.
opw-3845448
closesodoo/odoo#161253
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current Behavior:
The description of the "Interviewer" access rights is the following:
"Interviewer right will give access to all job position/applications
where the employee is defined. It will allow to refuse, plan meetings.
**Chatter content will not be available.**"
However, the "interviewer" users have access to the chatter as no
sensible content can be accessed from it.
> The description therefore needs to be updated.
Note:
This access right did not exist before saas-16.4
opw-3783965
closesodoo/odoo#161197
X-original-commit: eb2facc88701ca7deaa02947ee9e6c30687c0588
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Configure an email alias for the journal 'Vendor Bills'
Send to the mail alias two pdf bills
Issue: Only 1 record is created with the 2 bills as attachment
The system should split the bills into separate records, but this does
not occur:
- after the first bill is processed the current move extract_state is
'waiting_extraction'
- when the system check whether to extract data from the second document the
result is negative as it check the state of the first document
opw-3822262
Co-authored-by Andrea Grazioso <agr@odoo.com>
closesodoo/odoo#160983
Related: odoo/enterprise#60168
Signed-off-by: William André (wan) <wan@odoo.com>
Since commit [1], we can now drag and drop an image column by dragging
it directly, and not only by the move handle. Commit [2] allowed the
image to be dragged from anywhere and not only from the top middle.
However, since commit [2], it is really difficult to drag a column
downwards in a grid, if the drag started from the bottom move handle or
near the bottom of the column if it contains an image, because we easily
get out of the dropzone.
Indeed, since the positioning of the column now takes into account the
mouse position on the column where the drag started, the mouse cursor is
therefore located under the column (or almost under in the second case).
This is why it gets out of the dropzone before a new row could be added.
For the second case, new rows can be added, but only if the drag is slow
enough, which is not convenient.
This commit bounds the vertical position of the mouse when dragging, in
order for it to always be considered inside the column, so it cannot
escape the dropzone anymore. A safety margin of one grid row is
considered, to not escape when dragging rapidly.
Steps to reproduce:
- Drop enough snippets to have a scrollbar or select the "Sidebar"
header template.
- Drop a "Text-Image" snippet
- at the top of the page if the header was changed at the previous
step, or
- at a place where the top of the snippet can be hidden with a scroll.
- Toggle it to grid mode.
- Start dragging any column with the bottom move handle or drag the
image column by clicking near the bottom of the column.
- Go over the grid dropzone if the move handle is used.
- Drag towards the bottom of the grid.
=> The mouse easily gets out of the dropzone, making it impossible to
add new rows and drag further down the grid.
[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9
task-3601336
closesodoo/odoo#144427
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Since commit [1], we can now drag and drop an image column by dragging
it directly, and not only by the move handle. Commit [2] allowed the
image to be dragged from anywhere and not only from the top middle.
In grid mode, in order for the column to stay well inside the grid when
dragging, its computed position was originally bound horizontally, to
the left and the right of the row. With commit [2], it is now also bound
vertically, to the top and the bottom of the row.
While it makes sense for the top, because we need to take into account
from where we dragged the image, it should not have been the case for
the bottom, as we need to overflow in order to add new rows. This
resulted in the drag towards the bottom becoming jumpy, because it locks
on the bottom of the grid until a new row is added, when the mouse
pointer is down enough.
This commit removes this bottom bound, in order for the drag towards the
bottom to be smooth again.
Steps to reproduce:
- Drop the "Text-Image" snippet and toggle the grid mode.
- Drag a column towards the bottom in order to add new rows.
=> It is not smooth: it locks on the bottom of the grid.
[1]: https://github.com/odoo/odoo/commit/cff6f79b5f38239be8a498ff03549ad9a5deebae
[2]: https://github.com/odoo/odoo/commit/514d3dbad4d20db375cba634b6af68a4fb0cafe9
task-3601336
Part-of: odoo/odoo#144427
Before this PR, the chatbot script would hang when redirected to a
page where the chatbot is not enabled.
When such a scenario occurs, we should restore the chatbot's state to
where it stopped, and the script should continue.
This PR fixes this issue.
task-3625853
closesodoo/odoo#161121
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Prior to this commit, the tour service would fail to observe changes
in the tour's shadow DOM after the tour was resumed.
A mutation observer waits for the shadow host to appear in the DOM,
then registers it with the macro engine observer in order for the
macro engine to take shadow DOM modifications into account.
This commit ensures that the same logic is applied when resuming a
tour.
Part-of: odoo/odoo#161121
Steps to reproduce the bug:
- Install e-commerce.
- Open a product page in edit mode.
- Click on the "product.description_ecommerce" field.
- Bug: an infinite loop starts. The "selectionchange" event is triggered
in an endless loop, causing various issues such as the page freezing
after a while.
This issue was introduced by this commit [1].
Since this other commit [2], when a selection itself is the main
container of the editable area, we replace this selection to only
include the content of it. With commit [1], this has been modified to
take into account "oe_structure" and "[contenteditable]" elements. As
these elements can be empty, clicking on them would reselect them,
creating an endless loop since we'd never leave the condition that
replaces the selection.
[1]: https://github.com/odoo/odoo/commit/e93fa23c29421ffe8917d9650330585d6dad210f
[2]: https://github.com/odoo/odoo/commit/10c5a16cd44b8d8e54082df90166f2309dfa788d
task-3830033
closesodoo/odoo#160535
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add support for the Malaysian Peppol PINT specialization,
allowing to generate the related XML file.
This also adds a few additional features that are in the
specifications:
- SST registration number, needed in the xml and on the
invoice.
- TTx registration number, needed on the invoice.
Both numbers are optional, but if the business is registered
in any of them they are required to display these on the
invoices and they are required to enforce some rules. (cannot
send taxes that are not 0% "Out of scope" if not registered with
SST, ..)
Task id # 3647922
closesodoo/odoo#159407
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
The logger show "Job done" before the flush. But if during the flush an
error appear (sql constraint, validation error during computed field,
...), the log contain "Job done", but is not True.
The time to compute the cron is not good because it doesn't contain the
flush time.
closesodoo/odoo#161204
X-original-commit: 0cde9c7238ece225ebd50c50f4a78d16ac6b5226
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit the time to unlink an account.move can take lot of time (60s on large database).
closesodoo/odoo#161172
X-original-commit: 73c1fdd192577bba56dcad213d8a22de8b5de06f
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Outlook and similar Windows based systems use windows-874 for encoding
Thai characters which is not natively known by Python.
Simply aliasing the Windows encoding as cp874 adds support for this
encoding.
opw-3684161
closesodoo/odoo#161117
X-original-commit: 65d4c2507e762dc273a02a2e2215c49a5976568d
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
Add missing indexes on stock.move and mrp.workorder
to speed up search_read on mrp.production. That's mostly
useful at the opening of the Shop Floor app.
closesodoo/odoo#160349
Related: odoo/enterprise#59998
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
due to the absence of IR model data entries for certain
account taxes, but with identical tax names, tax types,
and scopes, attempts to create standard taxes with the
same names alongside IR model data result in a constraint
violation, specifically, "tax name must be unique." To address
this constraint, we append "old" to the tax name for existing
taxes lacking IR model data entries.
see:
https://github.com/odoo/odoo/blob/740fb9ac8c8e121820feeac0e1f25a304e47da9d/addons/account/models/account_tax.py#L202
```
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4864, in _create
records._validate_fields(name for data in data_list for name in data['stored'])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 1456, in _validate_fields
check(self)
File "/home/odoo/src/odoo/17.0/addons/account/models/account_tax.py", line 201, in _constrains_name
raise ValidationError(
odoo.exceptions.ValidationError: Tax names must be unique!
```
closesodoo/odoo#161146
X-original-commit: 87e13a0f29ace57f1fd591d7180a64bb085a3bca
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Add the same tag to 13 different blog posts.
- On the "Blog" page, click on this tag to filter the blogs.
-> Problem: the result displays "12 Articles" but they are actually 13.
In this case, the result displays "12 Articles" as they are 12 articles
on the current page. When going on the second page of the results,
"1 Article" is displayed. This problem is solved by displaying the total
number of articles found after the filtering operation rather than the
number of articles on the page.
opw-3802729
closesodoo/odoo#161137
X-original-commit: 4e90dc9096cbcf9f2fe7f251b247c8d62bc0bc5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Colin Louis (loco) <loco@odoo.com>
Before this commit, when the user created a new quotation from
Contact->Opportunity-> ("New Quotation" or "Quotations/orders widget
button", archived records could be added to the quotation
(e.g. ,product, taxes...) because the context was set to
active_test = false. After this commit, the context is configured back
to active_test = true when creating a quotation from opportunity.
opw-3802796
closesodoo/odoo#161087
X-original-commit: 3085c3b24bef719c3cf63ec9d3b5a7d7b2a34037
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When user tries to empty start date or end date in website using editor,
a traceback will appear.
Steps to reproduce the error:
- Install "website_event"
- Go to Website > Events > Open any Event > Register > Edit
- Now try to empty start date or end date > Save
Error: A traceback appears:
"TypeError:'<' not supported between instances of 'bool' and
'datetime.datetime'"
https://github.com/odoo/odoo/blob/4759c6d1ee09c32381dc56c59c95949fd0e2807c/addons/event/models/event_event.py#L507
Here, When user tries to empty start date or end date,
start date or end date will become "False",
So it will lead to the above traceback.
solution:
A try-catch is used to catch typeerror at write of qweb fields.
sentry-5038057541
closesodoo/odoo#161083
X-original-commit: c893ff16e277b46796a943c5532e01e8edf8958f
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Renilkumar Kajavadra (reka) <reka@odoo.com>
Currently, there is an access right problem concerning timesheet. The
module mrp gives write access to portal user on analytic line, but it is not
something we want for the project app.
step to reproduce:
- install hr_timesheet on a saas-16.3 db
- go to project app, open office design
- select any task, and add a subtask to it
- go the the view form of the subtask
- create a new timesheet for this subtask
- go back to the view form of the parent task
a button 'subtask timesheet' is now visible
- share the project in edit mode with a portal user
- connect with that portal user
- open the office design project
- go to the view form of the parent task and click on the button
- the user is redirected to a view tree with the timesheet of the
subtask
this view tree is editable
Source of the problem:
in the mrp module, the access rights of the analytic line is overwritten
to give write access to it to portal user.
Soluce:
We have to make the view in readonly mode for timesheet when the
connected user is a portal one. Unfortunately, it is not 100% possible
because setting the field to readonly still gives the user the
opportunity to click on those fields (which triggers access errors). So
we have to create new views and specifically open those views when the
user is a portal one.
affected version: saas-16.3 - master
task - 3751315
closesodoo/odoo#160959
X-original-commit: 7b733f118f60ff98d9f82c69453187d70e6bece0
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
The sale_stock module patches the ProductCatalogKanbanRecord updateQuantity method
to prevent the quantity to go under the delivered quantity of the product
The issue is that we are also using the ProductCatalogKanbanRecord in the industry_fsm_stock module
in which the services product added to the sale order are considered by default but we would like to be
able to dimish their quantity in the catalog (in case of a missclick for exemple)
Since the service product can't be considered delivered in sale modules, the condition in updateQuantity
shouldn't change anything
Task-3689939
closesodoo/odoo#155157
Related: odoo/enterprise#55455
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps:
Install web_studio
Change language to French
Open any form view and enable Studio
Add a datetime field and click on it
In french we have the following message:
"Première date acceptée": Date formatée ISO ou "aujourd'hui" He says that we can use the string "aujourd'hui"
when we only expect "today" in English.
This commit changes the help text to display "today" in every language
opw-3829954
closes odoo/odoo#160904
Forward-port-of: #160144
Forward-port-of: #159654
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Steps:
- Install sales app.
- Go to settings of sales.
- See header field there is no download button.
Issue:
- Binary field should have download button and
user should be able to download file with out
issue.
Cause:
- Since Settings is abstact model so it does not
contains id field in it and download button visibility
depends on id field.
Fix:
- Extend binary field for setting view to get proper
file from related field where actual file is stored.
task-3620555
closesodoo/odoo#160070
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This module was introduced in saas-16.4. In that version the sale
order report and portal template displayed both price_subtotal and
price_total for each sale order
line. 655d375af8 removed price_total.
Because this module removes price_subtotal we end up with no line
total at all on the default Brazilian quotation PDF and portal
view (just 3 columns: description, quantity and unit price).
Loosely inspired by l10n_cl [1], this commit changes our approach to
turn the two places where we use price_subtotal into price_total. The
aforementioned commit also changed the heading of this column from
"Subtotal" to a more generic "Amount", so there's no inconsistency
there. Although this is a bit of a mess, I can't think of a better
solution.
[1] https://github.com/odoo/odoo/blob/655d375af83dd49bbbd5f5818e319c3b0e9778c1/addons/l10n_cl/views/report_invoice.xml#L173-L175closesodoo/odoo#159794
Related: odoo/enterprise#59703
Signed-off-by: Josse Colpaert <jco@odoo.com>
Fix various "Using variable xxx before assignment". It was not detected
by pylint <= 2.5.0 which was the version enforced on runbot.
closesodoo/odoo#160886closesodoo/odoo#161166
X-original-commit: 328a0ce2fa619376672c591d8b4f8892aaa2da1a
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fixes the 'og:site_name' metadata, which previously
defaulted to the company name (see [1]), causing issues for multi-site
setups. Now, the metadata actually uses the site name.
Steps to reproduce:
- Navigate to any page
- Right-click and select "View Page Source"
- In the <head> section, observe the meta property "og:site_name" set to
"MyCompany".
[1]: https://github.com/odoo/odoo/commit/156955de6b4e6288ac606d29b843081842154eff
opw-3791082
closesodoo/odoo#161123
X-original-commit: 24ea3ca4b12f8dd4103a650436a144e776b81d83
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
To reproduce the issue:
-Drag and drop the rating snippet.
-Change the score from options.
-Notice that spaces between icons disappear.
In the release notes[1] of jQuery 3.5.0, it's stated that security
fixes related to the HTML parser were implemented. Consequently,
self-closing e.g. `<i/>` tags inside function arguments were replaced
with e.g. `<i></i>`. As a result, trailing spaces lost significance,
causing icons to stick together.
Before the commit:
Prior to Odoo 16.2, jQuery 3.3.1 was utilized, which allowed the use
of self-closing tags in the append function. This behavior was as
expected.However, starting from Odoo 16.2, jQuery version 3.6.3 was
adopted.
After the commit:
Instead of using self-closing `<i/>` tags, `<i></i> ` with a trailing
space was used. This trailing space gained significance due to the
prefilter no longer ignoring it. Consequently, icons no longer stick
together after changing the score.
task-3576760
[1] https://blog.jquery.com/2020/04/10/jquery-3-5-0-released/closesodoo/odoo#161076
X-original-commit: b897e836697a288bbd58a8efc340d9f7b2e76e30
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This ensures that the user will not click on the confirm button before the record is saved which will prevent unnecessary UserError if the Timeof type requires no validation
closesodoo/odoo#160839
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
When writing in a discuss channel, the updated value sent to the client
should be read from the database, not directly from the values passed to
the write method.
Partially backport of https://github.com/odoo/odoo/pull/139563closesodoo/odoo#158860
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When the user adds a valid Mauritius phone number, it is not correctly parsed by
the phonenumbers library, resulting in a user error while sending a WhatsApp
message to that number.
Steps to produce:
- Create a new contact with the Mauritius country selected.
- Add a phone number (e.g., '+23057654321').
- Try to send WhatsApp messages using this phone number.
- This will throw an Invalid number error.
Problem:
`phonenumbers==8.12.1` python library is used in odoo for parsing phone numbers.
The `8.12.1` version is too old and cannot parse Mauritius phone numbers
correctly.
Solution:
The `8.12.13` version accurately parses Mauritius phone numbers. Currently, The
latest version of the phonenumbers library is `8.13.31`. Hence, the latest code
from the latest version of the phonenumbers library is monkey-patched into the
system.
Task - 3799632
closesodoo/odoo#161039
X-original-commit: c3743b5fcfb5d67c442e5eee9f084b684e4baac3
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before when we create an expense report paid by company with multiple expenses of different dates then we posted the expense report. The journal entries had all the same date.
Now journal entries will match the date of the expense when it is an expense paid by company.
closesodoo/odoo#160990
X-original-commit: 77d53dd3d62016f97c19645b42c772204babdd45
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Logan Staelens (lost) <lost@odoo.com>
When creating a product document, it was still possible to save
something that wasn't a pdf. The check only happened when modifying it.
opw-3802795
closesodoo/odoo#160879
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce:
-------------------
- create a time off accrual plan with:
- cap accrued time equals to `True`
- maximum leave equals to `0 days`
- create an allocation with this accrual plan
- run the scheduled action "Accrual Time Off: Updates the number of time off"
(make sure you have the right "lastcall" and "nextcall")
Issue:
------
The number of days of the allocation is set to zero.
This scenario makes no sense from a business point of view.
In effect, we are blocking the accumulation of allocations at zero.
The result is that there will never be any days allocated to these allocations.
Solution:
---------
Add a constraint to force a maximum leave number
when cap accrued time is set.
opw-3847408
closesodoo/odoo#160626
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
When a register payment is made with a writeoff in foreign currency
and when the user set manually an exchange difference account,
don't create a write-off. Instead, 2 cases to consider:
- When the payment is expressed in a foreign currency different than
the invoice's one, play with the rate between amount_currency and
balance and let odoo making an exchange difference accordingly.
That way, the payment has no write-off and the invoice is fully paid.
- When the payment is expressed in company currency but the invoice
has a foreign currency, force the exchange difference to use a rate
that will fully paid the invoice without creating any write-off line
on the payment.
task_id: 3717436
closesodoo/odoo#157398
Related: odoo/enterprise#58511
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
* Current Status
- when remove attachment or message, The system will perform deletion on
the interface before performing deletion in the DB. However, in some
situations, exceptions will occur during the deletion process. So it
will happen that the attachment or message has been deleted on the
interface but still exists under the database. From a function that
helps optimize user experience, it will cause a worse situation with
user experience
* Solution
- Make rpc calls before deleting messages or attachments on the
interface
closesodoo/odoo#161023
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this PR, the error displayed in the public page was quite
cryptic. It was hard for the user to understand that error and even
harder to report it if needed. This PR makes the error more user
friendly.
task-3850559
closesodoo/odoo#160947
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce:
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts and create a contact from San Marino:
* Name: SM customer
* Country: San Marino
* Street, City, ZIP: [any]
* Destination Code: [any]
- Create an invoice:
* Customer: [the created contact from San Marino]
* Product: [any]
- Confirm the invoice
- Generate E-invoice XML via "Send & Print" button
Issue:
In the XML, the destination code (i.e. CodiceDestinatario) is the
default one for non-Italian customer (i.e. XXXXXXX).
Also, the VAT number (i.e. IdFiscaleIVA) is the default value for
countries that are not in the European Union (i.e. OO99999999999).
However, since October 2021, San Marino should be handled differently
for Italian electronic invoices.
A specific destination code (i.e. 2R4GTO8) should be used for all
customers from San Marino.
Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/
Solution:
For customers from San Marino:
- Keep VAT number
- Set "2R4GTO8" as destination code
opw-3819054
closesodoo/odoo#160494
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In Spain, "Cooperativas" have their own variant of the Spanish chart of
accounts. In order to support these businesses, we add two extra CoA
templates: Cooperatives - SMEs and Cooperatives - Complete.
task-3803050
closesodoo/odoo#159357
Signed-off-by: Josse Colpaert <jco@odoo.com>
Steps to reproduce:
- Install mrp and purchase
- Go to "Inventory / Configuration / Settings"
- Activate "Storage Locations"
- Go to "Inventory / Configuration / Warehouse Management / Operations Types"
- Edit "Receipts" type by activating "Show Detailed Operations"
- Go to "Manufactoring / Configuration / Settings"
- Activate "Subcontracting"
- Create product: (e.g. Product XYZ)
* Product Type: Storable Product
- Create a BoM for Product XYZ:
* BoM Type: Subcontracting
* Subcontractors: [any] (e.g. Azure Interior)
- Create a PO:
* Vendor: Azure Interior
* Products: 2 x Product XYZ
- Confirm the PO
- Open the picking from PO via the Receipt smart button
- In "Operations" tab, set done to 1
- On the picking form, change the destination location (e.g. WH/Stock/Shelf1)
- Save
- In "Detailed Operations" tab, a line should have appeared
- Select the same destination location on that line (i.e. WH/Stock/Shelf1)
- Validate the picking and create a backorder for the remaining quantity to produce
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ (Search Product: XYZ - Group by: Location)
=> The "On Hand Quantity" for Product XYZ is as followed:
* Virtual Locations/Production: -1.00 (correct)
* WH/Stock/Shelf1: 1.00 (correct)
- Open the backorder picking from PO via the Receipt smart button
- Record the production of the remaining unit
- Validate the picking
- Go to "Inventory / Reporting / Locations"
- Check the locations of Product XYZ
Issue:
The "On Hand Quantity" for Product XYZ is as followed:
* Partners/Vendors: -1.00 (incorrect, it should be empty)
* Physical Locations/Subcontracting Location: 1.00 (incorrect, it should be 0.00)
* Virtual Locations/Production: -2.00 (correct)
* WH/Stock/Shelf1: 2.00 (correct)
Cause:
When the PO is confirmed, the stock picking and the stock move are created, they both
have the same source and destination locations.
However, in an overridden method from "mrp_subcontracting" module, a check is performed
on the move to determine if it is a subcontract.
If it is the case, its source location is set to the subcontractor location and so, the
source location of the picking and the move is not the same anymore.
When the destination location is changed on the picking, an onchange is triggering an
update of the destination location AND the source location of the move to the values
coming from the picking, erasing the subcontractor location set on the move.
The issue only happens for the backorder, because the source location update is not
propagated to the stock move lines.
In the case of the original picking, the move lines were already created with the
subcontractor location as source location.
But when the backorder is created, the move lines are created with the values coming
from a move without the subcontractor location.
Solution:
Do not propagate "location_id" from the picking to the subcontracting moves.
opw-3777379
closesodoo/odoo#161011
X-original-commit: e0f7577da1a42512d2fdc5ee316f27a1ce040522
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Emilio Pascual