Currently, the e-invoice settings form view is not proper.
So in this commit, we did the form realignment in the e-invoice settings.
Also, updated the e-invoice report.
Part-of: odoo/odoo#109717
Currently, the Place of supply value is set from the partner state for all journal types.
So in this commit, we set the partner state in `Place of supply` only when
the journal type is a sale. Also added the country domain in XML view.
Part-of: odoo/odoo#109717
Steps to reproduce:
- We need to have eLearning and Survey installed.
- Then we go to Demo or any other users and we remove the access to
eLearning and we give it administrator rights to Surveys.
- We connect with Demo and we go to the survey app.
Issue:
We are getting a traceback when trying to access Survey app, because
we load the inherited view that calls for the `slide_channel_count`
field which is restricted for elearning officers only.
Solution:
Added proper access rights groups to the inherited views so we won't
try to access it without the proper rights.
opw-3059128
closesodoo/odoo#109620
X-original-commit: ee0290b90d109fd26724548d7f68c7ff2f6531e9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Maruan Aguerdouh Mohtar (magm) <magm@odoo.com>
The goal of this commit is to fix the problem introduced by the PR 106519.
How to reproduce the problem:
- Go to the "Email Marketing" app
- Go to the "Mailing Lists" menu
- Click on a "Mailing List"
- Click on the "Recipients" stat button
- Click on the "Import" button
Before this commit:
A dialog opens and no mailing list is selected.
After this commit:
A dialog opens and the mailing list we are in is selected.
closesodoo/odoo#106732
Related: odoo/enterprise#34453
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In this commit, we will convert all the customisations of the kanban view
consist in adding an always present button in the control panel that
performs an action/calls a model's method.
To do this, we will use the new display="always" parameter applicable
to buttons in the header of kanban views. This allows us to define a
button that is always visible in a kanban view.
Taskid: 3082390
Part-of: odoo/odoo#106732
This commit adds the possibility to define buttons that are always
present in the arch of a kanban view.
Purpose:
Several customisations of the kanban view consist in adding an always
present button in the control panel that performs an action/calls a
model's method.
We want to support this feature directly in the framework to remove
these customisations.
The task 3082303 has added the same functionality to the list view.
Solution:
Add a "display" option that lets you know when to display a button.
The different values that can be assigned to "display":
- "selection": the button is only displayed if at least one record is selected.
- "always": the button is always displayed.
The default value of "display" is "selection".
Currently, only the value "always" is implemented because it is not
possible to select a record in a kanban. The selection of a record in a
kanban view will be implemented soon, so we decided to use the same API
as in the list view.
Exemple:
<kanban>
<header>
<button name="to_do" type="object" string="Do" display="always"/>
</header>
...
</kaban>
Taskid: 3082390
Part-of: odoo/odoo#106732
Before this commit placeholder images were generated in multiple
different ways in website_slide. This commit makes use of
_get_placeholder_filename function and standardizes the way
these placeholder images are generated for website_slide.
Task-2908029
closesodoo/odoo#100587
Related: odoo/upgrade#4050
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Warn when constrains name combine with table name will be more than
63 characters.
This is to avoid case like the one fixed in #103148
Unlike index, since constrains name are defined in the code, we prefer
to avoid automatic truncate and add a warning since devs can chose
an appropriate short-enough name.
The linked fixes will just truncate the name to the max length
to match the name in existing databases. Renaming could be done in other
pull requests with upgrade scripts to avoid constrains re-computation.
Part-of: odoo/odoo#109065
Current behavior before PR:
(In the case when Multi-languages are set up for the website.)
The translation button does not work well with the e-learning fullscreen view.
It completely closes the fullscreen view and opens the edition on a blank page.
Desired behavior after PR:
To avoid this, we intercept the click on the 'translate' button and redirect to
the non-fullscreen view of this slide with the translation mode enabled.
Task-3087792
closesodoo/odoo#109815
X-original-commit: 9b5c3eb21139a60ae2374d9f7614508e31bac492
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Co-authored-by: Aurélien Warnon <awa@odoo.com>
This module creates E-waybill in two types
1) Based on E-invoice API:
Generates the E-waybill using the Invoice Registration Number (IRN) that create by the E-invoice service
2) Direct using E-waybill API:
Generates the E-waybill using E-waybill API
X-original-commit: 2374d127792b3412e0ffe62515499d5b8f8ba434
Part-of: odoo/odoo#109390
need to filter service product from invoice for E-waybill so add this optional parameter
X-original-commit: cb01d94ab249a45ec31983573179a68284698896
Part-of: odoo/odoo#109390
Before this commit:
Selecting some text and changing its size will never allow you to select 13 and
selecting default will make the text bigger than the surrounding text.
Example in project: the default size is 13px (the editor parses that info and
display 13px as the font-size), but if you want to set any text to that value
you can't. Users could set any text to that value by selecting
"default" font-size instead of 13
After this commit:
"default" sets to "font-size: medium", which is often not correct. It should
instead, do a "font-size: inherit" so that it's the default for the current
context. Hence, removed that medium font-size rule and let the cascade do it.
Task-3095887
closesodoo/odoo#109835
X-original-commit: 9878579f62b493958bb6a98e2cdc466bfc2954d8
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, the string with the phone number sent to Stripe for the request is not checked and we got this error on the checkout page
---------------------
We are not able to process your payment.
Stripe: The communication with the API failed. Stripe gave us the following info about the problem: 'Invalid string: +1 555-555...5678456789; must be at most 20 characters'
-----------------------
The stripe API does not accept phone numbers with more than 20 characters
The problematic phone number are mostly the one with extention: +1 780-459-5656 ext. 725
But the customer can put anything in the phone field when he buys some product via eCommerce
Now I just limit the phone string to 20 characters, this doesn't affect the res.partner
If the customer had a phone with more than 20 characaters in the res.partner form, it will stay that way. It's only for the stripe request
closesodoo/odoo#109834
X-original-commit: d24cc320854f180989949328396dbbd8ac69bdc9
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Since it's first implementation at [1], a new cursor is created to then
build a new environment after the website's `authenticate` overide with
the new `uid` of the logged in user.
Since the new visitor SQL upsert refactoring done at [2], it seems to be
introducing a SQL deadlock sometimes.
It has been detected on odoo.com while monitoring the logs. Despite
being quite rare, it still happens too often due to our heavy trafic.
Step to reproduce (among others):
- Install website_livechat
- Login as admin on 127.0.0.1
- On 127.0.0.2, load the website
- Open the livechat
- Type something in the discussion
- Directly try to login as admin
- It will load for a certain time then crash on a 502 timeout due to the
SQL deadlock
- You may need to repeat the process to actually face the bug
[1]: https://github.com/odoo/odoo/commit/6bec0e4d29e6b33b74962b2893a7a405667ef58c
[2]: https://github.com/odoo/odoo/commit/d348bed1ad9d3d16b295f013f015706be6c07820closesodoo/odoo#109830
X-original-commit: b241cf7de9329af1410b9dd45b161aa41926effb
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
before this commit, there is no form view defined for the mail.guest model and on accessing these record from Guests menu under the settings, is returning odoo generated form view.
after this commit, clean form view will be displayed on accessing the Guest menu.
closesodoo/odoo#109826
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
When modifying the template of an already configured line (e.g. Customizable Desk)
and replacing it with another configurable template (e.g. Conference Chair),
the attributes chosen for the Customizable Desk were given to the server,
but no variant could be found for the Conference chair matching the given
attributes values, leading to a crash server-side. The expected configurator
wasn't opened, and the SOline was left in an incoherent/invalid state.
This commit makes sure that invalid attributes data are filtered out since
they should only be reset when the chosen template is changed on the line.
Fixes#109604closesodoo/odoo#109820
X-original-commit: 55d37baabb4ee9911a1a33daf412e42d2c9f7d6d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Version 16.0 removed the price different account following this pull
request #99411
This decision has been made because it was only used anymore by
standard cost method and real time valuation. We thought that standard
was not a valid accounting method and we didn't want to maintain
code for it. But:
- Standard could be valid if you manualy complete the accounting entries
by yourself (e.g. employees/machines cost in mrp).
- It's also accepted as legal inventory valuation if you record the
difference between invoice and standard price + regular update of
the standard price to match the reality
- If you want to have an estimation of your cogs (benefits and loss)
during an accounting period. People just do a manual correction at
the end but they have a real time reporting on the situation.
Since delivery/receipt interim accounts already exists we could say
that user could simply reconcile them by himself. It could be but
it would be a pain to know what part of the account is already invoiced
and need a correction vs the part not yet invoiced.
It's a too big regression to be acceptable. We apologize and
reintroduce it for 16.0
This module is a fix module and will not be there anymore in 16.1
closesodoo/odoo#108513closesodoo/odoo#109814
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This reverts commit f1d8f7b43c29342aecb69f233fdd7702b4e4d913.
The previous commit shouldn't been merged to maintain the integrity
of runbot testing. It will be merge soon in the same time than the
migration script
Part-of: odoo/odoo#109814
This basically reverts [1].
After discussion with the related team, [1]'s purpose was to prevent
merging two links together if backspace was hit at the beginning of one
mega menu item. [1] however made mega menu creation impossible as it
prevented removing any mega menu item (well, you had one possibility if
you used Chrome which was to unlink the mega menu item and then remove
it via backspace but...).
After some more discussion, we decided that allowing to merge mega menu
items seems not bad (it is the same behavior as the rest of the editor
when two links are next to each other). In any case, being able to
remove default mega menu items is more important.
[1]: https://github.com/odoo/odoo/commit/9779145d9157e9687c36d2caa0ecea2862a2ac5a
opw-3109946
opw-3120070
closesodoo/odoo#109804
X-original-commit: 7de359470fb4d8eb81f018262a5e4c66a71c7043
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
VAT in New Zealand is called GST. New Zealand entities are issued IRD numbers and when registered for tax their IRD number is used as GST number.
> from: https://www.business.govt.nz/tax-and-accounting/basic-tax-types/gst
> For sole traders, your GST number will be the same as your IRD number.
> For partnerships and companies, it’s the same as your partnership or company IRD number.
GST number is legally required on all tax invoices (https://www.ird.govt.nz/gst/tax-invoices-for-gst/how-tax-invoices-for-gst-work)
I have added the VAT label as IRD/GST so that it's clear wherever else VAT label is used that the same number fits both contexts (rather than introducing a second field for identical data through NZ l10n).
closesodoo/odoo#109800
X-original-commit: 8ac78c222ae93e000a43c71ac9e359a8542f8cff
Signed-off-by: Josse Colpaert <jco@odoo.com>
When the same text appears several times inside a translated field but
nested in different HTMLs, the matching for each one is done
independently if various spacing appear in the HTML.
This commit strips the spaces around the matched texts so that texts
that are synchronized on purpose do not become desynchronized.
Doing this leads to collisions on the keys of `text2term`, it therefore
also has to replace it with a dictionary of text to list of terms.
opw-3098819
closesodoo/odoo#109798
X-original-commit: 6cec590a2dad43063d3bb747838393a8df13aa04
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Before this commit: if the number of order lines exceeds the size of the
order container, it wouldn't scroll to the newly added order line.
The solution is to scroll to the newly selected order line.
opw-3120034
closesodoo/odoo#109548
X-original-commit: bc9302b105a6e53bbfe8efc65c8a36b7a547b1d9
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
At present the invoice can only be sent to the device from the form
view. The functions involved in posting the invoice expect just one
invoice.
This commit adapts the functions involved in posting the invoice in such
a way that multiple moves can be processed. In order for this to happen:
The validation check function now creates a list of errors per move, and
the error message provided lists the errors under the name of each move.
The post function has been adapted to iterate over the moves provided,
and construct the params passed to the javascript action as a list of
dictionaries, rather than a flat dictionary.
The javascript action that forwards the data to the device is adapted to
iterate over the params provided to it, instead of sending just the one
invoice.
A sever action has been added on the account move (tree view) to allow a
user to select multiple entries from the invoice tree view and send all
of them to the fiscal device.
closesodoo/odoo#109520
Task-id: 2950308
X-original-commit: 2b590e69310bdce9201ad54a1b14f22007098173
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
currently the module is named as LT, where as it has to be Lithuania according to odoo localization module standards
closesodoo/odoo#109240
X-original-commit: 84291b92655a260bd75669466c8f66d421fa3e7b
Related: odoo/enterprise#35488
Signed-off-by: Laurent Smet <las@odoo.com>
This commit removes the title attribute on navbar items.
The title was only repeating the content so it was useless.
closesodoo/odoo#109230
Task: 3097276
Related: odoo/enterprise#35562
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit makes the kanban group header sticky, it means that when
the user scrolls the headers will still be visible on top of the view.
closesodoo/odoo#109060
Task: 2050014
Related: odoo/enterprise#35611
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Some cookies were left around even when the user logged out
The next user should log into the default company instead of the company
of the last user.
task-3077421
closesodoo/odoo#108998
Related: odoo/enterprise#35685
Signed-off-by: Julien Castiaux <juc@odoo.com>
Problem case :
- Create a product with MTO and Buy route activated.
- Create a Sale Order containing this product.
- Confirm the Sale Order, this will generate a Purchase Order for this
product.
- Go to Alternatives -> Create Alternative -> Select another vendor &
select "Copy products".
The alternative PO won't be linked to the Sale Order, as this link is
done through the relation `created_purchase_line_id` <-> `move_dest_ids`
respectively on the `stock.move` and the `purchase.order.line`.
The only way to enable multiple Purchase Order to be linked to a single
move is to extend the number of `created_purchase_line_id` linked to a
move, hence changing it to a Many2Many relation.
Then, when an alternative PO is created, we link the original PO lines
`move_dest_ids` to the newly created PO lines, which correctly links the
SO and the alternative PO.
closesodoo/odoo#106411
Related: odoo/upgrade#4116
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Create a service that is subcontracted `service_to_purchase` = true
- Create a SO containing this service
- Go to the newly created RFQ
- Go to Alternatives -> Create Alternative and select a new vendor
- The alternative RFQ doesn't show a link to the SO, nor the SO to this
RFQ
Initially, when the alternative RFQ is created, only the `product_id`
and its quantity is copied to the new RFQ. Now we add the reference to
the SO as well so the RFQ is properly linked to the original SO.
Part of task-2985735
Part-of: odoo/odoo#106411
*=hr_timesheet,sale_project,sale_timesheet,spreadsheet_dashboard_hr_timesheet
The main goal of this PR is to minimize code duplication for the search and list views for tasks and projects.
Task search views
-----------------
The most important change was to merge the search views used in the task reports with the "normal" corresponding search view. The reporting search view should now be almost identical to the normal one in both project and fsm.
The `project.task`/`project.task.user` search views are now following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
┌──┤4│ │7├──┐
│ └┬┘ └┬┘ │
│ │ │ │
┌▼┐ ┌▼┐ ┌▼┐ ┌▼┐
│5│ │6│ │8│ │9│
└─┘ └─┘ └─┘ └─┘
```
1. `view_task_search_form_base`: Base search view containing all the fields/filters common to project, project sharing and fsm
2. `project_sharing_project_task_view_search`: Search view for project sharing.
3. `view_task_search_form_project_fsm_base`: Base search view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_search_form_project_base`: Base search view for project only, with fields/filter common to the normal search view and the one used in reporting.
5. `view_task_search_form`: Search view for project.
6. `view_task_project_user_search`: Search view for the project report.
7. `project_task_view_search_fsm_base`: Base search view for fsm only, with fields/filter common to the normal search view and the one used in reporting.
8. `project_task_view_search_fsm`: Search view for fsm.
9. `report_project_task_user_fsm_view_search`: Search view for the project report.
With this organization, we can easily add a field to both fsm and project at once, and even to project sharing at the same time. Since the goal is to keep the reproting search views identical to the normal ones, it'll also add the field to both of them.
Task list views
---------------
Similarly to the search views, the task list views were also refactored to minimize code duplication, following this inheritance diagram:
```
┌─┐
┌─┤1├─┐
│ └─┘ │
│ │
┌▼┐ ┌▼┐
│2│ ┌─┤3├─┐
└─┘ │ └─┘ │
│ │
┌▼┐ ┌▼┐
│4│ │5│
└─┘ └─┘
```
1. `project_task_view_tree_main_base`: Base list view containing all the fields/filters common to project, project sharing and fsm.
2. `project_sharing_project_task_view_tree`: List view for project sharing.
3. `project_task_view_tree_base`: Base list view containing all the fields/filters common to project and fsm (not project sharing).
4. `view_task_tree2`: List view for project
5. `project_task_view_list_fsm`: List view for fsm.
Project views
-----------------
The search and list views for projects in fsm now inherit the ones from project, since our goal moving forward will be to keep those as similar as possible.
Other changes
-----------------
- Merged and removed many filters/fields from the task search views.
- Changed `total_hours_spent` and ` subtask_effective_hours` labels in `project.task` model to avoid changing them manually in many views.
- Renamed `state` into `kanban_state`, `hours_planned` into `planned_hours` and `hours_effective` into `effective_hours` in `report.project.task.user` to make it consistent with `project.task` (so we can keep the same views for both of those models).
- Moved the sale line filed in the "Settings" tab in the project form view (so that the `sale_line_employee_ids` field in "Invoicing" takes the full width).
---
Enterprise: https://github.com/odoo/enterprise/pull/34106
Upgrade: https://github.com/odoo/upgrade/pull/4216
Task-2746370
closesodoo/odoo#106015
Related: odoo/upgrade#4216
Related: odoo/enterprise#34106
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Because of an issue with converting bool values, read_progress_bar didn't work
on grouping by bool fields (e.g. Active).
Related tests worked fine because mocked server responses were different from
real server responses. So, we need to adjust mocked server too.
opw-2870937
closesodoo/odoo#103926closesodoo/odoo#104613
X-original-commit: e6ca3ef1b38dec964dab416c6058d4c1b7161614
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
The account_predictive_bills module is merged into account_accountant.
With this change, the context key
`account_predictive_bills_disable_prediction` is not used anymore.
closesodoo/odoo#104625
Related: odoo/upgrade#3918
Related: odoo/enterprise#31640
Signed-off-by: William André (wan) <wan@odoo.com>
When changing quantities of raw moves after MO confirm,
procurement is run to fulfill updated need.
Since procurement creates new moves, some fixes were also done to allow
moves to be merged with older ones, including:
1) `date_planned_start` of merged MO included microsecond which
blocked merging new moves created by procurement with orig moves.
Removed microseconds.
2) `_set_date_deadline` did not allow a simple date update to moves with
orig or dest moves. Added context to hard set all moves in self to specific
deadline.
3) `_update_candidate_moves_list` when merging moves, did not return candidates
from pickings that were merged to same MO. Usually just mattered when decreasing
quantity. Added explicit check for sibling pickings in MO
closesodoo/odoo#93712
Task: 2859547
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, there was no way to instanciate a Record component and be
able to handle changes occuring in that record.
After this commit, a simple props is added, making this use case possible.
closesodoo/odoo#109846
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Dates in FatturaPA are in ISO 8601 date format: `[-]CCYY-MM-DD[Z|(+|-)hh:mm]`
Data like `2021-01-01z` or `2021-02-05+01:00` did break the checks.
closesodoo/odoo#109838
X-original-commit: 9e50fa08a74fa842aa3a2f37dfe5b38707a50cba
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
We add a QR code to the invoice PDF report
and we add references to the json to the customer reference
(PO of the customer in ref) and to our Sale order (invoice_origin)
closesodoo/odoo#109837
X-original-commit: 25bc19dc1351b64505d8a2d41dd2b90afd7c117a
Signed-off-by: Josse Colpaert <jco@odoo.com>
We just set a place of supply(state_id) from partner_id in the Invoice/Bill if partner country is india because there are many complex cases so we can't get it automatically in all cases like
(a) where the supply involves movement of goods, whether by the supplier or
the recipient or by any other person, the place of supply of such goods shall be the
location of the goods at the time at which the movement of goods terminates for
delivery to the recipient;
(b) where the goods are delivered by the supplier to a recipient or any other
person on the direction of a third person, whether acting as an agent or otherwise,
before or during movement of goods, either by way of transfer of documents of title
to the goods or otherwise, it shall be deemed that the said third person has received
the goods and the place of supply of such goods shall be the principal place of business
of such person;
(c) where the supply does not involve movement of goods, whether by the
supplier or the recipient, the place of supply shall be the location of such goods at the
time of the delivery to the recipient;
(d) where the goods are assembled or installed at site, the place of supply shall
be the place of such installation or assembly;
(e) where the goods are supplied on board a conveyance, including a vessel, an
aircraft, a train or a motor vehicle, the place of supply shall be the location at which
such goods are taken on board.
we add new state "Other Country" to set place of supply(state_id) incase of partner country is not India
for more details check CHAPTER V here https://www.cbic.gov.in/resources//htdocs-cbec/gst/igst-act.pdf;jsessionid=63D695F612B9972934E8131415FEBA28closesodoo/odoo#82011closesodoo/odoo#109286
X-original-commit: https://github.com/odoo-dev/odoo/commit/b76ee098e2a4c4d26d6d1c689bb0750e770201dc
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
Before this commit, test "click on the progressBar of a new column"
deterministically failed on split builds. It only passed with all
addons installed, and passed by chance with all addons installed.
The reason is that the flow of quick creating a record in a grouped
kanban with progressbars wasn't concurrency proof at all. Commit [1]
simply added a hook at the end of the `_save` function of the model,
which highlighted the problem: the progressbars were updated before
the group's count was incremented, so if the quick created record
was the only record of the group, the progressbar was still empty
after the quick creation.
This commit makes the quick create code more robust.
We couldn't find a way to write a qunit test for this, but it still
fixes an error in nightly builds.
[1] a882b725bbclosesodoo/odoo#109818
X-original-commit: cbfad9c36f4e52309903702f21cea457acc55ecb
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Current behaviour:
If a user is making a donation with one amount,
but changes that amount on the payment page,
he lands on a 404 when processing the transaction.
Expected behaviour:
The transaction shouldn't land on a 404 if you just changed
the amount of the donation mid checkout.
Steps to reproduce:
- Install Website and the Donation widget from the website editor
- Add the Donation widget to a page
- Add add a payment method (for ex: Test)
- Make a donation for example of $10
- On the payment page, change the amount to another value
- Checkout, you land on a 404 page.
Reason for the problem:
When generating the `access_token`, it is based on the amount paid.
So at the beginning of the transaction, it is based on $10.
But during checkout, we have a new amount, therefor a new `access_token`
is generated upon ending the transaction. Since the 2 tokens are
different, we return a 404.
Fix:
During checkout we regenerate a new `access_token`, before going on
the landing page. This way the `access_token` will take the value of
the amount from the payment form, not the donation widget.
(The default value for the amount on the payment form is the one
selected from the donation widget)
Affected versions:
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master
opw-3059462
closesodoo/odoo#109817
X-original-commit: 78bc873eef6768cec87c7f2eb0d5324ccc9d6af5
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Note:
This is not fixed earlier because this in invalidates
template translations and this isn't a major issue.
Invalidating translations on 16.0 should still be
fine as of writing this.
Issue:
Google recently added a requirement for an API key
to their static maps API. This means we can no longer generate
<img> tags linking to the google API without using a key.
As we send that key inside emails, it cannot be protected
by origin policies to prevent people from using the key outside
of the domain of the database. Protecting it would require
implementing signed google API requests, which cannot be
done both quickly and sanely on stable.
Fix:
This commit replaces the image with a generic string to get rid of the
'missing image' icon. A better fix/imp may be introduced on the master
branch at a later time.
task - 3079113
closesodoo/odoo#109797
X-original-commit: a730c9920bc82a6637882f325ca3d947ca0ddd78
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
In a list view containing n records, apply or remove a filter.
Then edit the pager to reduce the limit to m, with m < n.
Before this commit, the pager was indeed updated, but the list
still contained the same number of records as before applying the
filter.
This was due to a kanban specific logic to handle the "load more"
feature. We stored the number of loaded records, and forced the
limit to be at least that number.
This commit fixes the issue by changing the way the "Load more"
works. Instead of loading the "limit" next records (i.e. with a
limit and an offset), we now reload the previously loaded records
+ the "limit" next ones (i.e. we leave the offset to 0, and
increase the limit).
This also prevent potential weird behaviors where the same record
appears twice, or records are skipped, when the recordset changes
between the first load and the first load more, or between 2 load
more.
closesodoo/odoo#109693
X-original-commit: 217d1191750d03918055610ba0e61f0f7522f475
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The title is aligned to the right on mobile. This is the result of the
two rules of Bootstrap:
```css
.modal-header {
display: flex;
justify-content: space-between;
}
```
To avoid this we add `margin-inline: start`, to force start alignment of
the title.
Steps to reproduce:
* Open Customer (on small/mobile screen)
* Create a new Customer
* Click on Tags field => BUG title of dialog on the right
Note: on desktop there is no problem as there is the close button on
the right.
closesodoo/odoo#109796
X-original-commit: 7809abb1dcf1b0d384c0cad4065cdf15adf56081
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
bat-odoo