Currently, if a customer wants to edit his/her information from the
Portal access, they cannot modify the information linked to EC.
This commit aims to support Ecuadorian companies needed information when
editing the portal contact information:
- added "Identification Type" field
- renamed "VAT" to "Identification Number"
- make those 2 fields required
closesodoo/odoo#142730
Task-id: 3620196
Signed-off-by: Josse Colpaert <jco@odoo.com>
Currently the eCommerce workflow in Ecuador lacks some information
needed to issue EDI invoices.
The main adaptions needed are:
* Identification type and number in the checkout process (in the billing address)
* SRI Payment Method in the eCommerce Payment Method
SRI Payment Method
* The SRI Payment Method value is required for the EDI
* In the payment method form view the SRI Payment Method field is hidden
if the list of fiscal countries of the selected companies does not include Ecuador.
* Payment methods which do not have an associated SRI Payment Method
cannot be used in the eCommerce checkout of an Ecuadorian company.
* A (default) SRI Payment Method has been addeded to some payment methods to simplify the setup.
* When creating an invoice from a sales order we try to compute the SRI Payment Method as follows:
We consider all the SRI Payment Methods of the payment methods of the payment transactions associated with the sales order.
If there is exactly 1 such SRI Payment Method we use this on the invoice.
This should ensures that we can always set the SRI Payment Method on invoices created through the eCommerce flow.
task-3585823
Part-of: odoo/odoo#142730
In Ecuador, the ZIP code is not a required field to create invoices.
Customers usually don't even know their ZIP code as the street number,
city and state (province) are mostly used for delivery (and not the
ZIP code).
task-3585823
Part-of: odoo/odoo#142730
Confirming a repair order with parts assign moves quantities.
Ending it without any of the picked flags automatically pick them.
But ending it with some non-picked parts does not cancel the moves.
Now they are.
closesodoo/odoo#149157
Task: 3679247
Signed-off-by: Steve Van Essche <svs@odoo.com>
Before this commit, there was a race condition with the statusbar
field, and more specifically with useRecordObserver.
The issue could be reproduced in the form view of project.task. In
an existing task, belonging to a project with some stages, change
the project to another project with its own stages. It might happen
that the displayed stages weren't the ones of the newly set project.
If this didn't happen directly, this happened upon saving (i.e. the
correct stages are displayed just after switching the project, but
as soon as the user saves the record, the former stages are back).
This happens because useRecordObserver used an outdated version
of the props to get the domain (i.e. the props of the component
have been updated, but useRecordObserver still used the old version,
in particular the old props.domain).
This commit fixes the issue by ensuring that we always use the last
version of the props.
opw 3693113
closesodoo/odoo#152433
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Purpose
=======
From O.6 to 0.04 seconds to call get_allocation_data_request (15x faster)
and 574 to 25 requests for an employee with 10 years of XP in odoo.com.
Part-of: odoo/odoo#152311
Before this commit, discrepancies between
leaves and allocations for an specific employee
and a specific time off type would have prevented
the employee from taking any time off for that
time off type.
It would also affect their dashboard.
__How to reproduce the issue:__
- time off type without negative amount
- create 2 allocations: last year and this year
- create a leave last year
- remove last year allocation from DB
- you cannot take leaves this year
- dashboard amount is affected by last year's leave
__Changes brought with this commit:__
This commit keeps the logic identical for negative
time off types. However, for the others, the
check ensuring the allocation validity for the
leave will now check the discrepancies before and after
a time off creation or modification. The error
will be thrown if the discrepancies have changed, meaning
that the leave had an effect on it. This way, any
other issue will not prevent leave creation.
Those leaves are still noticeable through the warning
though, meaning that they can be noticed and dealt with
accordingly.
Part-of: odoo/odoo#152311
The address displayed as 'Invoicing address' was
the main SO address and not the invoicing one.
Also, the pencil icon link to update the customer main address
was always displayed next to the invoicing address, even if:
* the so does not belong to the customer
* the invoicing address is different than the
customer main address
This commit fixes those two issues.
opw-3653190
closesodoo/odoo#152298
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The total amount is computed by adding the order amount and the delivery amount. The order
amount was provided as a string, and the computation didn't convert it to a number before
adding it to the delivery amount. As a result, the amounts were concatenated instead of
added, yielding an incorrect result.
opw-3614909
opw-3664682
closesodoo/odoo#152416
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Appending strings within a `t-out` for a website template makes it so
that it can never be translated. Instead the string should be written
like normal text so that it is correctly seen as to be translated and
`t-out` only the next step so that it's also correctly matched as to be
translated.
opw-3700815
closesodoo/odoo#152312
Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>
Steps to reproduce:
1) Try to make a payment with the amount less than 0.50$ (minimum amount
required in Stripe)
2) Stripe inline form fails to load
3) One can still click pay and see the traceback
After this commit the error are handled and displayed on the form
loading and on the form submit.
opw-3634316
closesodoo/odoo#152307
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
In order to better analyze profitability, we added an extra measure to
the Invoice Analysis report to show the "Margin" on every invoice line
based on the product cost price.
In order to have a simplified inventory valuation without fully using
the Inventory app, we also added an "Inventory Value" measure that also
uses the product cost price to show the change in inventory value based
on incoming and outgoing accounting documents.
An extra filter "Inventory Valuation" was added as well to show the
"Inventory Value" values per storable product and per month.
task-3708415
closesodoo/odoo#151805
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
With Kenya localization installed
Create an invoice
Send&Print
Issue: The sytem will issue the final pdf before the invoice has been
send to the fiscal device, so the legal information is actually missing
Solution:
1. If the allow_fallback_pdf is True (in case of transaction from the
e-commerce for example) we generate a proforma pdf invoice.
2. Else we raise an error to prevent the user to send invalid invoice.
Also added a warning to let the user know that a proforma will be
generated because the invoice was not sent to the Fiscal Device.
opw-3599869
closesodoo/odoo#151751
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
Co-authored-by: Claire Bretton (clbr) <clbr@odoo.com>
Force post does not work in the validate account move wizard.
Steps:
- Create a move in the future and set it to be auto post
- On the list view, select the move and select action "post entries"
- On the wizard, check "force" and validate
-> UserError "This move is configured to be auto-posted ..."
closesodoo/odoo#152396
X-original-commit: f85f3bcc026882b2a088fcd46ca8e6dc59d6f2f0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
Thanks to changes in 82314364c6029a83 the auto-lock settings
also works for public users. But, going from self.env.user to
self.create_uid to check the group lead to a traceback when
self.create_uid is not a singleton. This is because has_group expects
a single record.
To fix that, this commits checks the group of the create_uid of the
first record in self. Because sale.group_auto_done_setting is an
implied_group of a res.config.settings parameter, it's enough
to only check for the first record in the recordset.
To reproduce:
- Install sale
- Create a quotation as Mitchell Admin
- Create a quotation as Marc Demo
- Create a cron that searches on all draft sale.orders and confirm them
in batch
- Run the cron
-> Singleton Error
closesodoo/odoo#152338
X-original-commit: dfb2eaaaf5c08c0aa46cc5eb0defdc97b35953b0
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Aurélien van Delft (avd) <avd@odoo.com>
Before this commit:
- In the project module, when a user opens the color picker, it opens as
a dropdown even if there is not enough space available, resulting in
some parts of the color picker being inaccessible.
- In the project, when a user opens the color picker a second time, it
always opens as a dropup, even if there is space available for it to
open as a dropdown.
After this commit:
- Now, when a user opens the color picker, it opens as a dropup when
there is not enough space available for the color picker to open as a
dropdown.
- The color picker will open as a dropdown when there is enough space
available.
task-3608803
closesodoo/odoo#152337
X-original-commit: b60aa4f4effcec38d0e18707ce268c0cc07a2515
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
In form views, when the user closes the tab while having unsaved
changes, and if those changes are valid, we want to save them
automatically before leaving.
Before this commit, there could be situations where the changes
weren't actually saved. For instance, if they involved an heavy
payload for the write rpc, or if the network connection was poor,
it might happen that the xhr is killed. Or at least, browsers do
not offer any guarantee to wait for those xhr to reach the server.
Instead of a classical xhr, we thus use navigator.sendBeacon which
ensures that the data will be sent reliably [1]. There's a drawback
though, as its payload is limited. When the payload is too heavy,
sendBeacon simply returns false and does nothing. In this case,
we prevent the page from unloading and display a notification
suggesting the user to manually save his changes before leaving.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon
Task 3537838
closesodoo/odoo#151834
X-original-commit: 0b53daa60ee5b370def21c8e0e30a6819597a0e4
Related: odoo/enterprise#55457
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
When a customer sends a message to Odoo via WhatsApp, their number is saved in the `phone.blacklist` model, but the active state is set to False. If the customer sends 'STOP', it will be set to True, and if the customer sends a new message, it will again be set to False.
Before sending a message from Odoo to a customer via WhatsApp, we check if the number is in the `phone.blacklist` with this line in whatsapp_message.py
if self.env['phone.blacklist'].sudo().search([('number', 'ilike', number)]):
In SaaS 16.4, this line returns the following SQL request:
SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE (("phone_blacklist"."active" = true) AND ("phone_blacklist"."number"::text ILIKE '%32491730941%')) ORDER BY "phone_blacklist"."id";
Here, we check if the Active state is True to block the message if necessary.
In 17, this same line returns this SQL request:
SELECT "phone_blacklist"."id" FROM "phone_blacklist" WHERE ("phone_blacklist"."number"::text ILIKE '%32491730941%') ORDER BY "phone_blacklist"."id";
I correct it in a PR https://github.com/odoo/enterprise/pull/55498
But if we go further we find that it's really because of the active_test = False of this line in thread.py
thread = request.env[thread_model].with_context(active_test=False).search([("id", "=", thread_id)])
from this commit
https://github.com/odoo-dev/odoo/commit/8b2605b99348b7707b3db3db46af880c17c7029c
with the fix of this PR, the discussion on Whatsapp is now possible and we keep the fix of the previous commit.
opw-3704136
closesodoo/odoo#152273
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
When in a checklist where first and second checklist are marked done after
selecting first and second checklist and deleting it the third checklist would
be marked as done.
After this commit:
Deleting previous done checklist would not affect the current checklist.
task-3203889
closesodoo/odoo#152387
X-original-commit: 2ddda7a66076ef99e1aa4ba9d463b0fd2f73626d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Deependra Solanki (deso) <deso@odoo.com>
Commit [1] introduced a way to "hide" an ir.ui.view through a new
visibility field.
That field has multiple possible values to restrict the access. One of
those is "Restricted Groups", but when selected it's really hard to
figure what to do next because nothing happens on screen: there is no
"groups" field where to add the groups.
Those groups should actually be added a bit below, in the groups_id
field which is "hidden" inside the "Access Rights" second tab.
This is because the groups_id field already existed (in base module)
before introducing the website visibility feature which just relied on
that field when set to "Restricted Groups".
Note that another possible value for visibility is "Password", and in
this case a password field appear below the visibility field as one
would expect.
[1]: https://github.com/odoo/odoo/commit/e239934abe456257c9dc285d1ad9829c0353900cclosesodoo/odoo#151602
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit's purpose is to fix the display of the default field when
entering studio mode from a task form with no allocated time.
Step to reproduce :
-open project
-open office design
-create new task/select a task with 0 allocated hours
-open studio
the display of the field 'allocated time' is partially hidden by the
span 0%
Source of the bug:
the widget timesheet_uom_no_toggle has a max width of 7CH, which is too
little to allow the full display of the default name.
Solution:
Create and add a new scss class which is only active in studio mode.
Version affected:
saas-16.2 to master
task - 3553101
https://www.odoo.com/web#id=3553101&menu_id=4720&cids=1&action=333&active_id=4105&model=project.task&view_type=formclosesodoo/odoo#152159
X-original-commit: 30092f7a67579551ac3fb7a7d5668699cae8b3aa
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
In Language settings, change decimal separator to ','
Go to Journal Items
In the search bar input '4,50' and search for 'Amount'
Error: ValueError: could not convert string to float: '4,50'
This occurs becuase when the search component assemble the domain for the
orm we use the original string '4,50' and not the parsed value '4.5'
opw-3700578
closesodoo/odoo#152075
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
9e0277e changed the reporting from users to employee and the user field was removed
but a record rule was forgotten.
opw-3653746
closesodoo/odoo#151992
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
When the user passes a wrong domain in the record rule, the system allows users
to save that record without checking whether the new domain is correct or
incorrect.
steps to reproduce:
- create an ir.rule on res.users and write a domain with a typo
before this commit:
- users can't log into odoo
after this commit:
- an error is raised to prevent saving a bad domain
opw-3653746
X-original-commit: dc8dfc246d3de9d447a360f15f41f2388ac8d638
Part-of: odoo/odoo#151992
Steps:
- In mobile install project
- Project.project form view
- Go to the project settings
- In Alias Domain(Custom Email Servers)
- The input alignment is not good
Issue:
- The input should go under the alias domain in project.project
form view in mobile
Cause:
- Here they adding extra bootstrap class so that's why it will be
showing in correctly
Fix:
- By removing the bootstrap class of 'oe_inline' the problem will be solved
task-3550702
closesodoo/odoo#151829
X-original-commit: 2819d6e076404140f5c26e76829a8f5bb171cf14
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Since https://github.com/odoo/odoo/pull/1432[FIX] base/models: Prevent incorrect behavior in `_read_group_format_result`
To reproduce the problem, you need to ensure that a read_group returns several groups,
with the first element being a group with no value if you choose to group on a many2many (see test).
Here's an example to reproduce in website_sale:
- Install `website_sale` without demo-data
- Go to `eCommerce/Products`
- Create a new product
- Go to `Sales` tab in the product form view
- Set a new `eCommerce shop/Categories` like `Sales`
- Save
- Return to `eCommerce/Products`
- Remove default filters
- Group by `Website Product Categories`
- There are two group: `None` and Sales`
- Click on None
- Traceback
In this case, the orderby is website_sequence:sum ASC,
and will therefore return as first group None containing `Delivery Product`
and as second group `Sales` containing the newly created product.
What happens is that `read_group` will build `rows_dict` thanks to `_read_group`.
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2724
this `rows_dict` will be ordered according to `orderby`and then passed as an argument to the `_read_group_format_result` function
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2759
For each row, this function will convert `row[group]` (group in this case is the many2many field)
into a tuple containing (id, displayname) in case the value (`row[group]`)
is found which will be used to build the domain `[(field_name, =, value)]`.
So, for example, replacing
```py
rows_dict = [
groupbyField': odoo.model(1),
groupbyField': odoo.model(4),
]
```
with
```py
rows_dict = [
groupbyField': (1, 'First record'),
groupbyField': (4, 'Fourth record'),
]
```
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2460-L2462
If the value is False, we'll use the 'not in' operator instead.
To do this, we need to retrieve the ids of all the other groups to
include in this one all the records that aren't in any group,
either by retrieving the id if it's a model,
or by retrieving the first element of the tuple if it's already been modified,
or by directly retrieving the value of the field if it's not a many2x.
Except that if the first element is directly a group without a value,
it won't be able to retrieve the values of the other groups,
because the condition for checking that it's a `BaseModel` instance contained a typo
https://github.com/odoo/odoo/blob/cb67b4e1472ae6689e943ade1e27cb43e8d87025/odoo/models.py#L2465-L2467closesodoo/odoo#151497
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This is a backport, with the original commit occurring in master:
e80f5e3.
The motivation for backporting these states is that they're useful in
the upcoming eTIMS OSCU integration for Kenya, which targets version
17.0.
Added Kenyan states as per https://www.iso.org/obp/ui/#iso:code:3166:KE
Task ID: 3665315
closesodoo/odoo#152256
Signed-off-by: Josse Colpaert <jco@odoo.com>
Logo on pdf send to customer after generating coupon code was disorted if
it was not in certain ratio.
task-2588963
closesodoo/odoo#152245
X-original-commit: b1b94a075672067325ddcc125cbc57ae214b0a9a
Signed-off-by: anko-odoo <anko@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to Reproduce
==================
1). Create an empty quotation and link it to a mass mailing
(same medium and source).
2). Open the mailing form, the stat button displays "1 Quotation"
3). Click to open it
-> Empty Screen
Technical
==========
There are no records in this view as it is based on the sales report model.
If a quote has no line, there is nothing to display.
After this commit
=================
Now empty quotes will not be counted.
Task-3635429
closesodoo/odoo#152241
X-original-commit: 05c2859ccebcfc60e27a4833c57f98c2d7944bbb
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
If reordering rules' visibility is set bigger than DAYS_FROM_TODAY_TO_ORDER
(plus lead time). Then the order should be included in the calculation of
quantity to order.
┌─ Today ┌── Scheduled Delivery
│ (2024-01-01) │ (2024-02-01)
│ │ aka commitment_date
│ │
▼ ▼ time
──────────────────────────────────────────►
◄────────────────────────────►
DAYS_FROM_TODAY_TO_ORDER
◄────►
lead_time
Before this commit visibility_days were taken into the account only if
there forecasted quantity was lower than product minimal quantity. This
commits ensures that the visibility_days will always be included into
the calculation.
[Reproduce]
- install stock,purchase,sale_management
- Create a product P (storable)
- Add vendor V under the purchase tab
- Create Reordering with route buy, vendor V, min 0, max 0
- Create a Sale Order for 1 unit of P, under the 'Other Info' tab, set the Delivery date to 1 month in the future, Confirm.
=> If you go back to the reordering rule, you have Qty To Order at 0 (ok)
- Set Visibility Days at 40
=> Qty To Order is still at 0, even though it should now see the sale order we made before (bug)
- Set the Min qty at 1
=> Qty To Order is now at 2, it found the sale order we made, and computed the correct quantity. (ok)
- Set the Min Qty back to 0
=> Qty To Order is back at 0 (bug)
opw-3638398
closesodoo/odoo#152167
X-original-commit: 8a5541d16caa793c7549d78c082f7879d3aba233
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Andrzej Pietrusiak (pian) <pian@odoo.com>
Commit that introduced the issue: fbc167bf84340b4bb6d0f8c59f2734814f56c6df
Issue:
======
Adding a table in a long chatter message with scroll raise a traceback
Steps to reproduce the issue:
=============================
- Switch to RTL lang
- Go to any form view and open the editor composer to create a log note
- Write a lot of lines so that the scrollbar appears
- Add a table
- Log the note
- Try to scroll -> traceback
Origin of the issue:
====================
The `_onScroll` method is called and it has `this._rowUiTarget` as the
row from the composer dialog which is not in the ui anymore so
`closestElement(row, 'table')` will return `null`.
Solution:
=========
We just do nothing when the element is not connected.
task-3707808
closesodoo/odoo#151800
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Steps to reproduce:
- Enable Automated Valuation.
- Set the cost of Acoustic Bloc Screens to 287.33.
- Set the Product Category on the product to have AVCO automated valuation.
- Enable Cash Rounding.
- Create a Cash Rounding (see tests).
- Make an invoice selling one Acoustic Bloc Screen and remove the tax.
- Set the Cash Rounding on the invoice under "Other Info".
- Confirm the invoice.
Bug:
when summing the ammount of all the lines the result is slightly off
(float accuracy) this will create an unnecessary cash rounding to
compensate
Fix:
round the sum to the currency precision before checking for the cash rounding
opw-3681307
closesodoo/odoo#152112
X-original-commit: 4a6ec1a667ee3d2fba00d277b4c7e8a730a45ecd
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Current behaviour:
When planning more than 88 work orders,
there is a recursion error.
Steps to reproduce:
1. Go to Manufacturing
2. Operations > Manufacturing Orders
3. Create a manufacturing order
4. Add 90 work orders
5. Click on Confirm
6. Click on Plan
7. Recursion error
Cause of the issue:
Maximum depth of the Python interpreter stack
The recursion limit being set at 1000
by default (with getrecursionlimit)
Fix:
Upped the limit to ~320 work orders
opw-3651494
closesodoo/odoo#152198
X-original-commit: 25081646ef0b679356ad46f62fe737fb44269baf
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Co-authored-by: Rémy Voet <ryv@odoo.com>
Issue:
======
Discard changes of form having html field doesn't remove the changes
applied in the html field.
Steps to reproduce the issue:
=============================
- Open any mail template
- Add modification on the template
- Click on discard changes
Origin of the issue:
====================
The function `this.props.update` is responsible of updating `_changes`
and updating the record which is called for usual input_field using
`useInputField` hook, but since this html field isn't of the same format
we didn't use it and it's only called in `commitChanges`
Solution:
=========
We update the value of in `_onWysiwygBlur` in case we are `inlineStyle`
so we don't commit but we save the changes for the discard to work
properly.
task-3453497
closesodoo/odoo#151993
X-original-commit: 1624da6f42561792be816836c6d88bc986c3538a
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Forgot to update the test so that it tests both warning and success
notifications.
closesodoo/odoo#152186
Signed-off-by: Laurent Smet (las) <las@odoo.com>
When fields are submitted through the website form, their values are
used as they are. Because of this it is possible to include HTML in the
sent email while this is not desired.
To avoid this, this commit HTML-encodes the values received for custom
fields and html fields.
Steps to reproduce (with default_field):
- Go to the "Contact us" page with form untouched (it should send mail)
- Fill in the form
- In the name put John <b>Smith</b>
- Submit the form
- You will see that Smith will be in bold in the received mail
Steps to reproduce (no default_field):
- Install website_recruitment
- Go to the "Contact us" page
- Enter edit mode
- Change the form type to apply for a job (and select a job to apply in
the right panel option, like "Consultant")
- In debug mode in the backend, go to ir.model fields
- Find "Applicant (hr.applicant) record and edit it
- Remove the website_form_default_field_id in the "Website Forms" tab of
the form view of this record
- Back to the "contactus page", add a new custom field to the form
- Now, out of edit mode, add "<b>Something</b>" in the custom field and
submit the form
- Find the job application in the backend in the recruitment module, it
should be inside the "Consultant" job.
- You will see the "Something" in bold in the chatter
Note: In Odoo 16.2, commit [1] is already doing something similar for
one of the 2 places fixed here.
[1]: https://github.com/odoo/odoo/commit/3e7acff8d9302c3332fe3011f75374170484c61d
task-3650953
closesodoo/odoo#152170
X-original-commit: c2e934f421a8afee4ce537b1e03871a1bcef99d1
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Bram Van Gaal (brvg) <brvg@odoo.com>
Co-authored-by: bram1000 <brvg@odoo.com>
Co-authored-by: Benoit Socias <bso@odoo.com>
Install Studio
Activate form view of journal items and disable readonly flag on Analytic distribution field.
Create a journal entry adding analytic distribution to a line and post.
Now open the journal item in form view and try to change the analytic distribution
Action will be blocked by error
This is caused by the onchange in _inverse_analytic_distribution. As the
method take care of unlinking and creating new lines no more actions are
required by the orm
opw-3690346
closesodoo/odoo#152143
X-original-commit: 89ef4ae17a507007855ce21e166bec82fc25bd93
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
HOW TO REPRODUCE
================
Don't sign in and go to front-end > Courses > Trees, Wood and Gardens >
Main Trees Categories. '< Prev' and 'Next >' are not centered vertically.
HOW TO FIX
==========
Slides navigation buttons are <a> HTML elements. Add them bootstrap
class 'my-auto' to handle their height properly.
task-3633452
closesodoo/odoo#152130
X-original-commit: 4fb0631526153272c7fe203b35980fd7b18f6125
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit:
if you have <p> within <li>,sometimes removing the <p> will result in the loss
of all classes.
After this commit:
Replace p inside li with span while preserving classes.
task-3546209
opw-3602047
closesodoo/odoo#152104
X-original-commit: e396a1097463d014a1aba553022451365b31f5f3
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Current behavior:
When you try to pay with razorpay, you got an error saying the phone
number was missing.
Steps to reproduce:
- Setup RazorPay
- Set a phone number on admin
- Go to the POS
- Add a product to the cart
- Click on the payment button
- Select razorpay
- Scan the QRCode with your phone (make sure you'r connected on the
admin account)
- Try to finalize the payment
opw-3669600
closesodoo/odoo#152040
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Before this commit:
`destroyLinkTools` function sets the selection to entire link. However, in
case where a website snippet had a structure like
```html
<a>
<div>
<i class=fa-xxx></i>
<div>
<h4>Text</h4>
<font>Text</font>
</div>
</div>
</a>
```
selecting the complete link caused problem. The toolbar couldn't be
updated correctly, also one could not change the a tag of a single element
within the link.
After this commit:
`destroyLinkTools` selects the `anchorNode` and the `focusnode` of the
selection instead of entire link.
task-3245819
closesodoo/odoo#151752
X-original-commit: e88ffecc4bdb0480fc1d47af14558f28f72a665d
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Josse Colpaert