The product configurator modal was too wide and the items were not correctly aligned. This commit changes the general aspect of the radio input and add responsiveness.
task-2492631
When the discount policy of a pricelist was set to `without_discount`, the discount information was shown in the order line of the product screen and on the receipt but not in the invoice.
task-2492631
Before this commit, when the webhook was processing a notification,
if there was a validation error, the webhook was sending the whole
traceback to Adyen. Since this was still a response code 200, this
didn't cause any problem, but we could see the response received in
the Adyen backend.
So we will now catch any validation error and send `'[accepted]'` in the
response.
closesodoo/odoo#74733
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Issue:
- [1] Edit mode > Set a shape on image (mimetype = 'image/jpeg')
- [2] Replace it by an animated GIF.
- [3] Replace the .GIF image again by the old one.
- The shape is not applied on it.
After the step [2], the image a dataset of:
{..., mimetype: "image/svg+xml", originalMimetype: "image/gif"}.
But when replaced by the JPG image in [3], we get (in '_applyOptions()')
an image with the following dataset:
{..., mimetype: "image/jpeg", originalMimetype: "image/gif"}
This incoherent state is caused by the fact that the mimetype from
attachment will be added on shape image in loadImageInfo(), which
affects the result of '_isImageMimetypeSupported()' method
(image is considered as a .GIF), and as a consequence, the shape
won't be applied.
We already have code (in '_onImageChanged()' method) to fix mimetype
in this case, but the goal of this commit is to move this code to
'_loadImageInfo()' to prevent this kind of incoherent mimetype values.
IMPORTANT: after this commit, the right mimetype value for GIF images
is passed and shapes cannot be applied on them (shape data will be
removed from non-supported images)
task-2578242
closesodoo/odoo#72639
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, we use the total_timesheet_time field in the kanban
view of `project.project` to know if there are some timesheets into each
project. The problem is this field is computed and its compute method
take more execution time than just use `timesheet_ids` field to allow if
a project has at least one timesheet.
This commit replaces the using of `total_timesheet_time` field by the
`timesheet_ids` field in project kanban view to check if the project
has at least one timesheet.
closesodoo/odoo#74730
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
When using several certification together, there was an issue
when we tried to modify the quantity of an orderline.
The "this" context was lost and we were unable to call the function
anymore.
In order to fix that, we bind the context when calling the function.
closesodoo/odoo#74725
X-original-commit: 183c3cfded14e716781ae701ec92e2ba68808eb7
Related: odoo/enterprise#20070
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit, the validation flow with verification (payment of a
small amount with immediate refund) was performed with the use of
validation routes: after payment, the customer was redirected to the
validation route stored on the transaction to trigger the refund. This
implementation had an issue: if the customer never reached the
validation route, they were not refunded their validation amount. This
could happen if the customer closed the tab after paying with an
acquirer offering payments with redirection, or if the validation
payment was asynchronously confirmed through a webhook notification.
This commit gets rid of validation routes and requires acquirers to
immediately refund the validation amount when the payment is confirmed.
This way, a payment confirmation coming from a webhook can trigger the
refund too.
As the only acquirer that implements the validation with verification
flow, Authorize.net now voids validation transactions as soon as they
are authorized.
While we're at it, the logging of processing values is adapted to only
log specific rendering values if a redirect form is rendered.
task-2612977
closesodoo/odoo#74707
Related: odoo/enterprise#20060
Related: odoo/upgrade#2710
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Added documentation to the methods of the ImageTools SnippetOption.
Also, removed unnecessary config from the transform method, which was
specific to the wysiwyg transform method to allow for reset on double
click.
The ImageTools transform and crop options now correctly set their button
to active or not.
Two reset buttons are added next to the transform and crop buttons,
visible when a transformation was made on the image.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
closesodoo/odoo#74592
X-original-commit: fc3706a0736c2c76dfd1a261a1455146b1699ce7
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit adds two events to either enable or disable and cancel
loading effects at the SnippetsMenu level.
This is useful if we want for a snippet to be edited without showing the
loading effect. In the context of this PR it is used for image
transforms.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
X-original-commit: c45896fdd5a89e7954d8afeeb89ff51bb16ab438
Before this commit, the editor overlay was not correctly applied to
rotated elements.
After this commit, we apply the transformation of the element to the
overlay. For that, we needed the original top and left offsets of the
element. These values are obtained by cancelling the transform before
computation, and reapplying it after application to the overlay.
With these original top and left values and the transform property also
applied to the overlay, we are able to display it with the correct
rotation over transformed elements.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
X-original-commit: 8c7815bc02b06914966aca524cf95675706944b8
REASON FOR THE FIX
To correctly display the overlay over a rotated element, we need to
reset the transform of the element, to be able to apply it on the
overlay.
Changing the style of the element in the SnippetEditor cover method
would trigger a DOM mutation, which will result in setting the
odooEditor observer unactive.
The issue was that flushing the observer (when setting it unactive)
would always send an event observerApply, even if no record was
processed.
It was an issue as the SnippetsMenu was triggering a content_changed
event at the reception of this event, which would rerender the
SnippetEditor overlay cover (and create an infinite loop of events).
SOLUTION
To avoid that, the observerApply event is sent only if records were
processed.
Part of https://github.com/odoo/odoo/pull/74592
task-2554608
Issue: When making a return for a transfer, the precision_rounding was taken from the UoM of the product given in the transfer, but the quantity was taken in the UoM of the product defined on its form
Steps to reproduce :
1) Create a UoM "Hundreds", rounding precision 1 (has to be different than "Dozen"), Bigger than the reference Unit of Measure, ratio 100
2) Create a test product with "Dozen" as UoM
3) Inventory > Operations > Transfers > Create
4) Add test product, Demand=2, Unit of Measure=Hundreds
5) Validate
6) Create a Return for that transfer
7) Quantity is set to 17 Dozen instead of 16.67
Why is that a bug:
The quantity to return is `quantity = stock_move.product_qty` (in UoM of the product form) but the rounding is made with rounding precision `stock_move.product_uom.rounding` (in UoM of the line of the transfer) which can be different in case of manual transfer creation for example
opw-2543304
closesodoo/odoo#74588
X-original-commit: 4f962846ad0e47f7939f0181ecbae7954c23b615
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>
Due to the following PR: https://github.com/odoo/odoo/pull/70092
the download icon wasn't present in the document viewer.
We had to do this to avoid crash in mobile apps (Android and iOS).
But even if there are multiple other ways to download file, some
of our users are used to use pdf js download button that was previously
hidden.
So in this commit, we restore it on desktop as we can now correctly
handle the error on Android tablets and hide this button on iOS tablets.
Note that pdfjs button is not needed on mobile as we doesnt' have
attachements preview on small screens. Another button is available
when you open the file.
Steps to reproduce:
- Go to Accounting
- Customer Invoices
- After printing it once, the download icon wasn't present in pdfjs preview
closesodoo/odoo#74675
X-original-commit: 036c2475ac5c9ae3a0692486badfceb45de1f52b
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, since we use 'total_timesheet_time' field to see if
any timesheets exist for each project in the kanban view.
The render of this view is slower because of the compute of this field.
This commit improves the performances of this compute.
closesodoo/odoo#74727
X-original-commit: 4dfa75e5b8d170532c0dd36f609eac1718aab4a8
Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>
Suppose such a SO line:
- Unit Price: 541.26
- Qty: 38
- Discount: 2%
The line amount is computed thanks to application of the discount on the
price, then the multiplication of the result with the quantity. The
rounding eventually happens after these steps:
https://github.com/odoo/odoo/blob/254b2a0840d3e817cc6062c483b5213c10088af5/addons/sale/models/sale.py#L1013-L1024https://github.com/odoo/odoo/blob/b76e9ef658bde0178fa1660b6ad27b880e91632a/addons/account/models/account.py#L1138
Therefore, in the above case, we have:
```
Total = round(541.26 * 0.98 * 38)
= round(530.4348 * 38)
= round(20156.5224)
= 20156.5224
```
However, when confirming the SO and setting the delivered quantity, the
Untaxed Amount To Invoice is computed using the unit price with both the
discount and the rounding already applied:
```
Total = round(541.26 * 0.98) * 38
= round(530.4348) * 38
= 530.43 * 38
= 20156.34
```
As a result, the amount is not the same than the first one, this is
incorrect.
OPW-2525975
closesodoo/odoo#74709
X-original-commit: 014a40448ca7854646d929ab369f92c6dede1eb4
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Group by products margins computations to reduce SQL queries sent
to postgre server, improving overall performances.
Replace setattr for loop by product.write to reduce the number
of write queries.
closesodoo/odoo#74556
X-original-commit: 4884a2b0d035cb58d21cdee481cff3c636825020
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
In some reports, we need to detail the taxes for each journal items.
This is the case of all EDIs, the SAFT-report, l10n_in etc.
This task adds an SQL view mapping each tax lines with their corresponding base lines and computing the tax_amount and base_amount.
closesodoo/odoo#70866
Task: 2352524
Related: odoo/enterprise#18344
Related: odoo/upgrade#2686
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
It creates race condition, as it contact external ressource, in this case
facebook.com.
Tests should never call external services anyway, it always lead to race
condition.
closesodoo/odoo#74704
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
This commit adds commands to enable/disable debug mode and to get
to the debug menu from the command palette.
closesodoo/odoo#74587
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current template used to render the payment receipt
lack of details, which cause it to sometimes not make
much sense.
Eg.
Invoice of 3000
Reversal of 1000
Payment of 2000
The receipt won't display information about the reversal,
showing something akin to "3000-2000 = 0"
This will improve the template to give more detail to the
user and avoid possible incomprehension.
Task id #2545590closesodoo/odoo#73974
Signed-off-by: William André (wan) <wan@odoo.com>
In 01875541b1, HTML fields (and various
methods) were made to return markupsafe.Markup objects.
However at the time I didn't consider that XML-RPC serialization
remains based on type *identity*, and thus the `Markup` object would
not serialize outbound through XML-RPC, and would blow up instead.
This should fix the issue, by serializing Markup objects as str.
closesodoo/odoo#74684
X-original-commit: 165bd3bf88becc42416e49ad2f430e90675219fa
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Added error during forward port #e0f02cf438d8852461fa22a1ff88859afee4e9a5
add missing environement argument to display the date with the correct
format
closesodoo/odoo#74682
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Using the new carryover feature, improve the french tax report to properly carryover the values from the tax grid 27 to the tax grid 22 of the next period.
Also slightly improve the carryover itself
to support total lines, and disallow to
carry over to lines from another report.
Task id #2452451closesodoo/odoo#69887
Related: odoo/upgrade#2708
Related: odoo/enterprise#17953
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The field is supossed to point to account.bank.statement but is pointing to account.move
Now is working because the field is only used in button_open_statements method where the model is defined,
but if you want to use this field to report it will get information from account.move with that ID or an error if the move do not exist
closesodoo/odoo#74673
X-original-commit: 21b076d5dcd99f369bc745906cf94ce337539bcd
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce
- Purchase >> reporting
- Filters > choose a Vendor
- Filters > Effective Date Last Year
- Toggle Studio
- Add Pivot View and close
- Measures > On-Time Delivery Rate
Got a traceback, the read_group method didn't take into account
the aggregate functions.
opw-2600230
closesodoo/odoo#74672
X-original-commit: ca3821aa35bece74a461a47ea8a8f5e680df83a7
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
- latam document type was used in l10n_cl_sequence_ids and used the same
table in l10n_cl_journal_ids but it was never used any where
task- 2464212
closesodoo/odoo#71095
Related: odoo/upgrade#2478
Signed-off-by: Josse Colpaert <jco@openerp.com>
When a session was opened, another user couldn't see the resume button from the kanban view?
To resume the session, the user had to go threw the pos session view.
closesodoo/odoo#70887
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In order to limit encoding decoding, the _render method returns a
unicode string in the markup safe object instead of a MarkupSafeBytes
closesodoo/odoo#68299
Related: odoo/upgrade#2454
Related: odoo/enterprise#17270
Signed-off-by: Antony Lesuisse (al) <al@openerp.com>
* Remove AST in favor of pure Pyhon. This should make it easier for
developers to understand and create new directives because they do not
need to know AST.
* Remove `t-call-options` as it has been merged into `t-options` for more
consistency. Support for t-call-options is retained.
* Use generators for lists. This increases performances as the rendering
can be sent directly without having to wait for the creation of the
entire list.
* Optimize expressions runtime computation by pre-computing the static
parts.
Example:
'<' + 'div' + '>' + '<' + dynamic_value + '>'
Now compiles as:
'<div><' + dynamic_value + '>'
Steps to reproduce:
- Install purchase and accounting apps
- Set the database to a language that is not English
- Create a purchase order
- Remove purchase representative from PO (otherwise, no issue)
- Action -> Create Vendor Bill
- From the vendor bill, print invoice
Issue:
The pdf is in English (country names, date labels, etc...)
Cause:
If invoice type is `in_invoice` or `in_refund`, it will use the
`invoice_user_id` language (object.invoice_user_id.sudo().lang).
In the above case, there is no invoice_user_id on invoice.
Solution:
While preparing invoice values, set invoice_user_id to
self.env.user.id if not user_id on PO.
opw-2510134
closesodoo/odoo#74671
X-original-commit: 4b7569ce641a6fb20d5df676bf0b315d9b9d485d
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
When computing the inverse of `journal_id` on a batch of
`payment.acquirer`, a payment method is created if there isn't any.
As this process can only be done for one acquirer at a time, we must
populate the data accordingly.
closesodoo/odoo#74668
X-original-commit: 493b1ca54d6831f044726b2d8942e7e7f7ce3098
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce
- Change the language to another language than english
- Go to point of sale
- Open a session
- Click on 'Client'
- On the list screen, the button 'Select Customer',
'Deselect Customer' and 'Change Customer' are not translated
This fix is about to rewrite terms which has been deleted after a
first fix made on commit 00e177ba0a3e7e5d25e685c8d07732e3e11676de
opw-2596436
closesodoo/odoo#74662
X-original-commit: 615104b64eccf27670bc5ab88996ec7b93149769
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: guva-odoo <guva-odoo@users.noreply.github.com>
Issue: When preparing a work order for a product on which the bill of material had a line with duration set to 00:00, the work order expected_duration for that line was set to 60:00
Steps to reproduce :
1) Enable Work Orders under Manufacturing Settings
2) Create a Bill of Material for a new product "test"
3) On the BoM Form, go to Operation, add a line
4) Set an operation, a work center and for Duration Computation, set it to manually and 00:00 minutes and save
5) Create a manufacturing order for that product, check the Work Orders tab of the Manufacturing order form, the duration is set to 60:00
Why is that a bug:
Since we can set a duration of 00:00 in the Bill of Material, it means the work order can take 00:00 as expected duration, however it was set to 60.0 since 00:00 is evaluated as 0, which is considered `False` in a conditional assignment that was catching the case where the variable was `None`, which it can never be since it is a fields.Float that will be 0 in case of a `None` or `False`
opw-2603928
closesodoo/odoo#74660
X-original-commit: 331b4c3aa69b06316e762f79f17e882f40e1870e
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Previously, the debug manager was rewritten with the new webclient
architecture, however, because the frontend did not have access to the
new infrastructure (env and services), the old debug manager was kept
and used only in the frontend.
Since odoo/odoo#72675 the new env and services are now available, this
commit simply uses the new debug manager in the frontend and removes the
legacy code.
closesodoo/odoo#74609
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The error message when resetting a payment to draft and changing the date is not adequate. This aims to guide the user to the appropiate journal entry where changes are required.
part 2 of task [2533660]
closesodoo/odoo#73470
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Payments that are modified have no real traceability. It would be useful to see a list of modified fields in the chatter, therefore tracking was added to a number of fields.
Date changes on journal entries (account.move) are also tracked in the chatter
part 1 of task 2533660
Before this commit: When applying active filter using progressbar in activity
view, records are not displayed based on active filter, row was not getting
highlighted based on active filter also other records not getting hidden.
After this commit: When applying active filter in activity view using
progressbar, row will be highlighted and records will be sorted based on active
filter value, like if 'green' color is clicked in progressbar then records with
green color will be displayed on top also other color records will get hidden.
task-2550959
closesodoo/odoo#74405
X-original-commit: 0fbed7291d4d242d663f3b816904525dd5b65c0c
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Steps to reproduce:
! Chrome version >= 91.0.4472.114 (no issue on <= 90.0.4430.51)
- Install Accounting module
- Go to Customer Invoices and create a new one
- Add a customer with a very long name, add product then save
- Go back to list view
- Ensure that the column "Customer" does not display the full
customer name
- Try to resize "Customer" column
Issue:
All columns are resized.
Cause:
Since Chrome 91.0.4472.114, `max-width` on column cause
an issue with table.
The issue is triggerd when a <th> width size
exceeds the maxWidth size.
Also, when resizing, the maxWidth of current collumn stays the same.
Solution:
On resizing, update also, maxWidth with new width value.
opw-2585307
closesodoo/odoo#74649
X-original-commit: 0cc1a5863a1dee27ab5b8500c6de75628f1c441c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The non readonly computed field with inverse on the company was raising
an access error for users that have accounting rights but not admin
rights to write on the company.
opw-2446242
closesodoo/odoo#74643
X-original-commit: 0b2fa7b0e5d826b1ba08cd7723a3f40b792e82ba
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Jacky (trj)