Currently, users are blocked from downloading the UBL file if the partner
or the company are missing Peppol EAS and Peppol Endpoint fields.
The checkbox is not visible and even if it was visible, the user would
see a UserError asking to fill those values.
Let users download these files but show a banner warning about missing
fields.
closesodoo/odoo#159553closesodoo/odoo#160035
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
The issue:
A new fix has been introduced to solve the mimtype issue with creating an XML file: https://github.com/odoo/odoo/pull/124507
since the attachment create_uid now is the SUPERUSER_ID, when a user with the accounting role (not admin) tried to register a payment on any account.move type (invoice, credit note...) an access error is thrown
The fix:
remove the unused attachment as sudo
opw-3787008
closesodoo/odoo#159985
X-original-commit: 60dd56bf3f67cc944918ad4c23fa1ef5f2036e55
Signed-off-by: William André (wan) <wan@odoo.com>
Currently we assume that all imported invoices are incoming (i.e. bills).
This was i.e. done since the tax agency only sends users bills.
But some clients import invoices from other software (i.e. onboarding/starting).
After this PR we decide whether the invoice is outgoing or ingoing and
import the invoice correctly in either case.
task-3650355
closesodoo/odoo#159889
X-original-commit: 292521ddd566cd3d49df2dd2eb4e2850dc47620a
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
Currently there is the following problem when reloading the chart.
Journals without xmlid may not be matched to chart data correctly
(via code or name).
This then leads to duplicate journals being created / uniqueness
constraint issues on journal codes.
The matching happens in `_pre_reload_data`.
This should only be a problem for upgrade or user created journals
since journals created from the chart data have an xmlid.
The problem was introduced in commit d6695f2892ded178371f6c69cf594037c19ce438 :
(1) We load the chart data in en_US to be able to use the code translations
(2) We switched the language of the loading process to en_US
(to switch the chart data to en_US for the previous point and to
avoid inconsistencies)
When matching journals in the DB by code or name to the chart data:
- We fetch the en_US name of the journals in the DB due to (2);
Code is not translatable.
- We compare those values (journal code / name) against the en_US term
due to (1).
Thus the matching fails.
This commit improves the matching:
We also compare the name and code (still en_US version)
against the translated values.
closesodoo/odoo#159871
X-original-commit: 005ebd59cba6b6ca20c736c46d89259af8bd251a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Sven Führ (svfu) <svfu@odoo.com>
- Add new tax groups for VAT at 5%, 13%, and 15%
- Add taxes of 5% and 15%
- Archive VAT taxes of 5% in sales and 12%
- Configure tax group accounts for the new tax groups
- Add new foreign account tax position tax template at 15% VAT
- Add default company configuration for sale and purchase taxes, with new 15% tax
closesodoo/odoo#159596
Related: odoo/enterprise#59788
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit:
Modifying a location from/to a scrap location should be restricted when
there are move lines with reservation. However, starting from Odoo 17,
the quantity field indicates the reserved quantity only when the move
line's state is different from done.
After this commit:
Only check if there are reservation lines (move lines not in done)
in the location when changing from/to a scrap location to match
the behaviour before Odoo 17.
opw-3815275
closesodoo/odoo#159376
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Steps to reproduce:
- Activate "Storage Locations" in the settings and create a warehouse
- Inventory > Operations > Transfers > Internal
- Create a new internal transfer with a non-zero product move line
- Print the "Picking Operations"
Expected behavior:
The destination of the move should be on the document.
Current behavior:
The report (and hence the printed version) of an internal transfer does
not display the destination of the transfer.
Cause of the issue / fix:
This part of the report is displayed under a `t-elif` condition. However
for internal trasnfers the condition of the `t-if` and of the `t-elif`
are both `true` so that two `t-if` should be used for an appropriate
display of the report.
Note:
Prior to commit 567b8d6, two `t-if` were used.
opw-3797998
closesodoo/odoo#159313
X-original-commit: c59e01f1ed32563da3dd86308bf46a1f2cdb5834
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
This commit updates the parameters passed to the IAP SMS API route
("/api/sms/3/send") to include the DB UUID.
closesodoo/odoo#159714
Task: 3829793
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
In Settings>Inventory>Operations enable "Batch Transfers"
Create a [NonTrackedProd] product:
- Product Type: Storable Product
- Tracking: No tracking
Create a [TrackedProd] product:
- Product Type: Storable Product
- Tracking: By Lots
Make two POs with:
- Prod [NonTrackedProd] qty 1
- Prod [TrackedProd] qty 1
Open Barcode Scanning app
Select "Batch Transfers"
Create a new batch with the incoming transfers from the POs
Set only the [NonTrackedProd] lines as done and validate
Issue: Error will block validation
"You need to supply a Lot/Serial number for products"
The system should let the user validate the operation and create a
backorder instead of blocking the user
opw-3777701
closesodoo/odoo#158330
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
**Issue Description:**
Due to changes in field access rights verification as seen here:
https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/odoo/models.py#L5334-L5345
And the removal of sudo rights for CrmLead:
https://github.com/odoo/odoo/blob/494231e796b562162d3bfb19fc8ce7550657cf07/addons/website_crm_partner_assign/controllers/main.py#L98
Attempting to open a search by domain with the `activity_date_deadline`
field triggers a 403 error:
"You do not have enough rights to access the fields
'activity_date_deadline' on Lead/Opportunity (crm.lead). Please contact
your system administrator."
**Steps to Reproduce:**
1. Install the `website_crm_partner_assign` module.
2. Assign Joel Willis a partner level (via the partner assignment tab in
the `Contact` app).
3. Navigate to CRM, select an opportunity, and assign it to Joel Willis
(using the assigned partner tab in the lead form).
4. Log in to the portal as Joel Willis, navigate to Opportunities, and
click any filter on the activities date `Overdue / today / this week
activities`. This action results in a crash.
**Proposed Solution:**
Since we assume that the domain will always filter opportunities with
assigned to current user, we can:
- Do a first search using sudo with the original domain that might
contain the `activity_date_deadline` field.
- Then do a regular search with the opportunities IDs obtained from of
the first search.
opw-3703583
closesodoo/odoo#154653
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
This error occurs when the user adds a new "Working Schedule" to the resource,
switches to the two-week calendar view, removes all the existing "Working Hours"
lines, and then attempts to add a new line under "Working Hours."
Steps to reproduce:
- Install "resource" module
- Settings -> Technical -> Resource -> Working Schedules
- New -> Switch to 2 week calendar -> Remove all "Working Hours" lines
- Click on Add a line
Traceback: ZeroDivisionError
float division by zero
This commit implements a check for the variable "number_of_days". If the value
of "number_of_days" is zero or not found, the function will return zero.
This ensures that the function behaves appropriately in cases where the number
of days is zero.
https://github.com/odoo/odoo/blob/5177e21aea68959eedc73e0034ed984992392dd7/addons/resource/models/resource_calendar.py#L185
sentry - 5108250957
closesodoo/odoo#159844
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, it is not possible to export sale.report by excel or show the lines.
closesodoo/odoo#159793
X-original-commit: 5d8830cb34f3d34ddc907ad245a4312b18c5c1cf
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
OS: Ubuntu 20.04.4 LTS with nautilus
Browser: Google Chrome Version 123.0.6312.58
- type /file command in knowledge
- select a folder and click on open
- traceback occurs
Before this commit:
When a user attempts to upload a folder using /file command, the
processing begins, but the folder is not actually uploaded because the
`getDataURLFromFile` return promise which is not fulfiled. Additionally,
there is no indication of any warnings or errors during the folder
upload process.
After this commit:
If a user attempts to upload a folder instead of a file using the /file
command, it results in a error message in toaster notification.
task-3690847
closesodoo/odoo#159755
X-original-commit: 0b27ac02e499bf15d9f011beda17ab202c1f7a42
Signed-off-by: Damien Abeloos (abd) <abd@odoo.com>
Current behaviour:
When you generate a Delivery Slip for a list
of kit and non kit products with no backorder,
kit and non kit products get mixed.
ie: there are kit products in the section
"products not associated with a kit"
Steps to reproduce:
1. Create 4 products (K1,P1,P2,C1,C2)
2. Create a Bills of Materials for K1
3. Set Type as Kit
4. Add C1 and C2 as components
5. Create a sale quotation for K1, P1, P2
6. Set the quantity at 4 for all products
7. On the quotation, click on Delivery
8. In Done, put 4 for P1 and 3 for C1,C2,P2
9. Validate and select No Backorder
10. Click on Print, Delivery Slip
11. In the document:
12. P2 is in the kit section (K1)
13. C1,C2 in the "not associated with a kit" section
Expected behaviour:
Only C1 and C2 should be in the K1 section
Only P1 and P2 should be in the
"Products not associated with a kit" section
opw-3568390
closesodoo/odoo#159138
X-original-commit: 5d61d7023b3b0a5e6a47ad71bb12d548c797b5f9
Signed-off-by: Steve Van Essche <svs@odoo.com>
Signed-off-by: Antoine Demany (ande) <ande@odoo.com>
Description:
Adding missing indexes to support most of the searches on survey's
models to avoid seq.scans and non-selective index scans.
Also adding indexes that are inverse to One2many, or dependencies
of compute fields (as those if not indexes will trigger a seq.scan
when the ORM resolves the dependency tree).
If a domain had multiple criteria, only fields with the highest
selectivity were indexed. This shall also reduce the amount of tuples
returned, reducing IO access and cache trashing.
Cardinality:
survey_survey -> X (reference quantity)
survey_question -> 10X
survey_question_answer -> 50X
survey_user_input -> 330X
survey_user_input_line -> 7200X
Reference:
task-3724844
closesodoo/odoo#158136
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Test 'test_unpack_and_quants_history' may fail with error
```
ERROR: StockQuant.test_unpack_and_quants_history
Traceback (most recent call last):
File "/data/build/odoo/addons/stock/tests/test_quant.py", line 926, in test_unpack_and_quants_history
dst_location = stock_location.child_ids[0]
File "/data/build/odoo/odoo/models.py", line 6189, in __getitem__
return self.browse((self._ids[key],))
IndexError: tuple index out of range
```
closesodoo/odoo#159779
X-original-commit: 87e53b1d8e2e3ac6b8ddb514a8311b622adac366
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this PR, the chat bot would stop after redirecting
a user on the same page that the current one (e.g. anchors)
because it was counting on the page reload that do not occur
in this case. This PR fixes the issue.
opw-3801598
closesodoo/odoo#159769
X-original-commit: 3d7c2b87e59b261a2d3eeceb0c6de012e8b02a2e
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Issue
-----
A term doesn't have a translation available.
Note: no Transifex project associated.
opw-3816657
closesodoo/odoo#159757
X-original-commit: 9a50cdf115e21bf2422ae881c8a367ad8967a13e
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
When sending an SMS via the action from the sale order view
(specifically with sale_subscription), it is possible to specify a
number to send the SMS to. However, if the specified number
is identical to the partner's number (the number of the sale order's customer),
Odoo attempts to send the message twice, resulting in duplication.
[This commit change]
This commit addresses this issue by ensuring that additional numbers
are skipped if they are the same as the partner's number.
[Reproduce]
- Install mass_mailing_sms, sale_management, and sale_subscription modules.
- Add an SMS token to the IAP account.
- Create a contact (C) with a valid phone number.
- Create a new quotation with contact (C) as the partner.
- Go to Actions > "Send an SMS Text Message" (requires the sale_subscription module).
- Do not change the contact number on the pop-up (ensure it matches C's phone number exactly).
- Bug: Odoo attempts to send two SMS messages, with the first being successful and the second resulting in an error.
opw-3596207
closesodoo/odoo#159677
X-original-commit: 131b0eccb00d24f0525a6a541221bfd2c66cb04b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Versions
--------
- 16.0+
Steps
-----
1. Have two companies with helpdesk teams;
2. create a contact associated with company 1;
3. create a contact associated with company 2 w/ the same email address;
4. from this address, send an email to team 2 to create a ticket.
Issue
-----
Ticket is created using company 1's contact.
Cause
-----
When searching for partners associated with an email address, it only
looks at the first one.
Solution
--------
Expanding on e1d50a404516d5b32bf01508423c5a1c880cb304 which prioritized
the current user, further prioritize based on companies matching the
records passed to `_mail_find_partner_from_email`, avoiding potential
access rights errors in multi-company environments.
Also fixes a bug in account_move where `_mail_find_partner_from_email`
was called with an `extra_domain` argument in the wrong position.
opw-3705199
closesodoo/odoo#159108
X-original-commit: 60dd5348179c9bdcc78e4ad46bd9b768a6e3ea21
Signed-off-by: Levi Siuzdak <sile@odoo.com>
Steps to reproduce:
- Install 'Subscriptions'
- Enable 'Lock Confirmed Sales' in the settings
- Make a new subscription
- Invoice the subscription
Issues:
The subscription is now locked, this behaviour is not intended.
As confirmed with the PO this settings should never affect the
subscriptions.
opw-3754106
closesodoo/odoo#159652
X-original-commit: b472c9e6f743aa467f7f4851ac95a367b364dfb1
Related: odoo/enterprise#59625
Signed-off-by: Mattis Megevand (mmeg) <mmeg@odoo.com>
Some web_editor test was in "test_website" when it could
have simply been in web_editor.
It is moved there and modified to reuse existing imports and pass standard
web linting rules.
task-3741858
closesodoo/odoo#155704
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When using the `/image` command in the composer, or otherwise uploading a file
the editor should add the attachment to the composer if it is the current model
During a change in js relational models [1] the code was not adapted properly.
This lead to a traceback when using the command inside the composer.
[1]: 218ad8456a
task-3741858
Part-of: odoo/odoo#155704
Currently, attempting to print an unconfirmed Saudi invoice in foreign
currency results in an error. Furthermore, even if the invoice is
confirmed, the exchange rate displayed is not correct, the rate of the
confirmation date is used, instead of the accounting date.
Steps to reproduce
------------------
* install `l10n_sa_edi`
* switch to a Saudi company
* create an invoice in a foreign currency.
* without confirming the invoice, attempt to print it
You should be met with a traceback: `Undefined Function: operator does
not exist: date <= boolean`
* confirm the invoice, ensuring the confirmation and invoice dates have
different currency rates.
* print the confirmed invoice.* print the invoice
You should see that the printed rate does not align with the actual
transaction amounts.
Cause
-----
The system incorrectly uses the `l10n_sa_confirmation_datetime` to
calculate and display the currency rate on the PDF. This field is only
populated upon invoice confirmation, leading to errors when printing
unconfirmed invoices. Moreover, using this date for confirmed invoices
results in displaying an incorrect rate, as it may differ from the
`invoice_date`, which should be used for accurate rate calculations.
opw-3731624
closesodoo/odoo#159698
X-original-commit: 67da9437d3606cb8a291c071214cc30914ce7fb0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Issue:
======
The last column in `rtl` direction is connected to it's neighbor column.
Steps to reproduce the issue:
=============================
- Install notes and website
- Change language to arabic
- Go to notes and write `/` and opent eh table picker
- The last column (most left) is connected to it's neighbor
Origin of the issue:
====================
We forced the margin-right of the last cell in the row to have
`margin-right = 0` which is the case for `ltr` but not in `rtl`.
Solution:
=========
Use of `end` and `start` better to handle the direction
(https://developer.mozilla.org/en-US/docs/Web/CSS/margin-inline-start)
task-3825970
closesodoo/odoo#159643
X-original-commit: 0d57a30d12775d8c0ecdb6c3fab5ce191d3f2ccc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Issue:
======
Table picker isn't intuitive in rlt language and doesn't expand in the
correct direction.
Steps to reproduce the issue:
=============================
- Install arabic language
- Go to notes and create a new one
- Write `/` and choose table
- Use left/right arrow keys to see how the table expand.
Solution:
=========
For rtl direction it's better to make left for increase and right for
decrease since that's the direction of the langauge. Also the table
should be fixed on the right and expand on the left. (exactly the
opposite of ltr direction).
task-3721794
X-original-commit: 9d4c937e67cb72ff7152e01cda23255bf3c4d344
Part-of: odoo/odoo#159643
Add a test for exporting the source terms of modules.
This will allow automated scripts to fetch latest terms
Backport save_test_file with a parameter on date_format to have
predictable filenames
closesodoo/odoo#159373
X-original-commit: e7246ea48828746471a2e3a485bee30687eeee80
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, a logger exception is generated when the user tries to upload
any image as document in the mass mail.
This is because an UnidentifiedImageError occurs when the user uploads
an image file as a document and code [1] tries to open it with Image.
This commit adds code that handles an UnidentifiedImageError, and it adds
the message in the log for an invalid image file.
[1] - https://github.com/odoo/odoo/blob/029b84f3c061f819bacb9a4818504cced4adeb1c/addons/mass_mailing/models/mailing.py#L1405
sentry-4311184876
closesodoo/odoo#159653
X-original-commit: e4b7ec191fc81ec806736758f273e20b6260bbeb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: ANSARI MAHAMADASIF (maan) <maan@odoo.com>
In 8e3283aa we solved the issue of onboarding progress records
preventing the deletion of a company. We also added a test for this
solution.
In practice, it will not always make sense nor will it be allowed to
delete a company and in some cases, the first thing that would fail
is a foreign key from another model where it wouldn't make sense to
cascade as we do for onboarding progress.
Some modules create related records when a company is created such
that it would be cumbersome to bypass that.
Therefore, we disable this test until a clean flow robust to all
sorts of installed modules configuration is implemented.
See runbot 60475
Task-3829936
closesodoo/odoo#159679
X-original-commit: ea215fe59b45a0c4ff29b4defb38f9ae91a6ca37
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
Brazilian phone numbers are not managed correctly
following the 2016 changes in Brazil.
(Adding a 9 to mobile phone numbers)
Fix:
Patched the phonenumbers library, adding a 9
at the right place for mobile phone numbers.
opw-3694150
closesodoo/odoo#159641
X-original-commit: a4f884456180769e0e7db7152d40ddcfb497b090
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The method `_get_reward_values_free_shipping` assumes there is only one
delivery line per sale order. But it is not always the case. This commit
therefore makes sure the method does not raise an error in case of
multiple lines by taking into account only the first delivery line.
Fixes#136395closesodoo/odoo#159584
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#158844
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Addresses the issue where reapplying an already applied coupon
in the website shop led to the disappearance of the discount.
With this fix, the discount remains applied, and the system
continues to inform the user that the coupon has already been
used, preventing confusion and maintaining consistency in the
discount application process.
task-3621246
closesodoo/odoo#153485
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. A traceback appears when loading
a website form containing a field dependent on a date(time) field.
This traceback occurs because when checking the value of an empty
date(time) field (which happens when the user hasn't yet filled out the
form), we parse the field value into a Date(Time).
Before the changes in commit [1], we parsed this differently, which
didn't crash but returned "NaN" with an empty date(time) field.
In this commit, we now check whether a date(time) is valid and if not,
we now assign it "NaN" to maintain exactly the same behaviour as before
the commit [1]. Any value other than "NaN" would not work with the date
comparison system and would break certain conditions.
This commit also adds steps to the "website_form_editor" test tour so
that it fails without this commit.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
closesodoo/odoo#158288
Signed-off-by: Robin Lejeune (role) <role@odoo.com>
Since commit [1], the "tempusdominus" date(time) picker has been
replaced by the OWL date(time) picker. This change resulted in a
modification of the HTML structure for date(time) input fields.
Consequently, a bug emerged in the visibility options for fields reliant
on a date(time) field. Specifically, the time condition selector failed
to display the time conditions because they are rendered based on the
HTML structure of the fields.
Since the code was not adjusted to fit the new structure, this
functionality stopped functioning.
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628
task-3790809
Part-of: odoo/odoo#158288
Steps to reproduce:
- Remove all permissions to write/create/delete a view for the user "demo"
- Open a view form with "demo" user
Actual result:
- View code is displayed in plain text and with formatting
Expected result:
- View code is displayed with formatting only
- You can't edit the view or the translations
opw-3776073
closesodoo/odoo#159592
X-original-commit: a1f4e3de224d91e49d5adb2a6385d76c3282d206
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
This commit's purpose is to display the correct currency for the hourly
cost of employee in the project sol mapping.
Currently, the currency displayed is the one of the sol instead of the
currency of the employee. This is due to this commit:https://github.com/odoo/odoo/commit/83760b9f10b4bfe6a83671e4426bc5596e8d5f5c
We added a monetary widget, but we are feeding it the wrong id.
After this commit, the correct currency is displayed
closesodoo/odoo#159588
X-original-commit: 8603d628bfc5c7dc620333ad674a1afb7b7123d1
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
1. Fixes an issue where the parent product wasn't correctly set when
computing the routes of a component, leading on components from
subcontracted products displaying the wrong route (as it was trying to
resupply the selected warehouse instead of the subcontracted location).
2. If a route is found when searching for subcontracting routes but
doesn't lead to a way to resupply the stock (either buy buying or
manufacturing something), then ignore the found rules and revert to the
default of trying to resupply the stock location.
This avoids issue when using reordering rules to resupply the
subcontracted location instead, where the 'Buy' route would be hidden
even if it was selected.
closesodoo/odoo#159516
X-original-commit: c7b84a4a602f72c7a67144b7a81b38afe36e0eee
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, the custom attribute names were not correctly
displayed when added to an order.
opw-3795843
closesodoo/odoo#158805
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
- Instead of raising an error, we simply exclude sub-tasks of the current
task from the domain of the 'parent task' field
task-3584963
closesodoo/odoo#143282
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Steps to reproduce:
- In 'project sharing' create a task T in project A.
- Add 2 subtasks to task T in project A.
- Share project A in edit mode.
- Access the view form of task T as a portal user.
- Click on the subtask button to navigate to the tree/kanban view of subtasks.
- Select the kanban view.
- Create a new task on the fly, resulting in a traceback.
Issue:
- When a portal user creates a new task on the fly from the subtask kanban view,
a traceback occurs, and the expected behavior of creating a new task Y in
project A is not met. Additionally, task Y should not be a subtask of task T.
Solution:
- Resolve the traceback issue when creating a new task from the subtask kanban
view as a portal user in project sharing.
- Ensure that the new task Y is correctly created in project A and is not
set as a subtask of task T.
task-3584963
Part-of: odoo/odoo#143282
Steps to reproduce:
- Access the 'project.task' module.
- Create a subtask.
- Attempt to save the subtask after adding a project to it.
Issue:
- Saving a subtask becomes impossible when a project is added, causing an
obstruction in the process.
Solution:
- Rectify the functionality to enable successful saving of a subtask even after
adding a project, ensuring a seamless process for subtask creation and
association with projects.
task-3584963
Part-of: odoo/odoo#143282
Replace the use of 't-esc' with 't-field' for the payment icon image in
the icons list template. The latter, for an image field, provides two
options for rendering the payment icon image: use the PIL library to
obtain the image when given the option 'qweb_img_raw_data', or use a
URL. The former only considers the first option, allowing only image
formats compatible with the PIL library.
closesodoo/odoo#159586
X-original-commit: bc76cca37504b40eac73190363c452f89dca65ed
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
When some clients are upgrading their databates and reconnect their IoT Boxes to the new version of the database, we currently can have an issue where the old iot handlers are not being overwritten, but the new ones are being deleted.
This happens in situations like where we add a new driver distinction in Windows, so its name "SomeDriver.py" becomes "SomeDriver_W.py".
Since we dont delete SomeDriver.py the IoT can have both drivers in such situations, causing conflicts and unwanted behaviors.
The goal here is to delete all the old drivers and interfaces before downloading the new ones to make sure we don't have this issus
task-3729890
closesodoo/odoo#159538
X-original-commit: 53a04406e6563d141b7b2378dc25b29b8a8086d6
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
aliya