Prior to this commit, the rounding setting could be modified while
a session was open. This could potentially cause accounting
discrepancies and lead to unbalanced account moves.
opw-3677480
closesodoo/odoo#158625
X-original-commit: 021302a270028373ab519ea1d5409ffb73ee8424
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Prior to this commit, if a "Buy X get Y" promotion was in place, with
a free product reward associated with a specific tag, the computation
of the free product reward could be incorrect in the Point of Sale
when combined with products carrying the tag.
opw-3753994
closesodoo/odoo#158618
X-original-commit: 5f3c8017c5cf255e3b3fa53631a243d2f61c9f60
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
When applying a format in an unbreakable inline (without a class), the
format was immediately rolled back as we tried to remove split the
unbreakable in order to remove its style.
task-3768157
closesodoo/odoo#159110
X-original-commit: 78e809c18db7bd520ccf706b2504139248fbd0ff
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Issue:
======
resizing columns doesn't work properly in rtl direction.
Steps to reproduce the issue:
=============================
- Install arabic
- Go to notes
- insert a table
- Try to resize columns
Solution:
=========
We will handle the cases one by one:
Start: We need to update the `marginRight` prop instead of `marginLeft`
and calculate `sizeDelta` correctly which `clientX - (rect.x +
rec.width)`.
Middle: We will handle this the same as ltr direction, since it's the
reverse direction, we swap `previous` with `next` and `next` with
`previous`. Columns are sorted from right to left so we need to swap
columns when we recalculate them from the columns array so `item` will
be the one on the left and `neighbor` the one on the right.
last: We calculate correctly `sizeDelta` which is `rect.x - clientX`
task-3721794
closesodoo/odoo#159087
X-original-commit: 87f8bcd99a4b1049deed7bccbc5b85812ebc4674
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Issue:
======
The icons does match the direction of the move but it doesn't match the
label in the ltr language.
Steps to reproduce the issue:
=============================
- Install arabic
- Go to notes and insert a table
- write something in a column in the middle
- Click on the top of the column on the 3 points.
- The first item of the dropdown have the label in arabic meaning `Move
to left` but the direction of the icon and clicking on it will move it
to the right.
Origin of the issue:
====================
- The icon is being flipped because we are in rtl but in realtity left
is the same for rtl or ltr direction.
- We need to call `_onTableMoveLeftClick` when we are moving to the
right in rtl because the left of rtl direction is the visible right.
task-3721794
X-original-commit: 58cdfb8c80ecfb305ecdb84398508bd2fc180fb3
Part-of: odoo/odoo#159087
In Inventory Settings activate packages and storage locations.
Create a storable product [TEST] with tracking by lot
Create a PO for [TEST] with a [QTY] larger than one.
Receive the products (lot [A]) and put them in a package [PKG].
Create and process an internal transfer of the whole package [PKG]
from the input location to any location.
Unpack [PKG].
Go to Stock > Reporting > Locations
Locate the received product, hit 'History'
Issue: traceability is empty.
This occurs because the 'unpack' operation clean the information
relative to the package from the stock quant.
When accessing the history, the system lookup for move lines having the
same package (none in this case), so nothing is found
opw-3769752
closesodoo/odoo#158949
X-original-commit: 314d44b400717f392bfbb70f66ef9605c1f31041
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Before this commit, when creating a many2one field from an xml, with an
impossible combination "`required=True` - `on_delete='set null'`", the
column was not created in the database without any notice to the user.
This commit adds a constraint checking that any attempt to create a field
with this configuration would raise a ValidationError. This constraint
replaces the previous onchange method.
closesodoo/odoo#158778
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
*: web_editor, website
Commit [1] introduced new image settings for the product page.
When those settings were introduced, the editor was reloaded after the
RPC to properly reflect when the settings were changed. While this was
done, a data-reload was also added in the XML template of the options.
This was not necessary as the data-reload only works for some methods
which are not used in the image settings. Therefore, the data-reload
did nothing.
However, with commit [2], the settings were moved and combined with
page options. So the image settings automatically inherited the page
options behavior, which is to save and reload the page when a method
with data-reload is called. This caused the editor to ask for a reload
twice.
This could cause the page to reload before the RPC was finished:
- Add a 10 seconds sleep at the start of /shop/config/website controller
- Go to products page
- Enter edit mode
- Change the number of products per row
=> Nothing happens
Indeed, the page is reloaded immediately, before the 10 seconds rpc is
actually done.
This is also needed by the conversion of the SnippetsMenu to OWL:
It seems like the race condition introduces a traceback.
This commit fixes the issue by ignoring any save request from an option
that will reload anyway. It also awaits the RPC to finish before
reloading the page.
[1]: https://github.com/odoo/odoo/commit/54c6d36cfbea31fe60b888bbb903b0c6f22216b3
[2]: https://github.com/odoo/odoo/commit/b274cf2427951761e59eb357fb796b54be375507#diff-754f6c793d6a168d006d2a9da108142b889036031ac1a2e62060c225d060f858closesodoo/odoo#158468
X-original-commit: 556ae457b02e9c077d09fa9c3f9f1e6c6e26b345
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when a user of in chat posted a message and
deleted it, all other users kept the chat as unread.
Steps to reproduce:
- Connect as Admin and March Demo
- Send a message to Admin as Demo in DM chat
- Demo deletes this message
- Marc opens the chat
=> the unread counter is 1 and cannot be removed
This happens because when a message is deleted, there's still a
trace of it but the message is empty. However, empty messages could
not be candidate of setting the last message being seing by a member,
thus members were unable to mark the chat as read until someone else
posted a newer message (and did not delete it).
This commit fixes the issue by taking empty messages into account for
setting last message message of member, which allow to mark thread as
read even when newer messages have been deleted.
opw-3764410
closesodoo/odoo#158943
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Current behavior:
When printing a ZPL label for a product without barcode, the label was
printed with a barcode containing the "False" value
Steps to reproduce:
- Install the stock module
- Create a product without barcode
- Print a ZPL label for this product
- The label contains a barcode with the "False" value (You can check the
rendering on labelary.com)
opw-3797462
closesodoo/odoo#158939
X-original-commit: e392027afa245a708a906b484250ed46200e13be
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
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
Pedram (pebr)