The first objective of this commit is to polish the website
configurator:
1) On page 1 of it: - The size of the text is increased.
2) On page 2 of it: - The font size inside dropdown is reduced.
- 30 results are displayed inside dropdown instead
of 15.
3) On page 3 of it: - The size of the text is increased.
3) On page 4: - The cards are refactored.
- The end line is removed.
- The "Build my website" button is moved to the left.
4) On page 5 : - It is now impossible for the user to click on a theme
preview before it is completely loaded.
5) On all pages, the size of the "Skip and start from scratch" button
has been increased.
On the second page of the website configurator, the user has to choose
an industry type. Sometimes, it happens that the user is searching for
an industry that is not known by the server. Before this commit, a
message of type "No result found" appeared and the user had to choose
an other industry among the existing ones. From this commit, the
"No result found" message is replaced by the name of the industry that
the user is writing. To choose its industry type, the user can click on
the displayed industry name or outside of the input area. This last
option calls the `_blurIndustrySelection` function and the written
industry is kept as the final industry choice. If the user chooses an
industry name that is not known by the server then the remaining of the
website configuration is done with the "abbey" industry. Moreover, this
unknown industry name as well as the language used by the user is sent
and stored to the IAP database. The goal of it is to regularly update
the industry list so that it becomes as most complete as possible.
IAP PR : https://github.com/odoo/iap-apps/pull/549
task-3062171
closesodoo/odoo#110187
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit fixes the appearance of the select element in dark mode.
Since the background color is set with transparency, a white background
was set on the options dropdown by desktop browsers, which made the
text difficult to read. By adding a color to the options, we can fix
the appearance without the need to put a color without transparency
on the select elements.
task #3147138closesodoo/odoo#113106
X-original-commit: 194a6506a933665cc47ca96d976a0aa304eb864c
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
Before this PR, we wanted remove the possibility to create account on the fly. However, we thought it would be better to allow people to create and edit an account from the tree view.
closesodoo/odoo#112866
Task-id: 3188348
Signed-off-by: William André (wan) <wan@odoo.com>
For the Knowledge module, we would like to allow the user to fully
customize a graph view and let the user insert the graph they see in an
article. When loading the graph view from an article, the system can not
currently restore the following settings:
- For the bar chart and the line chart: The system will not able to
restore the "sorting order" and the "stack option" set by the user.
- For the line chart: The system will not be able to restore the
"cumulative option" set by the user.
This commit will ensure that these options can be specified from the
context of the view. The context configuration will have a higher
precedence than the configuration stored in the metadata of the model.
When the user will open an article containing a graph view, the graph
view will automatically load the options that have been set by the user
when inserting the view. The user can thus create their own dashboards
by customizing the graphs and inserting them in an article.
task-3056268
closesodoo/odoo#112600
X-original-commit: 458bf22c7e275b7893505bb39c16073a9f63b9ca
Related: odoo/enterprise#37046
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, there are a few mistakes in the standard view props definition:
1. To check the type of each element in an array, the prop definition has
to include an "element" entry. In the standard view props definition, we
included an "elements" entry which will completely be ignored by the
schema validator of owl in debug mode.
2. The "element" entry is only used when the `type` entry of the prop
definition is `Array`. We will therefore simplify the property definition
and remove the "element" entry for the props that are not arrays.
3. The `orderBy` definition of the standard view props mismatch with the
`orderBy` definition of the `WithSearch` component and the search model.
This commit will fix that inconsistency for all those components and
update the tests and the JSDoc accordingly. It will then be possible to
set the `orderBy` value from the props of the `View` component without
getting an error in debug mode.
task-3056268
X-original-commit: 4911e6cd366eadc60923940364274b30372e1584
Part-of: odoo/odoo#112600
Before this commit:
If we do a payment in COP (Colombian currency) with a 2 decimal price,
For example: $ 1.23
The signature generated by Odoo to PayULatam will be wrong.
This will lead to an Internal Server Error caused by the `ValidationError`:
`PayU Latam: Invalid sign: received %(sign)s, computed %(check)s.`
Note that the issue does not happen on version 14.
By cross comparing with the version 14, the issue don't happen there
as the signature sent by Odoo at the beginning of the transaction is
different.
For some unknown reason the code was changed in version 15 to round it to the
first decimal and this looks to be the cause of the issue.
So, in fact the signature that Odoo send at the beginning of the transaction
looks to be wrong and this ends up modifying the signature that should be
generated on the return of the transaction
Version 14 code to compare with:
https://github.com/odoo/odoo/blob/bbb987edff769a825f7617d24314ec7d79e29c40/addons/payment_payulatam/models/payment.py#L41
After this commit
No internal server error and the transaction is validated correctly
opw-3018628
closesodoo/odoo#113059
X-original-commit: 106560e211fb02cedc6dd640effee2d97fb590f0
Signed-off-by: Loan (LSE) <lse@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce the bug:
- Enable “multi routes” and “wave transfer in the settings
- Go to warehouse:
- Incoming shipments:
- Select 3 steps
- Create two storable products “P1” and “P2”:
- update their qty
- Create a purchase order:
- Add “P1” and “P2”
- Confirm
- Go to the picking:
- Set qty done only for “P1”
- Validate the picking and create a backorder
- Go to inventory > Operations > Transfers:
- Select the internal transfer from input to quality control
- Action > Add to wave
- A new wave transfer > select the move for “P1”
- Add to wave
Problem:
The operation type is not set on the wave transfer
opw-3112142
closesodoo/odoo#113054
X-original-commit: daed921acacd22f45d95357e131ea11654d73766
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Before this commit, name_get of the res.partner model could return
the partner's name + its address but with empty lines if some address
elements were not set.
Now, these empty line are removed which makes the address cleaner.
closesodoo/odoo#113039
Task: 2759019
X-original-commit: c3745be816b1bf9ecd38184307452f93326ef36f
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Following the introduction of field invoice_filter_type_domain in rev
bc131c0cfb, the override using values in
the context is no longer necessary.
closesodoo/odoo#113093
Signed-off-by: William André (wan) <wan@odoo.com>
For performance reasons, the grouped kanban view automatically
folds groups when they are to many, s.t. at most 10 groups are
open by default (because for each one of them, we must perform
a web_search_read rpc to fetch their records) [1].
However, during the convertion to owl, we broke half of this logic.
The qunit test introduced by [1] simulates a read_group that only
sets the __fold key to true in folded groups, but doesn't define it
in other groups. This test passed. But the logic in the model
didn't correctly handle the case where the __fold key was given for
all groups, even when its value was set to false. This happens for
instance in the project task kanban view.
This commit fixes the issue.
[1] https://github.com/odoo/odoo/commit/fa4c650b01dc184041c61d9d52299b0b740a83bd
Task 3191948
closesodoo/odoo#113061
X-original-commit: dd71662cc994fb8716cae63944b4df9d4201dcdc
Signed-off-by: Georis François (fge) <fge@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Using the web_editor html field in the Record component causes crashes.
Why does this happen?
The fields used in the Record component do not always have modifiers.
Solution:
Use the isReadonly function of the record to know if the field is
readonly or not.
closesodoo/odoo#113072
X-original-commit: 5354321877b65d577c419255ce43806f648e1708
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in a form dialog view, clicking on an action button
in the header does not save the record being edited. The record is reset
in case a new record is created.
How to reproduce:
- Go to a form view with a non-editable m2m
- Click on add a line
- Click on Create
- Edit the new record
- Click on an action button (the arch must contain a <button> in the <header>)
Before this commit:
The record is reset. All encoded data is lost.
After this commit:
The record is created in db and we keep all the encoded data.
closesodoo/odoo#113063
Taskid: 3165983
X-original-commit: 52fdfe0b26941718bf1532e517a51de38cacfdbc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Steps to reproduce the bug:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Facebook" snippet inside the "Table of Content".
-> The page is blocked.
This may happen with other snippets than the facebook one (e.g. the
image gallery or the countdown).
A mechanism that interests us here is the mutation observer. Up to this
commit its goal was to regenerate the navbar of the TOC when its DOM
content changed. In practice, since [1], a "widgets_start_request"
message was triggered up each time there was a change of the TOC
content. In the case of the Facebook snippet, this behavior led to an
infinite loop. Indeed, when the Facebook snippet was dropped inside a
TOC, its content changed so a "widgets_start_request" was triggered up.
This message led to the execution of the start function of the TOC but
also of the start function of the Facebook snippet. Because there is a
change of the DOM in this last function, the mutation observer
triggered up a "widgets_start_request" message again that caused the
program to loop forever.
The goal of this commit is to regenerate the content of the navbar only
when its content changes. To do so, the content of the navbar before
the change of the DOM is compared with its content after the change of
the DOM. If those two contents are different, it means that the navbar
should be updated. Thanks to this commit, it is now possible to add
dynamic snippets such as "Facebook" or "Countdown" inside the TOC.
With this in hands, another bug appeared:
- Drop a "Table of Content" snippet inside a page.
- Drop a "Text-Image" snippet on the page but not inside the TOC.
- Drop a "Countdown" snippet inside the "Text-Image".
- Drag the entire "Text-Image" snippet with "Countdown" and drop it
inside the TOC.
-> The page is blocked.
This bug comes from the fact that the drop of a snippet that stands on
the page inside an other snippet leads to the destroy and the restart
of the option of the outer snippet. However, in our case, the mutation
observer was still listening to DOM changes even after the destroy of
the snippet option. This led to parasite function call. This bug is
fixed by disconnecting the mutation observer when the option is
destroyed. Note that this is done in [2] as this was a problem in older
versions as well.
[1]: https://github.com/odoo/odoo/commit/a05f782871c61b2d58ca2fd4277cb7aed65a301d
[2]: https://github.com/odoo/odoo/pull/112960
task-3122249
opw-3164969
opw-3173006
closesodoo/odoo#113070
X-original-commit: 9139b27ee9216f4b6111d0596f101d4927b493b2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.
Related PR: https://github.com/odoo/odoo/pull/110860closesodoo/odoo#113075
X-original-commit: 3787599479d2f1e951bca6622c7049b62d631795
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
In the EAS list, the United Kingdom code is set to 'UK' while in Odoo,
it should be 'GB'. Because of that, the UBL Bis 3 format doesn't appear
in the journals for GB companies.
opw-3169038
closesodoo/odoo#113069
X-original-commit: 82591bb59edee81eca0db21bc44280b1c231ae0e
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Positive Lookbehind regex syntax is currently not supported yet by
Webkit, and thus Safari (both on macOS and iOS) resulting into a crash
as the syntax is not recognized.
This issue affects both frontend and backend.
This commit fixes it by reimplementing the feature without using this
syntax.
closesodoo/odoo#112985
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Forward-port of #94947 for 16.0+
closesodoo/odoo#112935
X-original-commit: ee3404603af8a38e21b922c39aa36a6b1e17b44d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This update conatins the following commit:
- [IMP] devtools: provide access to Fiber and RootFiber
- [FIX] props validation: do not subscribe to props keys
- [FIX] reactivity: only show key in subscription if observed by callback
- [FIX] components: stop rendering stale t-component when delayed
More details at: https://github.com/odoo/owl/releases/tag/v2.0.6closesodoo/odoo#113041
X-original-commit: fd67ca5d2aaa9683ac1e4667e76fc4230d5d62c6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce
=============
- on settings upload a custom background on document layout and save it
- open document layout again and try to download the image -> Traceback
Problem
=======
when calling download method we will ask server for a record with `id=false`
which gives an error
Solution
========
download button shouldn't be visible when `record.resId == false`
opw-3138230
closesodoo/odoo#113029
X-original-commit: 2e2cdee563dd645cabe2d361489d6eb17b174a33
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the bus service test "tabs share message from a
channel" was sometimes failing. This is due to the fact that it was
only waiting a `nextTick` to receive the message but the message is
not guaranteed to arrive within a tick. Indeed, the message is first
sent from the worker `MessagePort` via `postMessage` then triggered
on the event bus via `dispatchEvent`.
closesodoo/odoo#113008
X-original-commit: a8d25a89a9fbdb9d51926df2c33c1f4b5eba9b3f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>
Commit [1] removed the protection around the call to setDirty because setDirty
is always defined when the field is initialized through the standard field.js
mechanism. However, in todo_list.js in hr_payroll, the html field is called
without going through that mechanism, resulting in the prop being missing and the
call to fail with a traceback.
This could be fixed by adding the missing prop to todo_list.js, but other people
are likely to do the same mistake in the future so adding a default of our own is
probably better to avoid future similar bugs.
[1]: https://github.com/odoo/odoo/commit/f56e3bca2456f04616982a9a0e77b8d4c5a0abffclosesodoo/odoo#112994
X-original-commit: a6043b3aa290d6cecaabc02995e490f44cbd6ce2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The default font size of the frontend is 16 so the `default` option
in the font size dropdown was supposed to be enough for this use case.
However, this is not true in the context of website_blog where the
default font size of blog content is not 16. This is not a problem
because if the user does not like the default blog font size then
they can change it using the font dropdown... except they have no
way to select 16 for a size and `default` doesn't mean 16 in blog.
This commit adds an explicit entry for 16 in the font size dropdown.
opw-3110711
closesodoo/odoo#113011
X-original-commit: a35679d5a30e3931216c65ff4ea896e507ba4cf1
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
With Rounding Method set to 'Round Globally'
Create a Quotation with 2 lines:
- Price 6.7, Tax 15%
- Price 6.7, Tax 15%
Total is 15.41, Tax amount 2.01
When sending the quotation via email or in list view the amount total
shown is 15.42.
This occurs because:
- order total is computed as sum of the lines `price_total` field,
which, defined as Monetary, store already rounded values
- line total is computed via `_compute_taxes`, where
tax amount is always rounded per line
opw-3113851
closesodoo/odoo#113026
X-original-commit: c677f45dcb050ce7e6f755b71e56c9b9120bf613
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
To reproduce the issue:
- Website > Add menu items to activate the "+" dropdown.
- Edit mode > The top menu disappears.
On `_activateContenteditable()`, The `initAutoMoreMenu` > `_adapt()`
mutations (changes to move the overflowing menu items to a "+" dropdown)
are recorded and rollbacked by the editor, leading to reset the top menu
to the step before removing the `.o_menu_loading` class.
Recording the `initAutoMoreMenu` mutations leads to some other issues:
On edit mode (without overflowing items):
- Website > Edit mode > The editor starts (before any updates) with an
extra "history step".
- Undo > The top menu disappears.
On edit mode (with "Mega Menu" items):
- Website > Edit mode > Edit text in a "Mega Menu" item > The top menu
disappears.
The goal of this commit is to fix this behaviour using the
`renderingClasses` filter (added in [1]) to prevent the `o_menu_loading`
class from being taken into account in the `filterMutationRecords()`.
[1]: The https://github.com/odoo/odoo/commit/1c25ddb42393b136cac2a0ee0b9b7280fd803e7d
opw-3146873
closesodoo/odoo#113016
X-original-commit: 96c9ebd26aabc3f99acf5d586746b05db7cf4953
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
When using the composer in batch and comment mode, the first record of the
batch was used to find the language for notifications instead of the one
linked to the message.
Previously to odoo/odoo#99482 batch comment mode was not supported and there
were always only a singleton as record ids. Now that it is supported we have
to be more careful when dealing with IDs.
To solve this issue we check the message res_id which effectively contains
the correct record ID.
Oversight of odoo/odoo#99482
Task-3035101 (Mail: Support batch-posting from composer)
closesodoo/odoo#113015
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Rewrite the whole chart template mechanism, removing the templates
stored in the database. The new format will mainly use CSV.
Speed up install time
---------------------
* About half of the time of installing a localization for the first time is
taken by creating the template records. This new in code format gets
completely rid of this.
* Creating the template records could often not be done in batch because
of parent/children relations.
* The instanciation of the accounts on the company has been entirely
reworked too, by
- optimizing the order of creation of records to avoid UPDATE queries
- using precomputed fields to avoid UPDATE queries
- updating the translation in batch
- deactivating logging in the chatter
- avoiding access rights checks by checking the rights at the start
Overall, when installing a chart template for the first time, it is 4
times faster because half of the time spent on saving the template in
the database is not done at all anymore, and the instanciation on the
company is more than twice as fast.
Reduce technical debt
---------------------
There is no need to synchronize the templates with the real records
anymore. No need to use hooks to copy the data from one to the other.
It is easier to change a template in a stable version, which can often
be necessary due to legal reasons (i.e. a change of tax rates, reporting
tags,...)
Two modules have been removed:
* `l10n_generic_coa`: since there is nothing left datawise in this
module, it can be integrated in `account` for free. It is just code
and CSV.
* `l10n_multilang`: the fields that this module modified to be
translatable are now always translatable:
- there was an issue when updating modules that deleted all the
translations because the fields were not translatable at some point
during the loading of the registry, then they because translatable
again but lost all translations because of the column type change.
- most devs are not able to understand all the languages needed for
all the localization available. Therefore, english has been added in
the sources in most localization to understand better issues while
debugging.
- no need to call post init hooks anymore, doing the sync with the
templates.
- more: see "Translations" section
Because most of the data is now in CSV, it is also easier for product
owners to edit, audit, modify files themselves, removing one layer
during trivial development processes when only data should be changed.
More flexibility for declaration
--------------------------------
The data declaration can now be done easily in python or CSV.
A nice feature is that you can declare everything at once, even for some
more complex chart of accounts:
* if you have to set default taxes on accounts, would need to
- declare the accounts because accounts are required on the taxes
- declare the taxes
- declare the taxes to put on the accounts
This would lead to scatter information in multiple files. Now,
everything can be declared in the same place and the loading of the
chart of accounts will do the 3 steps automatically.
* if you have a relation of child/parent, you would first need to
declare the parents then the children, and the loading would not be
efficient because done one by one. Now, everything is done in batch
automatically without having to think about it.
It is also easier to update fields on records where there was no field
for that on the templates, like
* setting a restriction for journals on accounts
* setting specific values on the company
* modifying journals and linking them easily by using the xml_id instead
of having to compute it manually
Translations
------------
Some countries have multiple languages (i.e. Belgium uses officially
French, Dutch and German, and the CoA also has an official English
version) and we must support the languages in all these countries.
All these translations are known, and hard coded without using out
translation platform (Transifex). We also like to have the English
version (even if an official one doesn't exist) so that support can be
done more easily in databases using chart templates in other languages
(especially using a non roman alphabet).
Because the translations were not on Transifex for these records, it was
really hard to maintain: the translation templates (`.pot` files) were
not easy to extract as the automatic export would give values mixing
both the CoA and the menuitmes, the fields' strings,... But we don't
want to translate the CoA as we already know the value.
Managing the translations in the `.po` files was also annoying:
- it is easy to forget that the translations need an update too
- it requires a special editor, special terminal commands that everyone
is not familiar with
- it is easy to make mistakes in the source string
The new format is the following: `field@en_US` where `field` is the
translatable field (usually `name`) and `en_US` is the locale code.
This allows to have the whole declaration on one line, everything in one
file. It also makes the process easier when debugging: instead of
searching for the translation in the `.po` files, it directly appears
next to the configuration of the account/tax/... .
Update of the code
------------------
The code can be updated using this script
https://github.com/william-andre/transform_coa
Forward ports can be managed too by stashing/resetting/checkout the new
modules or the changes in the modules updated in the same PR.
task-2687567
Part-of: odoo/odoo#110016
Computing the name of multiple moves at the same time could lead to some
errors because we don't know when the field will be flushed:
1: We can't rely on the context to compute moves, for instance when
mixing payments and other moves in a bank journal. The context key
has been removed as it could be useful only when the `payment_id` was
not set yet, which should only happen in the Form view. But the name
of payments was not editable before posting a first time(like it is
for invoices)
Was failing following test with only `account_reports` installed
`TestReconciliationReport.test_reconciliation_report_multi_currencies`
2: There was an optimization tho avoid doing `O(n)` queries to find if
the current move is the first one of the sequence (and needs to be
precomputed in draft because of that). The algorithm is doing the
same `SELECT` after anyways[1] or even a second one to relax the
domain, followed by an `UPDATE` right after. This can't be batched
and delayed because we rely on the SQL unique constraint to assign
the numbers.
Was failing folloing test with only `account_reports` installed
`TestAgedReceivableReport.test_aged_receivable_sort_lines_by_date`
The reason why it started causing issues on some test databases (only
`account_reports` installed, not on a full runbot build) is still
unknown.
[1]: In order to reduce the number of duplicated queries, we could do it
only once per tuple (journal, date range, is_refund, is_payment), but
getting this tuple is not so easy and reliable without a complex
implementation. It is also not really possible to cache and reuse (i.e
in `highest_number`) because the value changes when other moves are
posted.
Part-of: odoo/odoo#110016
We don't want the query count to be impacted by whether a localization
is installed or not.
The code of a localization will most likely always check for the country
code of the company linked to the document, which adds an extra query
only in certain cases.
In order to fix that, we simply always prefetch this before running the
tests. The query count is also adapted because this means that we are
also prefetching the data of the company.
The prefetching is done in a way that it shouldn't prevent detecting
future "query leaks"
Part-of: odoo/odoo#110016
The parents are computed automatically.
This configuration causes a recursion error, during the computation of
the parent path, if we delay the automation of the parents computation.
Part-of: odoo/odoo#110016
`_get_real_points_for_coupon` subtracts several floats which can result
in rounding errors when a comparison is made in `action_confirm` that
checks if the result is smaller than 0. If the result is something like
-1 * 10^-14, Odoo will tell the user the coupon is invalid, which is
false. To prevent this from happening, we round according to the
associated currency of the points.
opw-3120442
closesodoo/odoo#112995
X-original-commit: 59c43f5cc460f311388540558e0fb0731b02cbc2
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
In case of the user have no access to all account.move, the hash result can be wrong.
Before this PR a user with limited access can print this report.
closesodoo/odoo#112970
X-original-commit: 8263b210ea980539941ce10f5c102c9056959b72
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Co-authored-by: John Laterre (jol) <jol@odoo.com>
before this commit, trying to cancel a picking with no move lines, will not move the picking to the cancel state.
* create a new picking
* keep move lines empty
* click on the cancel button
* picking will remain in the draft state
after this commit, on cancelling a picking with empty lines, will move the picking to the cancel state.
closesodoo/odoo#112784
X-original-commit: fefd9402142e9a1f28a2b04b8df96d8fb73d441d
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
UX was lacking comparing to other payment providers,
important fields were not always shown or were checkboxes
when they should be automatically true.
In order to make payment flow easier and more intitive, unnecessary fields
were removed, email is automatically filled. Now when user cancels transaction
on paypal before paying, it automatically cancels transaction on Odoo. Additionaly, quick
onboarding is only available if user already has paypal account and Stripe
no longer installs ond configures paypal if Stripe's onboarding get canceled.
task-2854184
closesodoo/odoo#104974
Related: odoo/upgrade#4025
Related: odoo/documentation#3063
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
For the A-NZ UBL 1.0.8 format, when selecting NZ partners, the elements
in `/cac:Party/cbc:EndpointID` and
`/cac:Party/cac:PartyLegalEntity/cbc:CompanyID` should be the GLN: the
Global Location Number (the corresponding EAS is 0088). The GLN is the
`company_registry` for NZ partners.
Before this fix, the VAT was filled for both elements and it raised a
"GLN must have a valid format according to GS1 rules." error on Ecosio.
closesodoo/odoo#112983
X-original-commit: 2e2ff2813de8b5c1f272eb84319170e07d19154e
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
When a `we-select` has no elements, it is drawn as a flat line.
This commit puts a "/" in its toggler content. This character is the
same one as the one that is displayed if the selected value is not one
of the available values.
Steps to reproduce:
- Delete all `website.snippet.filter`
- In debug mode, drop a "Dynamic Snippet" in a website page
- Select it
=> The "Filter" option was displayed as a flat line.
opw-3166634
closesodoo/odoo#112932
X-original-commit: dc6ff20386567abbabcb2d35388a3dc8995cab28
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
Until this point the access to tokens was somehow arbitrary and
illogical.
After this commit we will uniformize the tokens access rule where by
default an user can only access its own tokens by default and in
function of the use case then relax the rules.
Task - 2832561
closesodoo/odoo#104808
Related: odoo/enterprise#33541
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently, the name's fields to send to Authorize when the partner is a company are:
* firstName
* lastName
if we consider following name `Company Duck Inc`:
the code is sending:
* firstName: ''
* lastName: 'Duck'
Only it sends the `lastName` with the second word found in the name,
due to the new validations in Authorize.Net, this kind of transactions
are marked as suspicious and it's not confirming the transactions, leave them
as pending, this commit is sending the full name in `lastName`
instead of only second word to meet with the validation in Authorize.Net
Also, we are sending the fields `firstName` and `lastName`, with the
maximum length allowed by Authorize.
closesodoo/odoo#112977
X-original-commit: 77d83b327fd99ed090194ec0d3a771c9afc47115
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
Currently we verify the SSL certificate of the iot after starting the nginx web server.
So for the Windows iot if a new certificate is downloaded it will only be loaded by nginx
on the next restart of the iot because the process that runs nginx is a child of the one that runs the iot
With this commit we restart the windows iot if a new certificate is uploaded
closesodoo/odoo#112945
X-original-commit: 880afb3006ece93ee6575c977233bfb61081bf3a
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Louis (loco)