Steps to reproduce:
- Go to website in "Edit" mode (on a blog post page).
- Select one of the default images in the blog content.
- Click on the "Animation" option and select "On Hover" > Traceback!
Starting from [1], the "On hover" image animation was implemented to be
able to pick an animation that triggers when hovering an image.
This feature is setting a default "Square" shape (required for the
hover effects to work) on the target. Which means that an error can
always occur if the "On Hover" animation option is available while the
targeted image is not linked to an attachment and can't support image
shapes (which is the case here).
The goal of this commit is to fix this issue by only allowing the
"On Hover" animations when it's possible to apply shapes to the image.
[1]: https://github.com/odoo/odoo/commit/7f730f81ec541cc7791fc6b3fded17c838433f85
opw-3795599
closesodoo/odoo#158433
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Since [this other commit], the style indicating the active nav item
stopped working if the user added record pages to the navbar. This was
due to the cache system not being invalidated when switching from one
record page to another.
This commit fixes the issue by disabling the cache for the navbar if
there is a record page in the menu.
Other potential solutions were considered but ultimately rejected:
1. Using the record as a t-cache key. However, this would mean that if
you have 60,000 visible forum posts, you would end up with 60,000
different caches.
2. Activate the correct element using JavaScript. This would lead to a
duplicate logic in the JavaScript and the Python code, and it would
introduces a slight lag to add the active class on the correct nav item
(due to the time it takes to load and execute the JavaScript).
The chosen solution is the best compromise, as it maintains the cache
for most cases (website menu without records page links in it), nothing
change with this commit. For problematic cases (record pages in the
website menu), this commit disables the cache, which is a reasonable
trade-off.
Steps to reproduce the bug fixed by this commit:
- Edit a website's menu
- Add a link to a product page (e.g., customizable-desk)
- Add a link to another product (e.g., chair-floor-protection)
- Save the menu
- Click on the menu link to go to customizable-desk
=> At this point, the active menu element is correct
- Click on the menu link to go to chair-floor-protection
=> The active menu element does not update
This commit fixes the issue (a update of the website module is needed)
and adds a test to prevent regressions.
Notes:
- To see the issue locally, remove the --dev xml or --dev all arguments.
- The same issue was occurring with other record pages (blog posts, ..).
- We will introduce back the groups on menu and benefit from this new
method to also disable the menu cache if one of the menu is linked to
a group. See task-3800830
[this other commit]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
opw-3694651
opw-3750925
opw-3781668
closesodoo/odoo#159006
X-original-commit: 43576cd424b6d0fc7da01142b5e6550e371ad1ff
Related: odoo/enterprise#59321
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Resequencing entries that come from payment and non payment
raise a UserError, even if the journal has `payment_sequence`
set to False
Steps to reproduce:
1) Go to "Accounting / Configuration / Accounting / Journals" and create a new
journal with type "Bank" and "Dedicated Payment Sequence" in False.
2) Create a "Bank Statement Line" in the journal created in step "1".
3) Create and confirm a customer payment using the journal created in step "1".
4) Go to "Accounting / Accounting / Journals / Journal Entries".
Select journal entries created on step "2" and "3" and then click on Action --> Resequence.
Then a User Error is being show "The sequences of this journal are different for Payments
and non-Payments but you selected some of both types." it is not correct as the journal
created on step "1" has the field "Dedicated Payment Sequence" set to "False".
opw-3763500
closesodoo/odoo#159003
X-original-commit: 11d71cf1b244174c12c0094eb2f0f072894aecc6
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
A traceback was spotted when `unserializeNode` was called as a result of
a call to `resetContent`. That traceback could lead to other tracebacks
(including one when trying to read a history step's ID in
`_historyMakeSnapshot`). A traceback at that moment could remove all the
content of the editor before saving.
This commit ensures the argument passed to `unserializeNode` is defined,
that `unserializeNode` returns `undefined` if it couldn't return
anything valid, and that when such is the case the caller handles that
undefined return value properly.
task-3677431
closesodoo/odoo#158957
X-original-commit: bf062140877dabcb6db93d2a4bea2aa36f4b2601
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
This data is used in the chart of account definition and could put
the end user into a bad situation.
Related ticket: 3790614
closesodoo/odoo#158875
X-original-commit: f48c30181e1335ef72c60ca9e7d14b7f4aa42359
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Context:
During the refactor 68fbdc9640,
expense rights were improved but two cases were forgotten.
Before this commit:
1. sudo would not work as the rights were checking the groups
2. system admins were considered as being expense admins too, which may
not be the case if the system admin user changes
and the correct group `group_hr_expense_manager` is not given.
System admins should always be able to edit expenses
when it make sense.
After this commit:
Sudoed and group_system users are considered as expense admins
closesodoo/odoo#158583
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
How to reproduce:
- Install hr_skills_survey with demo data
- As admin, in "Survey", create a simple certification with one question
- Click on share and send it to Marc demo
- As a public user, do the certification through the received link
- As admin, go to "Employee" and got to "Reporting -> Certifications"
- You will see the certification in red under "Marc Demo"
This means that the certification is already expired and should not.
When completing a certification (survey), a hr_resume_line is inserted in the
database with a start_date and an end_date set to the completion date, causing
the certification to be expired right away.
We only do "cosmetic" correction here as the real fix will be done in master to
avoid multiple upgrade:
- to avoid existing certification to be displayed in red in the reporting view,
we correct the display (by avoiding adding danger decoration to the line if the
date_start equals the date_end). That correction won't avoid to find those
certifications as expired as we can't correct the computed field as it is
stored. Also, if the expiration_status column is shown (hidden by default), it
will display expired on those certifications.
- We do a similar correction in the display of the employee resume.
Note: the end_date problem is anterior to v17 but the resume line expiration
has been introduced in v17.
Task-3389395
closesodoo/odoo#158047
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
When typing in Japanese with Romaji input, a traceback occurred when
hitting backspace to remove the only character in the editable while the
Japanese character selection menu was open. This is because that case
triggers an `insertCompositionText` input event with an empty string,
and tries to delete the editable, which is unremovable. Since we called
`_applyRawCommand` without wrapping it in `_protect`, the unremovable
error caused a traceback instead of a rollback. When fixing that, an
other bug appeared, which was the insertion of a `#` character. This was
due to the fact that `insertText` was called with empty content, and
`insertText` defaulted to the character `#` for no particular reason
since the early proof of concept of the editor.
task-3134566
closesodoo/odoo#159005
X-original-commit: cb75212d4fe302b54097fbc90da6d6ef8b38205b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
That is how states are (might be?) exported, so it should be possible
to find them the same way.
closesodoo/odoo#158984
Task-id: 3644762
X-original-commit: 26df8e2858d8bcaa11dfae68be328388b1983745
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin
has been removed and is referenced everywhere, leading to tracebacks or
the impossibility to install a new application as res.group configurations
all relies on this, like:
<record id="group_helpdesk_manager" model="res.groups">
<field name="name">Administrator</field>
<field name="category_id" ref="base.module_category_services_helpdesk"/>
<field name="implied_ids" eval="[(4, ref('group_helpdesk_user'))]"/>
<field name="users" eval="[(4, ref('base.user_root')), (4, ref('base.user_admin'))]"/>
</record>
We could adapt all the occurences (severeal hundreds) to ensure robustness
but this won't prevent developer from introducing new use cases + the user
can be archived instead if we want to remove him from the pricing.
closesodoo/odoo#158885
Taskid: 3802440
X-original-commit: b55994b4c5e737aae593eb0419f96347ad90bebb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets (e.g. 3775298) are created because the default menu has been deleted,
leading to the impossibility to install a new module, as the parent_id
for new menus like /shop or /event are directly referencing the
website.main_menu record, or to the impossibility to create a new
website.
Task-3802440
closesodoo/odoo#158879
X-original-commit: adb1dcfd0a150ab4706a09a29ae8921fb94fa463
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Bug:
When an irish company without VAT invoices a Norvegian company with a 0%
tax, the category of the tax is "K" in the Bis 3 xml, which will raise:
"[BR-IC-02]-An Invoice that contains an Invoice line (BG-25) where the
Invoiced item VAT category code (BT-151) is "Intra-community supply"
shall contain the Seller VAT Identifier (BT-31) or the Seller tax
representative VAT identifier (BT-63) and the Buyer VAT identifier
(BT-48)."
Using code "G" would also raise: "[BR-G-02]-An Invoice that contains an
Invoice line (BG-25) where the Invoiced item VAT category code (BT-151)
is "Export outside the EU" shall contain the Seller VAT Identifier
(BT-31) or the Seller tax representative VAT identifier (BT-63)."
Fix:
We should only use "G" or "K" when the supplier has a VAT. If a supplier
without a VAT invoices with a 0% tax, we should use the tax category "E"
(Exempted).
opw-3785810
closesodoo/odoo#158670
X-original-commit: 357f1aec4bfa12fe476a207f2acfc1bf4a6232d5
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps to reproduce:
-------------------
- install calendar, project and documents;
- create an activity for a task (project.task) with meeting type;
- change attendee to the meeting;
- save;
Issue:
------
The activity is not linked to the right task.
Cause:
------
When we create a `calendar.event`, when the event is at a future date,
we send an email to the attendees.
This email must include an attachment corresponding to the ICS file.
Depending on the `no_document` context key, we may or may not create a document.
When we create the document, we have a value for the `activity_ids` field (one2many)
which is the ORM command for linking the newly created document.
This will result in the document id being written to the `res_id` field
of the `mail.activity` record.
Unfortunately, the activity contains a `res_model` which is not `documents.document`.
The result is that the activity is linked to a `res_id` which is not
that of the model previously set for it (i.e. `project.task`).
Solution:
---------
Add context key `no_document` when creating an attachment for ICS files.
opw-3746857
closesodoo/odoo#158570
X-original-commit: 17ac8d3f25bad2c4f37793e06edca40793a4f3d5
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Before this commit sol field wasn't editable when user
don't have any sales access and it was editable for
timesheet page and project form view.
This commit make SOL field in task form editable to
be consistant with project form and timesheet page
of tast form.
task-3764793
closesodoo/odoo#158547
X-original-commit: 1d25d6f92d4ecf658bbbc9d39983808fa0fc9c87
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Signed-off-by: Kartik Chavda (kcv) <kcv@odoo.com>
Versions
--------
- 16.0+
Steps
-----
1. Set tax rounding method to global;
2. create a loyalty program offering 100% discount on orders;
3. create a SO with the following line subtotals & 15% tax:
1. $5.60
2. $8.92
3. $44.91
4. $217.26
5. $2400.00
4. apply the 100% discount program.
Issue
-----
Total comes down to $0.01 instead of $0.00.
Cause
-----
To calculate the `discountable` amount, any non-fixed tax is mostly
ignored, instead only looking at price totals and fixed taxes. As global
tax rounding is achieved by using increased precision in intermediary
calculations, rounding errors are introduced by only looking at totals.
Solution
--------
Use the `compute_all` method instead, to retrieve precise tax data, and
add/subtract taxes depending on `amount_type`.
opw-3710365
closesodoo/odoo#158387
X-original-commit: 09f31597163a3251e58bb7b08939301574e1f65a
Signed-off-by: Levi Siuzdak <sile@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit, when using a shipping method with the variable
weight*volume for price computation, the price was growing with the
square of the ordered quantities. This is because both volume and
weight were multiplied by the quantity, before being multiplied with
each other in the next step.
This commit fixes the issue by introducing the variable weight*volume
at the beginning of the computation.
In order not to break anything in stable, the new variable is added as a
kwarg to the useful methods.
OPW-3802315
closesodoo/odoo#159007
X-original-commit: 0a8db0fa14bb63abd0b2a8f0234d86700b6c1e2e
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
Commit [1] was introduced to fix an issue where the website menu cache
is incompatible with having a slug url in one of its menu.
But in the enterprise build, since the website_helpdesk module is adding
one menu containing a slug url, it would disable the menu cache.
Unfortunately, the website_blog perf tests (at_install) are executed
after website_helpdesk is installed, meaning that in enterprise, the
perf test of website_blog would fail since it would require some more
SQL Queries (1 or 2 depending of the test) to render a blog post as it
would have to query the website.menu table.
It's still unclear how commit [1] was merged in the codebase since the
enterprise staging should have failed.
runbot-60466
runbot-60467
[1]: https://github.com/odoo/odoo/commit/948235079f002794f9837d3cf91e2d20e3254e20closesodoo/odoo#158666
X-original-commit: 11acdfc7d8dd0dfe146b6f7547123af94e2a0baf
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduces an update to the Font Awesome library,
specifically replacing the X/Twitter icon with its new design. It also
involves adjustments to a few images and SVG files to incorporate the
updated X/Twitter logo.
Technical note: It updates an existing file, originally modified for the
addition of the TikTok icon, which was not available in Font Awesome 4.
task-3463530
closesodoo/odoo#158586
X-original-commit: 34cba04a452f2da21f3418d6fc48a484da8ecd27
Related: odoo/enterprise#59147
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
* Activate multi-currency (Company currency `USD`, another currency activated 'EUR')
* Create invoice/bill in `EUR` and post it
* Archive `EUR'
* Open Invoice/Bill
Issue:
* Alert for inactivated currency is always displayed
Fix:
* Alert for inactivated currency should be displayed in draft state only
closesodoo/odoo#158802
X-original-commit: 72a0058ec748a03351ab3ad7536ff7089f84262e
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
As we imported invoices from the IAP proxy we refused files when the
same filename was already present in the database.
Import invoices sent by Company A to Company B on the same Odoo database
was therefore impeded. The CRON would try to import the Company B's
vendor bill with the same attachment's filename as the Company A's
invoice and reject the file.
Now we fill in the `company_id` field on the attachment and we search
for attachments which belong to the company we're importing for, so the
case is covered.
An import test has been added.
opw-3673508
closesodoo/odoo#157755
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
In a1f32fafa85b300e2d656a57797b8dbde6e3f065, various onchanges from the
picking types were changed into computes. However, the compute for the
`print_label` field was forgotten and never linked to its field.
closesodoo/odoo#158869
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
_read_group doesn't raise an error when we have an aggregate
specification like `order_id.create_date:min`, instead it silently
ignores the `.create_date` part.
We only add a warning in the stable version to avoid breaking any
change.
closesodoo/odoo#158777
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
commit that introduced the issue : https://github.com/odoo/odoo/commit/8e516dccac4ced7e48adfabe756a899784bac9ca
Issue:
======
valuation unit cost is wrong when we do backorder with real time unit
price computation
Steps to reproduce the issue:
=============================
- Create a kit with 2 components with product quntity to produce = 3
- Put qty = 2 for the first component and qty = 1 for the second component
- Assign product category to the kit product and the components as fifo
one with automatec price computation
- Create a purchase order with 30 quantity of the kit and price unit =
90
- confirm order and go to receipt
- Confirm 4 qty for the first component and 2 qty for the second.
- Create backorder
- Go to the confirmed receipt and go to valuation
- You will see that the total sum corresponds to the price of all the
products and not only the confirmed ones.
Solution:
=========
We need to use the bom quantities and not the order line to get the
unit_cost of each component.
opw-3790132
closesodoo/odoo#158788
X-original-commit: a72232694f68a810986e5c1c24fd0394d058af41
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
- Create PO
- Confirm, delivery and create bill
- Confirm and create reverse move via "Add credit note" (Full Refund)
- Open portal view of the PO
Issue: The credit note payment status display `Waiting Payment` badge
instead of `Paid`
opw-3806514
closesodoo/odoo#158556
X-original-commit: 66d08a484dae64f559a78ccee18b4a79f9e4e70e
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
For method `_get_product_for_ui` in pos_self_order's product.product extension, check fields `product_tmpl_id.image_128` and/or `image_variant_128` for the existance of an image on the product (`has_image` key).
Previously, the field `image_1920` was used which has two issues:
1.) The 128 sized image should be preferred because it is 15x smaller than 1920. The whole image is loaded at this point, so the smallest-sized one should be used.
2.) `image_1920` is a computed, non-stored, field. This has the implication that the image will be processed, thus consuming more memory (even leading to a MemoryError on the customer's DB). This happens like so:
a.) `_compute_image_1920` is called, which sets a value into `record.image_1920`. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/addons/product/models/product_product.py#L157
b.) Eventually `_image_process` is called, which performs memory intensive computations on the image. https://github.com/odoo/odoo/blob/38f37edad3da4a4547b73d971e053b0634067fa1/odoo/fields.py#L2550
So this can be avoided by implementing this commit, which will check the stored, non-computed fields instead.
Memory benchmarks for allocations by `_get_self_order_data`:
Done on customer DB with 1340 product.products, with a total of 776 images between them.
Before commit: 1638.4 MiB + server memory limit reached
After commit: 29.7 MiB total
Total improvement of 55x less memory usage
closesodoo/odoo#157900
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
To reproduce issue:
.create a new picking of any operation type
.save the picking (so that a name is formed)
.edit the picking and change the operation type to another type
.save manually
Expected result:
new name with matching prefix to the new operation type
Actual result:
previous name with prefix from previous operation type is still
there. This is an issue because then the name doesn't match and
this can be confusing to users
When a user create a new picking of any operation type and save the
picking, the name is formed based on your type. If the status of
picking is draft, and he needs change the picking type, the name of
picking is not changed, so, this PR solves this error. Now, when
change the picking type and save it manually, the name of picking
will be regenerated with the correct specification. Should be receipts,
workorders or delivery.
task-3703643
closesodoo/odoo#153147
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, it happens that the taxes display on the pdf were wrap,
specially when the description in the pdf were too long. This commit will add a
text-nowrap on the taxes when the len of the taxes is shorter than 10 characters
closesodoo/odoo#158774
Task: 3754824
X-original-commit: 95d0bd1794418ac8bdb4464c54304d3dcd0cb523
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
Steps to reproduce:
- Create pricelist with an end date in the past for a stored product
- Click on manual replenishement
- The created PO will have a price of 0
Bug:
if no valid pricelist is found unit price is set to 0
product standard price is a better fallback
opw-3692985
closesodoo/odoo#158650
X-original-commit: ed106e70f908deda819007fc68feaa44074c0472
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
If phonenumbers library is not installed, we should display a
relevant error message, instead of the generic invalid phone number
error message.
closesodoo/odoo#154926closesodoo/odoo#158546
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Now that we check whether a participant exists on Peppol network first when they register,
we should also mock that request. Currently, since that request is not mocked,
all peppol tests are skipped.
Part-of: odoo/odoo#158546
If the participant is not active on the IAP server, the server sends back
a Participant not ready error in response without raising an error.
On the client side a user sees a traceback, because we're trying to retrieve
a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid'].
That's because we treat that error in the try block and then proceed
to the else block because technically there was no exception.
This commit moves that error handling to `else` block so that such invoices get the proper error messages.
Part-of: odoo/odoo#158546
Before this commit:
In POS online payment the usually the user is either the
logged in user/public user which ends up raising error
`The phone number is invalid` even when the customer is selected
After this commit:
Razorpay doesn't raise the error instead now we don't create
customer when it is not a tokenize request
task-3786679
closesodoo/odoo#157533
Signed-off-by: Harsh Modi (hamo) <hamo@odoo.com>
Those are optional, commit [1] mimicked the python code in JS but with a
mistake: "required" instead of "optional".
Steps to reproduce:
- Enable cookies setting on website
- Drag & drop a snippet
- Modify that snippet conditional visibility to "Utm Campaign: Sale"
- Visit in incognito /?utm_campaign=Sale, you don't see the snippet,
which is good
- Now click on "Only Essentials" in the cookies banner
- The snippet will be shown, because when accepting the essentials
cookies, the utm ones were set, since they were marked as required.
[1]: https://github.com/odoo/odoo/commit/90ada07ecfc308ad181748d3e809810bb90f3eecclosesodoo/odoo#158720
X-original-commit: 63b0606d728be949cc6cfcb0dbdf17114ec1c711
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Those master data would break the basic accounting pdf generation flow
as those are widely used and it is not expected from end users to delete
them.
Example of support ticket from that issue: 3790875
closesodoo/odoo#158637
Taskid: 3802440
X-original-commit: b1ecc922503ff3a9618e89afd13659e37eb3fbed
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Lots of tickets are issues when the end user deleted this product
category, leading to the impossibility to install another carrier
as this category is referenced by all the specific carriers products
Ticket example: 3789116
closesodoo/odoo#158626
Taskid: 3802440
X-original-commit: 9383b6f4a5ef0394588c522efcc92e6f37a245cb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit:
When you increase the height or width of cells in a table and subsequently
delete a row or column, the adjacent rows or columns experience an increase in
their height or width. This happens because the table preserves its overall
dimensions even after resizing individual cells.
After this commit:
Now, the table no longer preserves its height or width. When resizing the table,
the height or width of its rows or columns does not increase.
task-3636212
closesodoo/odoo#158256
X-original-commit: 9940bf3e153714022785b50cb423e52634c99202
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
- When adding tasks to a contact using Studio
and attempting to set a task's project to a
project linked to a Sales Order (SO),
we encounter the following error:
"TypeError: 'NewId' object is not iterable."
Steps To Reproduce (in 17.0):
- In a contact form open Studio and add a O2M field Customer (Task)
- Create a new task in the O2M and set the Project to a project
related to a SO.
- Notice Traceback Error "TypeError: 'NewId' object is not iterable"
Solution:
- The issue arises in the search domain of
_get_last_sol_of_customer , where the domain is
('order_partner_id', 'child_of',
self.partner_id.commercial_partner_id.id),
where the type of `self.partner_id.commercial_partner_id.id`
is NewId since the partner is being edited to add a task.
This action triggers the `parse` and `to_ids` methods with
a value type of NewId. thus the error.
- The operator child_of expects a list of IDs, and the ids
property refer to the record's origin ids.to resolve this,
replace `commercial_partner_id.id` with `commercial_partner_id.ids`.
opw-3760372
closesodoo/odoo#157318
Signed-off-by: Raphael Collet <rco@odoo.com>
Imagine the following situation: an automated action A is triggered when
some stored computed field F has a certain value. When a record is
created and no value is given for field F, then the automated action A
may be run twice: once when evaluating A's domain forces the computation
of F, and once again because A's domain is satisfied.
The implementation already uses context flags to reflect which automated
actions have already been run, in order to avoid automated actions to be
run recursively. The fix consists in enabling those context flags to be
shared among the evaluation of the domain and processing of the
automated actions.
opw-3731182
closesodoo/odoo#157272
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Nasreddin Boulif (bon) <bon@odoo.com>
After the fw-port of the fix in [1], it seems some references had
changed, breaking the translations again. This commit fixes that.
[1] 9d2f7f312c5d699b937bd5546085fc151a149a8f
closesodoo/odoo#158664
X-original-commit: d28189565f035cf2f84f7cb01137cece2bb90662
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
is checked but not the display name of the product.
It is not necessary for the purpose of the change and adapting
the display name on the product is very common customization
for many companies.
X-original-commit: bbba3cd6e5affff53728d877b0d426eb6c88ff38
Part-of: odoo/odoo#158621
Incorporate Christihan Laurel (CLaurelB) as Vauxoo's contributor.
I confirm I have signed the CLA and read the PR guidelines at
http://www.odoo.com/submit-prclosesodoo/odoo#158729
X-original-commit: f0a0d596ab716c96de38a5c0f837da2924338d7b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Mehdi Outagant (MOU)