Before this commit, we always had the address of the partner even if the address
were the same.
Now, depending on the address in the customer field or delivery address, we can
decide to display the invoicing address or shipping address or both.
Task: 3817563
Part-of: odoo/odoo#162557
Issue
-----
The activities summaries displayed by the misc. operations view in the accounting
app take up the entire screen and span across the card if the activity summary
is too long.
Steps
-----
- Open the Accounting App.
- Create a new entry from 'Miscellaneous Operations'.
- Add an activity with a long summary.
- Go back the dashboard. The summary will try to span the entire width.
Cause
-----
The activities are displayed with a field tag in the kanban view. The field tag
refers to the activities js component as a widget. Due the use of a widget attribute,
the template generates a div with class: "o_field_widget". This class is defined
to have a css "display" attribe with a default value of "inline-block". Using "inline-block"
causes the activity row to take up the whole width.
opw-3839992
closesodoo/odoo#162543
X-original-commit: dec1f870de9f7004a2935f61c79b83dada7a57a5
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Moataz Hussein (mohu) <mohu@odoo.com>
This commit improves the performance of the reference check for large
categories of Units of Measure (UoM).
After this commit, the number of UoMs in the category is counted using
the read_group method instead, resulting in faster performance.
Benchmark:
| Nbr of UoM | Before | After |
| ---------: | -----: | ----: |
| 0 | 0ms | 0ms |
| 1 | 1ms | 1ms |
| 30 | 6ms | 3ms |
| 200 | 7ms | 2ms |
| 18000 | 900ms | 15ms |
opw-3775689
closesodoo/odoo#162540
X-original-commit: 9f47341de352d08a8e325d14f25af8221bb392cb
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
Before this PR, trying to get an available operator could result in an
error.
When a live chat is created, an operator is selected based on various
criteria such as language, country, number of ongoing chats and
availability for calls. This selection process involves the
`_get_less_active_operator` method, which receives the status of all
operators and a list of operators to choose from.
Prior to this fix, an operator not included in the list of operators
to choose from could still be selected, resulting in errors when
trying to locate them in the operator list.
This PR resolves the issue by ensuring that operators are only
selected from the provided list.
opw-3874872
closesodoo/odoo#162357
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
The blogs filters in mobile is breaking the layout. This commit applies
a dropdown or an offcanvas instead which is displayed next to searchbar.
In this 17.0 fix, the dropdown becomes an
offcanvas if we have a sufficient amount of blogs which allows better
navigation on mobile and makes it consistent with other website modules.
Additionally it adapts the spacing to make it even between the
navigation component.
The `t-set="_classes"` is not removed in case of potential xpath in
production. Same goes for the `container` class on the div at line 9,
being overridden by it's t-attf-class counterpart.
task-3315921
closesodoo/odoo#157757
X-original-commit: 19f34c5e0973903b47cf6a5c65cc8888986abaa8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Current behavior:
When entering a lot name that doesn't exist in the PoS, the lot is being
created. But the lot is not being assigned to the stock move line.
Steps to reproduce:
- Create a product with tracking by lot
- Open PoS and make an order for this product
- Enter a lot name that doesn't exist
- Validate the order
- Close the session
- Go to the order picking in the inventory app
- The lot is not assigned to the stock move line
opw-3710125
closesodoo/odoo#160533
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce:
1. Go to IoT > Devices
2. Select a device and add the report "Lot/Serial Number (ZPL)"
3. Create a product tracked by lots
4. Purchase 5 units of this product
5. Validate the reception (with a lot)
6. Print labels > Lot/SN Labels
- Quantity to print: One per unit
- Format: ZPL Labels
Before this commit:
When printing labels for multiple lots of the same product, the wizard
was incorrectly generating the docids as a `list[list[int]]`. It works
correctly as the ids are joined thanks to JavaScript magic. However,
when sending the report to an IoT device, the ids are sent as-is in
the context, which raises and error when calling `browse()`.
After this commit:
The docids are now generated as a flat list of integers, which is
correct and works as expected.
opw-3850631
closesodoo/odoo#162063
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Signed-off-by: Walravens Mathieu (wama) <wama@odoo.com>
In this commit:
===============
printer icon will visible based on printer configuration
task - 3869678
closesodoo/odoo#162056
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
To reproduce:
* Add a bank account to Employee, and a bank account to your company.
* Set the company on the employee's contact to yours.
* Create an expense to be reimbursed to the employee, submit it and try
to "Register Payment".
Current behaviour: the recipient bank account in the wizard is set to
the company's.
Expected behaviour: the bank account in the wizard should be set to the
employee's bank account.
This commit solves this.
task-3837305
closesodoo/odoo#160749
Signed-off-by: William André (wan) <wan@odoo.com>
After the portal redesign, messages for no quotations or sale orders
were moved before the portal_table template, which is called when there
are entries of quotations or sale orders. However, the previous version
of the message for sale orders was left after the template call.
This commit removes the previous version of the message to avoid having
duplicated messages.
closesodoo/odoo#162546
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Fix errors in some of the spanish invoice_labels for withholding taxes.
Thanks to @AlmustafaNET odoo/odoo/#147867
closesodoo/odoo#162447
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Current behavior:
When generating a sale report for multiple pos sessions, the payment
name is not clear which session it belongs to.
Steps to reproduce:
- Open PoS and make some sales
- Close the session, and do the first step again.
- Go in reporting and generate the report for a period that includes
the two sessions.
- In the payments table you will see the payment name, but you won't
know which session it belongs to.
opw-3684937
closesodoo/odoo#162440
X-original-commit: 77c95c2588c3af02e6f96cd03c289671c775c0e8
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Prior to this commit, the presence of an invalid order in the browser
cache could prevent the PoS from loading. This issue typically arises
after a database upgrade, where changes in fields can render unpaid
orders in the cache unloadable. This commit resolves this issue by
discarding any problematic unpaid orders that can no longer be loaded.
opw-3874858
closesodoo/odoo#162408
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Current behavior:
If you create a user that only have access to a branch of a company.
If this user try to access the QR Menu of any PoS he will get an access
error.
Steps to reproduce:
- Create a branch B for company A
- Change access of user U to only have access to branch B
- Login with user U, and try to open any PoS QR Menu
- You get an access error
opw-3745256
closesodoo/odoo#162222
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
While updating the checkout page an element was changed from div to t
To handle the intermediate value used by users who installed this version
a new selector was added to the xpath to account for both cases
Previous commit that was trying to fix the same issue 12e5296c1dclosesodoo/odoo#162064
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Some parts of the translation were missing and Romanian isn't available
as a language in Transifex for this version. Therefore we add it in now.
English grammar mistakes of original string are left untouched.
closesodoo/odoo#162469
X-original-commit: f19e872698d17b93da3c2e1a3eafb20a4d098660
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
When registering payment for customer invoices and vendor bills at the same time, a misleading error message appears"You can't register payments for journal eithers being both inbound and outbound".
Replacing it with a clear message "You can't register payments for both inbound and outbound moves at the same time."
Task id: 3638740
closesodoo/odoo#162464
X-original-commit: a18cb2ebb133c2e4b72ddd5d8cda23d2b71006dd
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Seif Gneedy (segn) <segn@odoo.com>
Steps to reproduce
==================
- Create two new storable products tracked by USN
- Create a new RFQ with one of the created product
- Confirm the order
- Open the receipt
- Add a new line with the other product
- Click on the open move button in the new line
- Add a new SN
- Save & close
=> Cannot read properties of undefined (reading 'resId')
Cause of the issue
==================
When calling openRecord, if the record is dirty, it is saved before
proceeding.
After saving, we call super.openRecord with the old record.
Since that record is no longer linked to the root record (the
stock.picking), when we try to save it, it won't match an existing id.
Solution
========
If the record is new, we don't save as there would be no way of knowing
which of the returned line would come from this one.
If we are opening an existing record, we find the new datapoint by
matching it's ID.
opw-3777615
closesodoo/odoo#162425
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce the issue:
1. Create a Storable Product and give it a UOM
2. Create an On Hand stock in a certain location
3. Go to Barcode and create a new Internal Transfer
4. Add the Product and with any quantity and click on Confirm (not Validate)
5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm
6. Validate the Transfer
7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button
8. The reserved quantity is not null
Explanation:
When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes:
- In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards.
https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61
When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`.
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422
(e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)
- There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`.
(e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)
Suggested fix:
There is a first check to make sure one of the values has changed, then each one will be assigned through a condition:
- The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called.
- The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute.
opw-3798046
closesodoo/odoo#162380
X-original-commit: 2b8e073d082620ca3ac2342fa12c7f93a07335d1
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>
How to reproduce:
1. Go to any course
2. Click on the button 'Add attendees'
3. Type the recipients name
"Create and edit ..." should be displayed but is not.
To reenable this feature, we remove the option no_create_edit on partner_ids
of the slide_channel_invite_view_form form to enable the creation of partner
when adding attendee to a course.
As the support for the force_email context has been discontinued, we don't
reenable the quick_create as it can create partner without email (if the user
enter a non-valid email). But we reenable the "create edit" option with a view
that force the user to enter an email: base.view_partner_simple_form (like
done on some views in odoo/odoo#149806).
Task-3868824
closesodoo/odoo#162190
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When changing `groupby` we want to also update `user_groupby` to avoid
raising `_validate_groupby_no_child` or `_validate_formula`.
It can always be set independently after.
Detected while upgrading `account_financial_report_it_sp` because
`<field name="groupby" eval="False"/>` was set in the data but
`user_groupby` was never updated. (but the constraint was triggered
because of the write)
Note that the constraint was not fired when needed either.
closesodoo/odoo#160301
Related: odoo/enterprise#60420
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side
This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)
when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.
closesodoo/odoo#157664
Task: 3681668
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Currently, an error occurs when the user tries to add an order with toppings.
This is because before 17.0, [1] got values like `[6, False (1, 2)]`, where
we found the `values['topping_ids_1'][0][2] (ids (1,2))`. But after 17.0,
[1] got values like `[[4, 1], [4, 2]]`. As a result, it cannot be found in
the `[0][2]` index at [1].
This commit fixes the above issue by using 'convert_to_cach()', which returns
the ids from [[4, 1], [4, 2]]. Apart from that, this commit also improves the
code by adding a loop to get topping IDs for each topping.
[1]-https://github.com/odoo/odoo/blob/039407cf2954ce6298aa8af7aff251a1cefdc39b/addons/lunch/models/lunch_order.py#L99
sentry-4627940064
closesodoo/odoo#142701
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.
**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.
**Steps to reproduce:**
1. In settings, go to the email templates management page
2. Select the Survey: Invite template and upload some
attachment
3. Go to the Survey application and click on one of the surveys
listed, observe the lack of attachments despite having the
email template with the attachment selected
**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.
**Fix:**
Make the attachment_ids field a stored computed field.
opw-3709830
closesodoo/odoo#162499
X-original-commit: 1fcc11a2ca8e18d10eaac51ce20773596db183e2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Vincent Ethan <etvi@odoo.com>
Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund.
This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund.
Steps to reproduce:
-------------------
* Setup a rounding method with a precision of 5.0
* Create a product with a price of 138.0
* Open the POS and add the product to the order
* Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80.
* Validate the order
* Go in the backend and refund the order
* The refund will be rounded to 135.0
Why the fix:
------------
The new behavior after this fix:
* When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding).
* When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected.
The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined.
Since this is a rare event, we consider this difference to be acceptable.
Post-fixup:
-----------
The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore.
opw-3701574
closesodoo/odoo#162416
X-original-commit: f8e78cdee3dac64a3ac3d8da529aea398cdb7393
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Sarah Bellefroid (sbel) <sbel@odoo.com>
Co-authored-by: Robin Engels <roen@odoo.com>
At the moment, if EMV QR is selected on the invoice where the country does not support EMV QR an error is raised.
However, this error is also raised if EMV QR is selected but the bank account is not set. The following error is raise
`No EMV QR Code is available for the country of the account False.`
This commit adds a check to ensure the bank account is set and raise a better error message.
Task# 3868467
closesodoo/odoo#162500
X-original-commit: e6ca281b691e75dd9c12fb110f80f444c21729de
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo.
The test was failing because of the following:
when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`.
However the list of `event.attendee_ids` is ordered by create_date.
And we create both organizer and attendee with the same command at the same time: `partner_ids=[Command.set([self.organizer_user.partner_id.id, self.attendee_user.partner_id.id])]`
So we might have organizer at index `1` and invited attendee at index `0`. This resulted in the indeterministic behavior of the test.
To fix this issue:
This commit changes how the invited attendee is retrieved, making sure that we always get the right attendee.
fixes runbot-61527
closesodoo/odoo#162279
X-original-commit: 6db2614283abfc035343f021b9cfc52609aa9d44
Signed-off-by: Ahmad Almaghraby (alah) <alah@odoo.com>
Actually if a server is not configured we can click on it and
we are redirect to not reachable page
With this commit it is not possible to click if server is not configured
closesodoo/odoo#162372
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
When the iot run without server we display an certificate error.
This error is useless because we can't get a certificate without server.
Some customer a worry about this error
With this commit we hide this comment if we not connected to a Odoo server
closesodoo/odoo#162371
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.
Task-3761551
closesodoo/odoo#162106
X-original-commit: 5b38d58db1bb7cacd2a5ffa195a3799f2645fdbb
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Mohammed Basioni (basm) <basm@odoo.com>
Prior to this commit, some attributes such as "data-tooltip" were not
exported in /static/src/ templates, while "label" was only exported in
them.
This commit adjusts the code to use the same list of translated
attributes everywhere, fixing the problem and making it less likely to
happen again.
Task-3872895
closesodoo/odoo#162250
X-original-commit: 6c272a432cea29fa98d9f2a3e4f454214099f3e6
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Given the changes in [1] and subsequently in [2], which in some way
counteract the RTL adjustment, it is necessary to eliminate the rtlcss
directive from the carousel CSS to ensure the correct behavior.
Steps to reproduce:
- Enter in edit mode.
- Drag and drop an image gallery and a carousel snippet.
- Navigate to the theme tab.
- Add an RTL language (Arabic, for instance).
Bug :
- The images slide in incorrectly during transitions. In RTL mode, when
clicking on the left chevron, the next image should appear, not the
previous one.
If we have three slides numbered 1, 2, and 3
- In RTL mode: Clicking left should navigate from 1 to 2 to 3 and then
back to 1.
- In non-RTL mode: Clicking left should navigate from 1 to 3 to 2 and
then back to 1.
The directional Font Awesome icons (classes starting with `fa-` and
ending with `-right` or `-left`) are not flipped in the mobile viewport
as a result of [3]. Necessary adjustments have been implemented
to prevent this behavior.
Upon investigation, a more significant bug was discovered regarding the
'oi-...-[right/left]' icons. These icons were not flipped appropriately
in the frontend when the webpage context was set to an RTL language. A
pull request has been created and merged to address this issue [4].
More info on rtlcss [here]
[1]: https://github.com/odoo/odoo/commit/ebb61753bf3d3dd8d3f53db088112b9e4beb813d
[2]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[3]: https://github.com/odoo/odoo/commit/be375bb2a886edd002f042355455a71fcac4daf5
[4]: https://github.com/odoo/odoo/pull/157214
[here]: https://rtlcss.com/learn/usage-guide/value-directives/#tip
opw-3747848
closesodoo/odoo#162202
X-original-commit: 7f0f750b0d9e45982130742af2ac396d1985612e
Related: odoo/enterprise#60922
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to reproduce:
1- Create an allocation with validity date (e.g. 01-01-2024 -> 30-06-2024)
and another one starts after the first one (e.g. 01-07-2024 -> 31-12-2024)
2- Go to Time off module and select a date in the second allocation's period
3- Click on the Time off type dropdown menu
4- You will see the first allocation displayed not the second one
Current behavior before PR:
The display name of some leaves gets computed in a wrong way.
This is happening because after fetching the right allocation
we compute the display name but this time we don't have
the 'default_date_from' in context so since
it became one of the fields that triggers '_compute_leaves'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L218:L219
we compute the leaves once again but the target_date will be none
and it will get assigned with today's date in 'get_allocation_data'
https://github.com/odoo/odoo/blob/17.0/addons/hr_holidays/models/hr_leave_type.py#L380:L381
Desired behavior after PR is merged:
This has been solved by saving the date attribute in the context
with another name as when computing the display_name we call sudo so clean_context()
removes the 'default_' context keys. Now when it gets removed we are
going to have the same value but with another name.
opw-3797696
closesodoo/odoo#159917
Signed-off-by: Youssef Bashandy (yoba) <yoba@odoo.com>
Steps:
- Install sale apps.
- Upload a header file from settings with xyz.pdf for
example.
Issue:
- Header/Footer file is not updated according to uploaded
file name.
Cause:
- Header/Footer file name in setting is related and
readonly is should not be readonly in order to update
header file name.
Fix:
- Make settings header/footer file not readonly to
set proper updated file names.
task-3620555
closesodoo/odoo#152007
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In Shop Floor, consuming less tracked by lots components than expected
gives an 'Invalid Operation: lot/serial number needs to be specified
for a tracked product' error.
Discarding the dialog to fix the quantities makes the production order
disappear from the Shop Floor.
This because of the MO Readiness filter: as the move becomes partially
available, the reservation state goes to confirmed rather than assigned.
closesodoo/odoo#144718
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Currently restarts of the odoo server do not happen at
the end of the installation of all components. The devices are therefore not detected.
With this commit we restart the server when all the components have been installed
closesodoo/odoo#162362
Signed-off-by: Yaroslav Soroko (yaso) <yaso@odoo.com>
Prior to this commit, if a product had multiple attributes, each
attribute would be displayed multiple times in the order line. This
commit resolves this issue by ensuring that each attribute line is
displayed only once.
opw-3849701
closesodoo/odoo#162258
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Start a SMTPS server with client certificate authentication. In Odoo
configure an outgoing mail server with encryption="ssl/tls" and
authentication="certicifate". Load a valid client certificate and key to
use with the SMTPS server then test the connection.
The connection fails because the client certificate wasn't sent during
the TLS handshake.
If you're having trouble running a SMTPS server, I made a script here:
https://gist.github.com/Julien00859/5090d1cff6c02197e5854aabb67bf5ac
It uses aiosmtpd, a light pure python smtp server, install it with pip.
You'll need to copy your snakeoil ssl key + cert inside your /tmp
directory and to expose them to your current user:
# public cert
cp /etc/ssl/certs/ssl-cert-snakeoil.pem /tmp
# private key
sudo cp /etc/ssl/private/ssl-cert-snakeoil.key /tmp
sudo chmod 400 /tmp/ssl-cert-snakeoil.key
sudo chown $USER /tmp/ssl-cert-snakeoil.key
task-3703209
closesodoo/odoo#162297
X-original-commit: b3d7c1fc9c017a4354dc4a6f8abfbf590bc26a51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No rounding in the query used to map sale.order.line to
the hr.expense, models leads to some records not being able
to be linked together, because of floating point errors.
Adding a rounding to the key price_unit,
and not filtering on price_unit. Then, using the rounded string versions
of the price_unit in the comparisons adds a more reliable approach.
task-3705179
closesodoo/odoo#162245
X-original-commit: 0f4705be195ac66e1cdf5af39fd509035929556c
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Currently, recalculating `analytic_distribution` requires access to
`account.analytic.distribution.model`. This breaks BoM creation for
non-accounting users (e.g. MRP managers). This commit fixes the issue by
using `sudo()._get_distribution`.
closesodoo/odoo#162184
X-original-commit: 3872e9365e4d8cc100a6022e934292f6f6802162
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Pawel Fertyk (pafe) <pafe@odoo.com>
Previously, when the odoo server was running on some Windows
installations, it was possible for javascript files loaded directly from
the static folder of an addon to fail to run because the Content-Type
header was set to text/plain instead of text/javascript. This is because
the mimetypes module from the standard library honors the mimetypes from
the OS, in the case of Windows it reads a key in the registry, which can
be misconfigured to text/plain for .js files.
This commit forces the mimetype of .js files to text/javascript to solve
this issue.
closesodoo/odoo#162313
X-original-commit: 64cbe389e698398eee93ebde9c61b2ee79756380
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Since [this other commit], web_editor can call IAP to generate text via
chatGPT. Unfortunately, an unnecessary param (`version`) was given to
IAP leading to a warning on the IAP side
`generate_content_from_conversation> called ignoring args <version=X>`.
This commit removes this useless param.
[this other commit]: https://github.com/odoo/odoo/commit/386a2fdebf429b0318473e596ed9ac0966d9a8b5
Related to task-3383324
closesodoo/odoo#162249
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Commit f0016849 added the module `sale_async_emails` but not the .pot
file.
closesodoo/odoo#162215
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Maximilien (malb)
