In the `write` method, accessing the `ms_organizer_event_id` field of
`self` leads to an exception if `self` represents several records.
So, the idea of this fix is to set the `need_sync_m` field of all modified
records to `True` when at least a field to sync with Outlook is modified
(see `_get_microsoft_synced_fields()`) and then, at the end of the `write`
method, really patch or delete records that are already linked to Outlook
(that means they already have their `ms_organizer_event_id` field set).
closesodoo/odoo#96761
X-original-commit: 1a66343327f9ea9f59ba25ea63e26331cabb65b5
Signed-off-by: Arnaud Joset <arj@odoo.com>
Previously, attempting to add a class to a button box would crash
because the button box divs are compiled to ButtonBox component which
did not accept a class prop. This commit fixes that.
closesodoo/odoo#96726
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: im_livechat, snailmail_account, survey, web_editor.
The callback registered by the bus service method onNotification was
not the same unregistered by offNotification. Since those method were
superfluous, they have been removed in favor of (add/remove)EventListener.
closesodoo/odoo#96684
Related: odoo/enterprise#29819
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Auto retry can be usefull to avoid breaking a build because of a
small tour or query count, but for long tests like qunit, this can be
painfull when a real error is triggered.
This commit proposes to disable autoretry on demand for some tests
to solve this issue.
This may be applied on all tests longer than a few seconds.
closesodoo/odoo#95440
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When using the wizard to add a bank account, it should be added to
an existing journal only if the journal has no bank account set
and no journal entries.
We also want to be able to remove a set bank account.
When using the wizard to add a bank account (Create it button ;
not Connect button), it should be added to an existing journal
only if the journal has no bank account set and no journal entries.
We remove an unwanted constraint on the bank journals that
prevented the removal of an Account Number (IBAN).
Some UX changes. In the Journal Items list view, specific views
open depending on their move type. This commit also changes
the "View" button of the invoice payment widget on the Journal Entry's
form view in order to align behaviours.
The core open_move method is also moved from the account move line
model to the account move's one for more flexibility.
The "1 Statement" button of the payment's form view now links to the
new reconciliation widget.
The Journal Items lists accessed from the Journal report now show
the partner by default.
The "Unreconciled" filter now filter out partial reconciliations which
have a residual amount != 0.
The Partner column should almost always be shown by default in a
Journal Items list view.
task-2893208
closesodoo/odoo#94923
Related: odoo/enterprise#29092
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
In some case, users use custom `address_format` with keys that do not
exists. This lead to errors in odoo and upgrade process. Avoid
`KeyError` by using defaultdict with `str` value.
upg-361146
upg-361241
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
odoo.modules.load_modules(registry._db, force_demo, status, update_module)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 457, in load_modules
force, status, report, loaded_modules, update_module, models_to_check)
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 349, in load_marked_modules
perform_checks=perform_checks, models_to_check=models_to_check
File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 227, in load_module_graph
migrations.migrate_module(package, 'post')
File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
migrate(self.cr, installed_version)
File "/tmp/tmp1bew9m7l/migrations/website/14.0.1.0/post-adapt-footer-data.py", line 69, in migrate
address = html_escape(partner._display_address(without_company=True))
File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 950, in _display_address
return address_format % args
KeyError: 'town_name'
```
closesodoo/odoo#96703
X-original-commit: 81bf1d2101202a4a6cb832004500129905c2d3be
Signed-off-by: Christophe Simonis <chs@odoo.com>
The top popup, by default, confirm/cancel when Enter/Esc key is
pressed. This behaviour should be ignored when the focus is in
text input fields.
closesodoo/odoo#96769
X-original-commit: 29b34ff8d6ee368add91f58cc4db9533d2779a77
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When a user exports a picking with the option 'import-compatible', he
won't be able to import the record later.
To reproduce the issue:
(Need stock. Use demo data)
1. Inventory > Operations > Transfers
2. Select a transfer (without opening it)
3. Action > Export:
- Enable the option "import-compatible"
- Add the field "Operation Type"
- Export the transfer
4. Back to the transfers list view, click on Import
5. Load the exported file and click on Test
Error: An error message is displayed ("No matching record [...] in field
'Operation Type'"). However, the option "import-compatible" was enabled
and the operation does exist, so the record should be found.
When exporting a record, if one of the selected fields is a relational
one, we use its `display_name` as value:
https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L883-L886
Then, when importing, we use `name_search` to retreive the record:
https://github.com/odoo/odoo/blob/662ecf4e20ceab92b62804cb2a06e51f6b897623/odoo/addons/base/models/ir_fields.py#L406
Back in the use case: if an operation type has a warehouse, its display
name will be the combination of the warehouse name and its name:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L146-L151
However, the `_name_search` does not handle this type of search key:
https://github.com/odoo/odoo/blob/b6833702044b0d3057d543dae71fbea7ef091d98/addons/stock/models/stock_picking.py#L157-L164
Therefore, using that value ("Warehouse: Operation name") in this
`name_search` will not work.
According to the review from odoo/odoo#95526, such a model is considered
as broken: "if the display name (`name_get`) is overridden, then the
`name_search` should be overridden to match". Moreover, the generic
solution proposed in the previous PR would not work in case of
multi-warehouses.
OPW-2739786
closesodoo/odoo#96768
X-original-commit: 456784ca98b3e3bc30c40b1cffe46574930ae492
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
Since [1] the back button did not navigate within the steps of the
website configurator anymore.
After this commit the window location change that happens within the
browser is copied back into the state - thus causing a redraw of the
correct configurator step.
Steps to reproduce:
- Create a new website
- Go to second step
- Press browser's Back button
=> Did not navigate to previous configurator step.
[1]: https://github.com/odoo/odoo/commit/56cc3dfab156f21c7ef97b3c407f1480b094fe93
task-2789075
closesodoo/odoo#96766
X-original-commit: d32f8a9d64f0487e1e61ec7cee7cffde21b8ddb2
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Also includes a fix that properly opens the pos ui when clicking
the button (link) "Click here to close the session".
closesodoo/odoo#96765
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
When canceling a transfer, all its moves and move lines having qty done
(if any) are canceled as well. But this doesn't happen on package levels
having such move lines with qty done filled, the state was set to
'confirmed' while all its move lines are 'cancel', which was not
consistent.
closesodoo/odoo#96764
X-original-commit: d9b16c3732c7e935c21a0396bb01ed4f19456827
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
New styles on forms had broken the full height / no sheet style of
note's form view.
closesodoo/odoo#96741
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Due to the new form and list views some of the customisation of loyalty
were not working properly anymore.
This commit adapts the js customisation inside of loyalty to wowl 2.
TaskId-2929488
closesodoo/odoo#96731
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Steps to reproduce:
- Create an accrual plan and an allocation request such as described
in the added test and validate the allocation request
- Run the scheduled action for accrual plan computation
- Check the number of allocated days
Expected behavior:
The first level should bring 6 days, the second 3 days and the last
1 day for a total of 10 days
Current behavior:
The 3 level give non integer values closed to the expected for a
total of 9,... days.
Explanation:
When transiting between two levels the nextcall was the last day
of the current level to have the right level, this creates an
inconsistency as the end_date of the _process_accrual_plan_level
level should go up to the first day of the next level to have the
full number of days expected. To solve the issue we change the
level selection so that if the date is the first day of the
level it is still in the previous level. We also modify the places
where the nextcall was modified when transiting level so that there
is no more one day delta anymore.
opw-2868297
closesodoo/odoo#96665
X-original-commit: 5d055130c97c5d8367c2b71fc617f588c5e15741
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When displaying the price of a shipping method, if its type is "Fixed
Price", the option "Tax-Included" is not considered.
To reproduce the issue:
(Use demo data)
1. In Settings:
- Product Prices: Tax-Included
2. Create two shipping methods:
- SM01:
- Provider: Fixed Price
- Set a customer tax of 15% on the associated delivery product
- Fixed Price: 100
- Published: True
- SM02:
- Provider: Based on Rules
- Set a customer tax of 15% on the associated delivery product
- Pricing:
- If weight >= 0: Cost = 100 + 0 * weight
- Published: True
3. Open the eShop
4. Add the Customizable Desk to the cart
5. Process checkout
Error: When displaying the delivery methods, the price of SM01 is
incorrect: $100 instead of $115. In other words: the tax is not in the
price, as it should according to the settings. (The price of SM02 is
correct: $115).
The displaying of the shipping method price depends on the shipping
method type:
https://github.com/odoo/odoo/blob/68b08164e5de353ea0c48de92d0c0e028b49bc52/addons/website_sale_delivery/views/website_sale_delivery_templates.xml#L35-L46
If the type is `fixed`, we display the `fixed_price` field of the record
(that is the value encoded on the shipping method form, so it does not
include any tax)
If the type is different, we just display a text: "Select to compute
delivery rate". And, when loading the page, a JS widget gets and
displays the rate for each shipping method (including SM01!)
https://github.com/odoo/odoo/blob/204a2bb5553a275e785fbb9ccefbe26b06ef4ba1/addons/website_sale_delivery/static/src/js/website_sale_delivery.js#L38-L47
And in that case, the rate returned by the RPC includes the tax (if
needed):
https://github.com/odoo/odoo/blob/bc2615d8ab5135f21c488c5a260c59605b0da498/addons/website_sale_delivery/controllers/main.py#L57-L60
That is the reason why the displayed price of SM02 is correct.
When the widget gets the prices, it uses the classes to find and replace
the rate with the one returned by the server:
https://github.com/odoo/odoo/blob/204a2bb5553a275e785fbb9ccefbe26b06ef4ba1/addons/website_sale_delivery/static/src/js/website_sale_delivery.js#L95-L105
However, if the shipping method type is `fixed`, it does not have the
class `o_wsale_delivery_badge_price`, so the SM is not found and its
type is not updated (that explains why the displayed price of SM01 is
not correct).
Because the widget gets the rate of all shipping methods, we should take
advantage of that and let the widget apply the result on each method,
even if the type is `fixed`
OPW-2854341
closesodoo/odoo#96657
X-original-commit: ba210fe1dbcfe3026e6f34b94a5defd2fb4cd15d
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
_description of the `hr.payroll.structure.type` should be "Salary
Structure Type" instead of "Contract Type"
closesodoo/odoo#96653
X-original-commit: 49ecc72b2971edc57f85d4bea50901021b4f3f7b
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Since odoo/odoo@2dd37982e6 , Kanban
column's width is flex based. But sadly two types of columns were not
adapted properly:
- Kanban small column didn't reduce the column width
- Quick create kanban column shrinked too much
This commit fixes both these issues by properly setting the flex-basis
size for one and disabling shrinking for the other.
closesodoo/odoo#96650
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When navigating backward to step 2, the website purpose is reset in
order for the navigation to not automatically advance to step 3.
Because of this, when navigating to further steps with the browser's
forward button, that field remains empty. This ultimately produces
an error when the configurator state is extracted to generate the
website.
After this commit the former selected purpose is kept when no purpose
is selected anymore. It is then used when collecting the configurator
details if there is no selected purpose.
task-2789075
closesodoo/odoo#96640
X-original-commit: d874958aa44c0bd96ab7b84f7066c9b8d28642d6
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
With the conversion of views to the new webclient, the o_xxl_formview
class was no longer applied as expected, which broke the layout and the
width calculation in embedded list views (as the chatter would take up
more space than intended during the width computation). This commit
fixes that by adding the class when needed.
This commit also moves the css rules relative to that class which are
mainly used for the side-chatter, from enterprise to community, as the
side chatter has been made available in community as well.
closesodoo/odoo#96627
Enterprise: odoo/enterprise#29803
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
As the `color-contrast` function provided by BS5 basically fulfill the
same need as the custom `o-get-most-contrast` function and the later one
isn't used, we can safely remove the custom one.
closesodoo/odoo#96626
Note: last (and only) usage was in mrp_workorder's tablet view.
Related: odoo/enterprise#29802
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Steps to reproduce:
- Create a leave request for multiple employees
- Go in the employee list
Current behavior:
The leave request is not visible in the list view
Expected behavior:
The leave request is visible in the list view
Explanation:
Previously a domain on the list view restricted the
records to the one that had an employee_id with the
right company but this condition was never met by the
the multi_employee leaves as they have no employee_id.
To solve the issue we add to the domain a condition to
accept multi_domain employee that have the right state
and the right company.
opw-2917291
closesodoo/odoo#96625
X-original-commit: f1c7c3737d3420a1356fd8e24d7970edcdb571c6
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose: Allow users to make product 'expense available'
(or the opposite, unset them as expense products) by making the
field 'can_be_Expensed' available in the base product view.
task - 2909067
closesodoo/odoo#96619
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit refactors the way we handle the "<>" case in domain
evaluation, for the sake of consistency with the "==" case. Indeed,
we tried to avoid using JSON.stringify as it could have an unwanted
behavior (e.g. it could crash, or it could have been overridden on
the value we manipulate).
closesodoo/odoo#96614
Signed-off-by: Géry Debongnie <ged@odoo.com>
By enabling the method '_employee_values_sync' the original behavior is
keep. Furthermore, by overriding the method now is possible to decide
either a field is synced or not into employee.
closesodoo/odoo#96609
X-original-commit: 46c12cc0f72b2a6aba907fe903a255aed61a1695
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Since the revamp of the Kanban View in mobile and the migration of the
Settings view to the OWL views, the jQuery.touchSwipe library is not
used anymore.
closesodoo/odoo#96608
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- A user has accounting permission but no employee permission, when that user creates a payment in spending it gives an error that does not have access to the bank_account_id field
- This commit allows the user to read the bank_account_id field when creating a payment
closesodoo/odoo#96607
X-original-commit: 8045780cbf2dc36d533dbfd3315bab31a229351d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Before this commit, the records created in grouped kanban view via
the quick create feature were displayed in the bottom of the column
where they had been created. They should be on top. This commit
fixes that issue. Note that this only concerns the state of the
kanban view before the next reload, as from that moment onwards,
the default order on the model is used.
Issue introduced by the conversion of the kanban view to owl.
closesodoo/odoo#96606
Signed-off-by: Samuel Degueldre <sad@odoo.com>
When using _prepare_analytic_distribution_line, it would take
the company for the line from the distribution, then the env.
This would cause multicompany issues in some case, creating the
line for the wrong company. By using current the move line to
get the company before falling back on the env, we can avoid such
an issue.
OPW-2900827
closesodoo/odoo#96465
X-original-commit: 8c10324f062e4cd239494545cdfce7cde7ffadbb
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
*: calendar, im_livechat, survey.
Following @ged-odoo review, the multi tab service has been improved:
- multi_tab_service.js has been moved to the correct location.
- _callLocalStorage method has been removed and replaced by
getItemFromLocalStorage/setItemToLocalStorage.
- underscore.js calls have been removed.
- multi_tab_service is now using function closure style instead of class.
- multi_tab service is now using its own bus instance.
- service name is now in snake case as per convention.
- tests have been added.
- multi tab service now handles setting/removing/getting values
shared between all the tabs.
closesodoo/odoo#96386
Enterprise: https://github.com/odoo/enterprise/pull/29694
Related: odoo/enterprise#29694
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Adapt the wording since the edit button is not always on the top
right corner but can also be on the top left one. Also make the
info alert non editable, and add a placeholder to indicate the
editable area.
Task-2924229
closesodoo/odoo#96371
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The purpose of this component was not helpfull
as it has no real use case and was only used
by the BinaryField component.
Instead of using an entire component, we only
keep the DOM that is now used directly in the
BinaryField template.
closesodoo/odoo#96357
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes the wrong implementation of the
field. It was not functional and is now using the
FileInput component.
Before the commit, it was not possible to upload or
delete files from the list. Test has been adapted to
those changes.
Toast notifications were also missing, and a new
test has been added to check that a notification is
correctly displayed when the server responds with a
error message for a given file.
Part-of: odoo/odoo#96357
Since [1] and even after [2] when replacing a media by a media of a
different type only classes were cleaned - but all inline styles were
copied.
This commit filters the inline styles when replacing a media by a media
of another type.
Steps to reproduce:
- Drop a "Text - Image".
- Replace the image by an icon.
- Apply solid colors for the foreground and the background.
- Replace the icon by an image.
=> The applied colors were kept in the inline style of the image.
[1]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344
[2]: https://github.com/odoo/odoo/commit/9ca349bbdb75505e8dbd31898f05ba8d694e7953
task-2687506
closesodoo/odoo#95853
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since [1] when replacing a media by a media of the same type or that has
some extra classes in common, those classes were removed instead of
being kept.
This commit makes sure only the classes that do not exist in the newly
selected media type are removed.
Steps to reproduce:
- Drop a "Text - Image".
- Replace the image by an icon.
- Apply a circle effect and colors on the icon.
- Replace the icon by another icon.
=> The applied effect and colors were lost.
[1]: https://github.com/odoo/odoo/commit/9ca349bbdb75505e8dbd31898f05ba8d694e7953
task-2687506
Part-of: odoo/odoo#95853
Commit [1] moved the editor in the backend introducing changes to the
way some options interact with the website. This unfortunately broke
the header position option, the header background option and the footer
visibility option.
The header position option would loop indefinitely, the header
background color option would not display the correct preview colors and
the footer position would trigger a traceback.
This commit fix those bugs:
- The header position option had a callback that was never called, it is
now called.
- The copy of styles introduced by [2] is now less implicit. Only styles
that are defined in web_editor/common/utils:
[EDITOR_COLOR_CSS_VARIABLES] are copied on the snippet menu, and only
those variables will be used as background colors for the preview
elements. (Allowing for every other colors like black and white to be
used with classes).
- The footer visibility option had a broken line of code that was copied
from past code. It is now fixed and working.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/212a8bfdd21269b18054200b9e2585e1c95540d6
task-2687506
closesodoo/odoo#94949
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since this commit [1], when you select the Header position option and
set it to "Over The Content", the change is not saved if you did not
edit something else in the page too.
Indeed, now that the "save" works correctly (and that it no longer saves
the page every time). It does not detect the change made by this option
which is to add a class on the '#wrapwrap' element. (The editor looks
for changes inside the wrapwrap but not on it).
This commit checks if any page option is dirty on save on top of
checking if the content of the page has been modified.
Additionally, this commit fixes a bug that would occur on Firefox based
browsers where the hidden input used to display the status of these
options would be auto-completed by the browser in some conditions.
(https://bugzilla.mozilla.org/show_bug.cgi?id=520561).
This could result in an incorrect state being displayed.
To reproduce:
- Change the option, click on cancel, start the editor
- the incorrect state is displayed
A test is also added by this commit to verify that all the page options
works correctly.
[1]: https://github.com/odoo/odoo/commit/bab673488e185ddd7792aedecc3870663290fed3
task-2871426
X-original-commit: ea7a69b344d970cc2b31555f4cd8fd7c5e2fc6d2
Part-of: odoo/odoo#94949
In SearchModel, the calls to search_panel_select_range and
search_panel_select_multi_range were done without using the global
context (e.g. the action context), contrarily to what is done in the
legacy SearchPanelModelExtension. We fix that.
closesodoo/odoo#96458
Signed-off-by: Géry Debongnie <ged@odoo.com>
During the BS5 migration, the .text-body class wasn't properly ported.
As it is a standard Bootstrap class and useful to override component's color with the one used by the body (ie. set a heading color the same as the content).
This commit restores it.
closesodoo/odoo#96173
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
When receiving more than expected, we try to redirect the SM thanks to
the putaway rules. This can lead to undesirable behaviors.
To reproduce the issue:
1. In Settings, enable 'Storage Locations'
2. Create a storable product P
3. Edit the operation type "Receipt":
- Show Detailed Operations: True
4. Create and confirm a planned receipt for 1 x P
5. In the Detailed Operations:
- Set the done quantity to 3
- Set the destination location to Shelf 1
6. Validate the receipt
Error: The destination location of the SML has changed: Stock. It should
still be Shelf 1
When validating the SM, because the done quantity is more than the
demand, an exra-move is created. During such a process, the extra move
is confirmed and assigned, so it leads to the destination redirection
thanks to the putaway rules (that's the reason why the destination Stock
will be selected and defined on the SML).
In such situation, we should not try to apply the putaway rules.
OPW-2900283
closesodoo/odoo#96124
X-original-commit: 0183298293192538a801f52262c047ea34a1b76a
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
The alert block content and style for the transaction status after
payment were computed in two different places: In the dedicated
`payment.transaction_status` QWeb template, and in the
/payment/confirmation` route's controller which, for some reason, was
re-inventing the wheel instead of relying on the dedicated template.
This commit combines the slightly different behaviors in the template
and gets rid of the duplicated logic in the controller to:
- Handle the states 'draft' and 'error'.
- Always show the transaction's state message, and not only when the
transaction was in a state for which there exists no pre-defined
message (`draft` and `error`).
task-2924873
closesodoo/odoo#96348
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
==== Short version ====
Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything to keep the Google Analytics dashboard in
Odoo.
In previous stable version, it was kept but is displaying a warning
about it (as until mid 2023 old accounts can still embed it).
All this is about the embed dashboard, not the tracking in itself for
which Odoo is already adapted in Odoo 15.0 for Analytics 4.
==== Detailed version (following short version, read it first) ====
- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
to be embed in external websites. They seem to just have dropped the
"feature".
This was confirmed by Google here [4] and indirectly here [5] in the
DOC:
`Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
The threshold seems to be somewhere mid-2020, according to [6].
It seems to be accurate as my own key from 2018 still works, while my
keys from 2021 do not.
==== Fix ====
- In stable, warn user about it in their Odoo Analytics dashboard (this
PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
integration and remove the doc about it, see [7].
==== Useful links ====
[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html
Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.
opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890
closesodoo/odoo#96280
X-original-commit: d065595f77790fb5ab9480f6de5b88549352324b
Related: odoo/enterprise#29666
Related: odoo/upgrade#3698
Related: odoo/documentation#2499
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Filter product templates search result if there are any possible attribute
combination to get/create a product variant regarding the searched attributes.
For example if the combination (A, B) is excluded, filtering on (A, B)
will filter that product out of the result.
task-2558970
closesodoo/odoo#89018
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
This commit adds the possibility to define a maximum payment amount that
a given acquirer can process. If the payment amount exceeds the value,
the acquirer is filtered out of the available acquirers listed on the
payment forms.
While we're at it, the field `country_ids` is renamed to
`available_country_ids` to better depict that it is not a property of
the acquirer, but a configuration option. It will also be coherent with
the field `available_currency_ids` that is expected to be added soon.
Task - 2162165
closesodoo/odoo#82411
Related: odoo/enterprise#24412
Related: odoo/upgrade#3703
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Steps to reproduce:
1- install POS in multicompany env
2- create a customer c from POS UI
3- c doesn't belong to the active company
Bug:
the company_id is not set when the customer is created
Fix:
set comapny_id to current active company for new customers created from
POS
OPW-2881551
closesodoo/odoo#96073
X-original-commit: 3aa03eb65d431cb9749a2b31a9a09d6b41cd34a4
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Rémy Baranx (bar)