Before this commit, when the automatic invoice setting is enabled, a
traceback would be shown when customers pay and the post-processing of
the transaction tries to create an invoice. The problem is that the
invoice is created in sudo, but it's unsudoed before logging invoices
in the chatter.
Now, the invoice will stay sudoed if the method is called in sudo.
opw-3700576
closesodoo/odoo#157779
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In a single database, you could have two partners who are called John Doe.
Before this commit, any statement line where the partner_name was set
with 'John Doe' would return the last one being created, due to the _order
attribute on res.partner model, even if the statement line was generated
from a payment of the other 'John Doe' (ie first one created).
With this commit, we ensure that the wrong partner is not selected, in
case we cannot differentiate one from the other.
closesodoo/odoo#157754
X-original-commit: 421a0ae53de8c947d68fb1c22066d4d73c1ce9b7
Related: odoo/enterprise#58699
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior:
The pos sale report is showing the wrong value in the "Total (VAT Exl)"
column. The value acutally shown is the total tax included.
Steps to reproduce:
- Create a product with a tax included in price
- Create a pos order with this product
- Validate the order
- Close session and print the pos sales report
- Check the value in the "Total (VAT Exl)" column.
opw-3684937
closesodoo/odoo#157753
X-original-commit: ba58ac0f86e10755f1ffbc80814c3722470517f9
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Currently, when the user and the target both are in multiple companies,
the profile button cannot be displayed correctly. Since the employee_id
uses `('company_id', '=', self.env.company.id)` rather than `in`.
This commit fixes the issue by checking employee_ids directly and if it
is found, the profile button will be displayed correctly.
We don't care about which employee_id is used if there are multiple,
since the user are in multiple companies as well. If looking for a
specific profile, the employee can be found in the HR application.
closesodoo/odoo#157741
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Before this commit, the product configurator dialog was not shown when
adding to the cart, a product with only no variant attribute values,
using the buy button on the '/shop' page.
Now, if the product has configurable attributes (custom attribute, no
variant, and dynamic attribute can now be selected), the product
configurator dialog is shown.
opw-3736469
closesodoo/odoo#157737
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce
==================
- Go to Accounting > Customer Invoices
- Open any record with no attachments
- Drag & drop a pdf attachment on the chatter
=> The PDF viewer is empty
Cause of the issue
==================
When uploading an attachment from the FileUploader, the parent view is
reloaded.
This is not the case when uploading an attachment from the dropzone.
opw-3748853
closesodoo/odoo#157232
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Description:
Add missing index on FKey `tax_cash_basis_rec_id` to speed up
deletion of `account.partial.reconcile` records during reconciliation.
It's `btree_not_null` as the relationship is sparse.
Reference:
opw-3649801
closesodoo/odoo#157696
X-original-commit: 3852da88bb48e6bd82618839b5b351246129ebf6
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Purpose
=======
The time off duration is set to 0 when the related contract is set
as expired, then we remove the end date and set the contract back
to running.
That's because the check was done before calling super, hence the
contract is excluded from the candidates because it is still expired
without end date, which would make no sense when trying to retrieve
the related calendar.
closesodoo/odoo#157681
Taskid: 3806342
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Before this commit, ir.actions.report can be randomed orderer.
closesodoo/odoo#157616
X-original-commit: 1a2b83d8a4fc956e07d6009eb7fc308eb16eedd2
Signed-off-by: Raphael Collet <rco@odoo.com>
The `test_calendar_month_view_start_hour_displayed` makes sure that start hour is displayed in calendar month view.
The test was failing before 09:00 AM because after creating the event, it sets the start time to 10:00 without setting the stop time or duration.
So when creating this event before 09:00 with a default duration of 1 hour, the stop time would be before 10:00, and it would raise an error.
This commit aims to fix this issue by adding a step to set the duration of the event, avoiding the potential error.
fixes runbot-59850
closesodoo/odoo#157263
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
**Current behavior:**
When creating a new product template record, the tab title will
be *Odoo - False* until a new name is saved rather than
*Odoo - New*.
**Expected behavior:**
When creating a new record in a form view, the tab title will be
*Odoo - New* until the `name` field is filled out and the record
gets saved (at which point it will be *Odoo - <name>*).
**Steps to reproduce:**
1. Install `sale_management` and go to the product list view
2. Create a new product, observe the misnamed tab title
**Cause of the issue:**
In `product.template`'s _compute_display_name() method, some of
the default values can have a 'False' (str) value which will
evaluate to True (bool), setting the name to 'False'.
**Fix:**
Set the display_name field to a False (bool) value if the
current record does not have a name field set.
opw-3793588
closesodoo/odoo#157258
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Steps to reproduce:
- Enable 2 step reciept in warehaouse settings
Bug1:
- Create and confirm a PO qty = 1
- Open reciept update qty to 4 and validate
- The internal transfer qty is updated to 3 (the difference)
Bug2:
- In inventory overview create a new reciept and mark it as todo
- Update quantity and validate
- Internal transfer is not updated
Root cause:
Initially in version 17 product_uom_qty was changed to indicate the demand
before the move is done and it indicates the acutual done qty when
the move is done.
After https://github.com/odoo/odoo/pull/130342
product_uom_qty will always indicate the demand qty,
and qty_done will always indicate actually done quantity.
Fix:
updating the quantity will create a new move for the difference that is
used to trigger new push rule and then merged back in the original
when merging product_uom_qty is not updated to keep track of the intial
demand but pending linked moves should be updated to reflect the new quantity
opw-3708740
closesodoo/odoo#156331
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Ensure an avatar is generated based on the employee/user name
if no image is provided at the record creation (for internal users only).
closesodoo/odoo#147446
Taskid: 3637523
Related: odoo/enterprise#58646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
[This other commit] introduced a method to serve Google fonts from the
local server. Then it has been back-ported to previous versions with
[this commit].
Unfortunately, the font was not identical when the user chose to load
the font from Google servers versus from the local server. This
discrepancy was due to a missing parameter when downloading the font
file to serve it from the local server. This commit fixes the issue by
adding the missing parameter.
Steps to reproduce the issue fixed by this commit:
- Drop a text block onto a website page.
- Make the text bold.
- Go to the theme tab.
- Change the font to https://fonts.google.com/specimen/Poppins
=> The text style changes depending on whether you checked the "Serve
font from Google servers" option or not.
[This other commit]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd
[this commit]: https://github.com/odoo/odoo/commit/04ab4e255b7fef1608ee2c70a3a005f3064bc4f3
opw-3775683
closesodoo/odoo#157800
X-original-commit: be2d27e69d7928a46d49a7ef0a3c4b93932a36b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
During the copy of provider if the journal is set, it create a new account.payment.method.line, and if you change the company of the new provider you have an error when you try to create a new journal.
closesodoo/odoo#157767
X-original-commit: 0357c9ec749d893ba1d7913903fd0c45df400662
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Create an invoice to partner A, confirm
Create an invoice to partner B, confirm
From Invoice list view, select just one invoice and hit register payment
It will be possible to only select journals having inbound payment
method
Now select both invoices and hit register payment
It will be possible to select any Bank journal, even if both invoice
payments should be incoming
opw-3757686
closesodoo/odoo#157732
X-original-commit: 88f43a454f3cd9207aa62e2e58b67bcfdf0fcb59
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
[FIX] microsoft_account: accessing the url without any post data
When a user tries to access the URL directly, at that time the value of
dictionary `kw` is not available. So the error will be generated.
Error : KeyError: `state`
This commit will solve the above issue by raising the `BadRequest` if the value
of dictionary `kw` does not available.
sentry-4377121133
closesodoo/odoo#157720
X-original-commit: 382b64c2f14073cfff1a8ef9290b5c7834d52188
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
------------------
- Have Website and Mail Group installed
- Send Guidelines for a mailing list through the Website app
Issue
-----
{{ object.mail_group_id.name }} appears in the body of the "Mail Group: Send Guidelines" mail template instead of the actual mail group name.
opw-3778512
closesodoo/odoo#157772
X-original-commit: fe05e7c6acf02986a154af1235ac244a7686b30b
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
When the cookie bar is activated, the optional cookies are deactivated
by default, unless you click on I agree.
This causes issues regarding UTMs:
- You can have blocks to show only if an UTM cookies has been set
- UTM should be added on sale order for instance when reaching the
website through a link with an UTM and then buying something
Steps to reproduce (utm on quotation):
1. Install ecommerce
2. Go to Settings/Website
3. Activate Cookies Bar
4. Open a private tab
5. Go to /shop?utm_campaign=Sale
6. Click on I agree on the cookie bar
7. Buy a product
8. Go back to Sales App in backend
9. Find the last public user quotation
10. Go to other info tab
11. The medium field is empty
Steps to reproduce (utm based visibility):
1. Drag & drop a snippet on a page (let's say the /page)
2. Set that snippet visibility to "Visible only if utm campaign is
"Sale"
3. Repeat step 2 3 4 from above
4. Open /page?utm_campaign=Sale
5. You will see that the block is not shown despite accepting the
cookies and having the correct utm set.
Note: we don't want that clicking on I agree reload the page, it would
solve everything but would have poor usability.
Note that with the default cookies bar, you could still naviguate to
another page, and accept the cookies later, in which case the UTM would
never be set since they would not be in the URL anymore.
It's an acceptable limitation, if that's a real issue to someone, they
have to set the popup layout to a blocking one, not the small non
intrusive one.
Fix:
When closing the cookie bar, forcing the info in the URL to be stored in
the cookies if the key is a UTM.
opw-3681927
closesodoo/odoo#157711
X-original-commit: 8c31c2b08ed84ccdb97af628d9db7f6c67c6d830
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Antoine (ande) <ande@odoo.com>
Steps to reproduce:
- Create an empty database (without demo data)
- Install stock_account
- Go to Invoicing settings
- Select Austria as Fiscal Localization
- Go to Apps
- Try to upgrade stock_account module
Issue:
A traceback is raised.
The module tries to create the default stock accounts properties on
the main company, but they already exist, which triggers a violation
of the SQL unique constraint (ir_property_unique_index) of "ir.property"
on the combination of (fields_id, company_id, res_id) fields.
Cause:
When "stock_account" module is installed/upgraded, the default stock
accounts properties are created for the main company with forcecreate="True"
option, which means they will be created if their "xml_id" doesn't exist, even
if they are declared inside <data noupdate="1">.
In this case, they are created with their "xml_id" at the module installation
with the following values:
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: False
When the Austrian localization (or other localizations defining their own
stock accounts properties) is selected in the settings, these default properties
are deleted and replaced by those coming from the localization package with
some similar values but without "xml_id":
- company_id: [the main company]
- fields_id: ["property_stock_account_output_categ_id" field of "product.category" model]
- res_id: False (to be used as a default value)
- value: [depends on the localization package]
Then, when upgrading "stock_account" module, as the "xml_id" of the default
stock accounts properties cannot be found anymore, the upgrade process will
try to re-create them and will trigger the SQL unique constraint.
Solution:
Move the creation of the default stock accounts properties in a python function
to check if the default properties already exist based on the combination of
"company_id", "fields_id" and "res_id" fields and not based on the "xml_id".
opw-3682320
closesodoo/odoo#157703
X-original-commit: 7e710e4effae6dc812a9304090b5796b39fed640
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Before this commit, there was no message in the logs when the import of
a data module is finished. This commit adds a log info to state that the
module is now in the db.
closesodoo/odoo#157687
Signed-off-by: Pierre Masereel (pim) <pim@odoo.com>
This change allows for locked purchase orders to be matched with OCR
closesodoo/odoo#157569
Task: 3798080
X-original-commit: 59fe446aee1ee6d634aa286adc261a3c7f547d14
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Joris Makauskis (jmak) <jmak@odoo.com>
Before this commit:
POS online payments uses the logged-in user or the public user,
even when a POS order customer might also be present.
After this commit:
We check the partner_id for POS orders and give it
precedence over both the logged-in user and the public user.
task-3805695
closesodoo/odoo#157562
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Issue
-----
In a POS session, some buttons of the numpad and some fields in the client editor form are not translated.
opw-3783252
opw-3756593
closesodoo/odoo#157509
Signed-off-by: Adrien Guilliams (adgu) <adgu@odoo.com>
Steps to reproduce:
-----
1. Have lunch app activated
2. Settings > Technical > Scheduled Actions
3. Run manually a scheduled action to send an automatic email to a lunch provider with "send order by" not equal to email.
** Traceback error **
Changes
-------
The user will see an UserError instead of a traceback.
opw-3751229
closesodoo/odoo#157305
X-original-commit: 13792ee52f96d739ef1b7af0f1323906b1a39ee4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Tanguy Quéguineur (taqu) <taqu@odoo.com>
Steps to reproduce:
- Install timesheets
- click on all timesheets
- open search view
Issue:
- in search view 'my' filters block should be at the top of the list
Cause:
- misplacing of the name month filter causes the issue.
Solution:
- if we replace that filter below the group then the issue will be solved.
task-3772684
closesodoo/odoo#155714
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since this commit [1], the two searchbar snippets are broken.
The search bar input seems invisible because it shares the same color as
the default snippet background and has no border. This style matches the
search inputs used in apps (like the "/shop" search bar), which isn't
affected by the "Input fields" settings in the "Theme" tab.
To resolve this issue, this commit introduces a new option to choose
between the "light" style (similar to "/shop" search bars) and the
"default input style" for the 2 "Search" snippets.
The "default input style" is automatically applied when the "Search"
snippet (excluding saved snippets) is dropped to address the issue
caused by the light-on-light color scheme.
Steps to reproduce the issue:
- While in Website edit mode, drag and drop a "Search" snippet onto the
page.
- Bug: The input appears invisible due to the lack of a border and a
background color identical to the snippet's section color.
[1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20
task-3662985
closesodoo/odoo#154435
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
In Knowledge, embedded views anchors have a `data-behavior-props` attribute
containing information on how to render the embedded view. That attribute is
sometimes updated, and during a collaborative session, receiving such an update
as a collaborative step would trigger a full sanitization of the embedded view,
possibly discarding some transient content that could break the view, even
though it caused no security issue since it is all rendered on a per client
basis (each client fully renders its own view).
The proposed solution is to sanitize only the attribute of the node and not its
content during `_safeSetAttribute`, which is reasonable, because the node
content is already sanitized recursively for `add` mutations.
task-3060490
closesodoo/odoo#157669
X-original-commit: d9e3d7bdb6e13e6049a86ed08160daccf0fcbcc8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"
The design of the karma wheel is broken because the translation for "Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k xp pour passer au niveau supérieur"). While in French the text go outside the wheel and it appears clearly broken, it is also the case in English as the rank name is hidden due to the length of the text (for example when gaining one karma: 7.49k is displayed instead of 7.5k which takes more place).
To avoid modifying the template "profile_next_rank_card" that could break community overrides, we solve this problem in css by increasing the karma wheel size and the precentage of width occupied by the text inside the wheel. We also reduce the vertical margin between the rank name and the descriptive text and reduce the line height to avoid the text to overlap with the wheel. And if the text is still too large for some language it will be truncated and an ellipsis will be used.
Technical note: we do the change in website_profile.scss (and not in website_slides.scss) because it applies to both karma wheel: the one on course home page and the one in the profile page.
[FIX] gamification: fix incorrect next rank
How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"
The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be: 4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next level is doctor at 10k).
We solve that issue by fixing the method that determine the next rank (see technical note for more details).
Technical note: the problem occurs because the admin user has the rank 4 but its field next_rank_id is null while there is a level 5. In that condition, the method _get_next_rank returns an empty recordset while it should return the rank 5. We simplify that method to always return a rank if there is one suitable (if you reach the last level, there are no next level).
(Initial PR in saas-16.1: odoo/odoo#151372)
Task-3617054
closesodoo/odoo#157655
Forward-port-of: odoo/odoo#157585
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
How to reproduce:
- Install "French" for the website
- log out and log in as demo
- Go to the front-end and click on "Courses"
The design of the karma wheel is broken because the translation for
"Get 7.5k< xp to level up!" displayed in the wheel is too large ("Obtenez 7.5k
xp pour passer au niveau supérieur"). While in French the text go outside the
wheel and it appears clearly broken, it is also the case in English as the rank
name is hidden due to the length of the text (for example when gaining one
karma: 7.49k is displayed instead of 7.5k which takes more place).
To avoid modifying the template "profile_next_rank_card" that could break
community overrides, we solve this problem in css by increasing the karma
wheel size and the precentage of width occupied by the text inside the wheel.
We also reduce the vertical margin between the rank name and the descriptive
text and reduce the line height to avoid the text to overlap with the wheel.
And if the text is still too large for some language it will be truncated and
an ellipsis will be used.
Technical note: we do the change in website_profile.scss (and not in
website_slides.scss) because it applies to both karma wheel: the one on course
home page and the one in the profile page.
Task-3617054
X-original-commit: f32eabf55db4db4d46b45032c76bfa17dfce475f
Part-of: odoo/odoo#157655
How to reproduce:
- Install website_slides with demo data
- Connect as admin
- Go to the front-end and click on "Courses"
The karma wheel shows 100%, "master" and a karma of 2.5k xp while it should be:
4% on the wheel, "Doctor", 2.5 / 10k (karma_min for master is at 20k and next
level is doctor at 10k).
We solve that issue by fixing the method that determine the next rank (see
technical note for more details).
Technical note: the problem occurs because the admin user has the rank 4 but
its field next_rank_id is null while there is a level 5. In that condition, the
method _get_next_rank returns an empty recordset while it should return the
rank 5. We simplify that method to always return a rank if there is one
suitable (if you reach the last level, there are no next level).
Task-3617054
X-original-commit: 6639005e660d0516a7624bd274c27e897797d614
Part-of: odoo/odoo#157655
Some translations were missing or incorrect for the VJ grid
in the Tax Report.
task-3724926
closesodoo/odoo#157622
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Refactored the owner_id check in the stock_account module to make it more flexible for future updates.
Before, any changes or additions to how ownership is checked required overriding the whole method.
Now, it's easier to extend ownership checks without such heavy modifications,
paving the way for more straightforward updates and customizations related to inventory ownership.
closesodoo/odoo#157614
X-original-commit: b01b73d58f57930bbfa705f5206e6e57f3816aa5
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
context of the creation of a new record
closesodoo/odoo#146019
X-original-commit: c3aea407ccf9903ea9b43edfdd0289b63c478ffb
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Steps to reproduce:
- Click on the footer and enable footer "Slide Hover" option
- In the theme tab, add a theme bg image
- Drag & drop a "Text - Image" snippet (or any snippet without a bg
color set, or any snippet with a bg color set and just remove it)
- The snippets and page layout in genral will receive a forced color
instead of using the bg image set.
This is because with the slide hover option, the bg has to be moved from
the `#wrapwrap` to the `main`. Indeed, it's the main which is scrolling
hover the footer, not the `#wrapwrap`. Without doing that, the elements
hover the footer would have a transparent background and would not hide
the footer.
But the bg image was not considered when doing it, only the bg color.
opw-3704746
closesodoo/odoo#157638
X-original-commit: 68c8a7f48ac955a8e9e4f1fc8cb1c76af54116b3
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
1. Go to the website
2. Drag a snippet that contains an image
3. Select the image block
4. Go to customize the image
5. Go to transform - select crop image
6. Crop and apply changes -> Overlay is hidden
Before this commit, after cropping an image the overlay was hidden. To
make the overlay visible again, you have to click elsewhere on the
snippet and then click on the image again, because the overlay was being
hidden.
When we perform an image crop, we activate the `hide_overlay` action,
which subsequently eliminates the `o_we_overlay_preview` class. This is
due to the fact that, during the image-cropping process, the
`previewMode` is set to `false.` However, if we wish to keep the overlay
visible, We can simply avoid triggering the "hide_overlay" action.
task-3392225
closesodoo/odoo#157635
X-original-commit: 2075b4c957a8e2d03fcfd8bfab99be1e49c31ca9
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce the bug:
- Enter Website edit mode.
- Drag and drop an "Image-Text" snippet onto the page.
- Grab the right edge of the right column of the snippet and extend it
to the right until it overflows the iframe and hovers over the editor
panel.
- Release the mouse, then hover over the iframe again.
- Bug: The "mouseUp" event was not triggered, and the column resizing
still occurs.
This bug occurs because the "mouseUp" event was attached to the
<body> of the iframe and not to the window of the iframe.
Indeed, for mouse events to be triggered outside of an iframe, they need
to be attached to the iframe's window.
This fix is not necessary before the version 16.0. Before V16.0, the
page preview and the options panel shared the same window. It's only
since this commit [1], where we moved the page preview into an iframe,
that the bug occurs.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
taks-3562970
closesodoo/odoo#157627
X-original-commit: e6be732450d9ef662a48ba074e1ca1ad32e35c04
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Signed-off-by: Benjamin Vray (bvr) <bvr@odoo.com>
Add the possibility to call the send & print with *only* a set of options.
All other checkboxes are therefore set to False, instead of their default computed value.
closesodoo/odoo#157532
Related: odoo/enterprise#58574
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Create a new Journal Entry
Add a 100$ debit line 1
Add a 100$ debit line 2
Add a new line: system will suggest 200$ credit line 3
Save
Delete line 3
Change line 2 amount into 50
Create a new line
Issue: the system will compute a credit amount of 50$
This occurs because in the onchange we work with a new record
representing the set of changes
Commands sent by the orm are:
- DELETE of line 3
- UPDATE of line 2
So in the new record we don't have information on line 1.
A solution is to recover the data from the stored record
opw-3757415
closesodoo/odoo#156875
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Steps to reproduce:
- Install planning app.
- Go to planning app, and convert the view to List.
- Group by Resource -for example-.
- Notice how the allocated time values are mis-aligned with the header label.
Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.
The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
- both firstAggregateIndex` = `lastAggregateIndex` = -1
- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1
- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.
opw-3764616
closesodoo/odoo#156647
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Get to a list view where there's a monetary field AND the related currency
field in the same list.
Then insert the list in a spreadsheet.
=> Either the currency format is not fetched or the currency name, depending
on the order in the list.
Bug introduced by 8777973e
opw-3770057
closesodoo/odoo#157623
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
Negative days are no longer allowed in the Payment Terms since 16.2, although it was possible before.
There is no need to block user behaviour if they require negative days (for example, days before end of the month), as the payment term works as expected with negative days.
To fix, we remove the constraint _check_positive.
To reproduce the issue:
- Go to Accounting -> Configuration -> Payment Terms
- Edit/Create a Payment Term with a negative value in the 'After' column
- When saving, a Validation error appears
task-3751491
closesodoo/odoo#157600
X-original-commit: fe1399a1821a05638c638fc4f0437a7aed70e260
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
In all cases, we will fetch the record since we display the name, so it
has no extra cost to slug the record instead of the id, and it will
prevent an extra redirect from /tag/1 to /tag/name-1 on click.
opw-3752989
closesodoo/odoo#157578
X-original-commit: c406220277a3005cde34a44ba733d470769c2dc4
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Antoine Dupuis (andu)