Field tooltip lacks domain information because of a small mistake in
`getTooltipInfo` function.
To reproduce: open a form in debug mode and hover any many2one field that has
domain in its configuration. Example: ``hr.expense:sale_order_id``
opw-3049554
closesodoo/odoo#106225
X-original-commit: c2663c0493f8330041ba426ce233a2a73fda048a
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Purpose of this commit to improve generic usage of project app.
So in this commit done following changes:
- rename 'total hours' into 'total hours spent' (or 'total days spent' if the
timesheet encoding unit is in days) for project.task
- timesheets (billed on timesheets) section > group the graph view by
invoice > employee
- add default action project update > profitability> timesheets
(billed on timesheets) section > group the grid view by
invoice > employee (display sections)
- add default the 'timesheet costs' measure in pivot view
- display 'hours remaining' in red if the number is negative for project.task
form view
- display the 'week' scale by default in the grid view
task-2819458
closesodoo/odoo#90270
Related: odoo/enterprise#26795
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
**Issue:**
When at the first page of the list, and the user deleted all/or some
of the records, the next page is not automatically displayed.
**Solution:**
This is because the first page (offset=0) is exempted from offset
adjustment (_adjustOffset) which is responsible in reloading the
records in the list.
In this commit, we propose to reload the list if the call to
`_adjustOffset` didn't call `load` and there are actually deleted
records.
closesodoo/odoo#106317
X-original-commit: 2863978041d2856644da938ced9eedc640b8f198
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
**Issue:**
- Open a list view and group the records. Notice the count per group.
- BUG: When deleting a record under a group, the count in the group
is not updated.
**Solution:**
When calling `deleteRecords` in the `DynamicGroupList`, we call
`deleteRecords` on each group's `list`. This "list" can be
`DynamicGroupList` or `DynamicRecordsList`. Regardless which instance
calls the `deleteRecords` method, we should take the number of the
deleted records and subtract it from the group's current count.
If it turned out that the calling object is a `DynamicGroupList`,
we should make sure that it returns the ids of the deleted records
so that the parent group can update its count as well, that's why
we are collecting the deleted record ids.
It's not so easy to follow but we can roughly imagine the structure
this way:
DynamicGroupList
-> DynamicGroupList[]
-> DynamicRecordsList[]
Deleting items from the inner dynamic records list should result to
update of the parent group list, and eventually, to the update of the
root group list.
X-original-commit: 865c1b37f7986f00b85c9e8135e46cc4b2ac70da
Part-of: odoo/odoo#106317
The logic to set the focus on the emoji search bar was only triggered
the first time any emoji picker was opened.
This makes sure the focus is processed every time a picker is opened.
task - 3035021
closesodoo/odoo#106315
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Non EU vendor bills are sent to the Tax Agency as self-invoices,
so the partner actually is the seller, but the same checks on the
VAT must apply as it was the buyer.
Task: https://www.odoo.com/web#id=3010849&model=project.task
opw-3010849
closesodoo/odoo#106312
X-original-commit: 8c18b870ecc04314380fcdb6b61179de78e28703
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Some missing aria attributes from 14.0 are reintroduced.
They are required for screen reader users to be able to know if menus
are opened and if menuitems are checked (e.g. if a filter is applied).
closesodoo/odoo#106277
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Dropdown menus/items were refactored and moved to OWL when migrating to
15.0. Now, the focus is always on the dropdown button, which captures
and handles all keyboard events, to be able to move over the menus.
Currently-selected item is highlighted by toggling classes.
However, since the focus is always on the dropdown button, screen
reader users are no longer able to know what menu item is being
selected, as it's only a visual change (in previous versions, the focus
actually moved to the selected element).
The above is fixed by making the activeElement follow the visual change.
Part-of: odoo/odoo#106277
Co-authored-by: Luis González <lgonzalez@vauxoo.com>
Detailed Reason field in hr_departure_wizard view is now wrapped in a group for better organization.
task-3002105
closesodoo/odoo#106304
X-original-commit: 824f62c59fd4408b1460826c2b0f0732bd10c2fd
Related: odoo/enterprise#34282
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Steps to reproduce:
- install the "Subscriptions" module;
- create a subscription;
- got to the portal of the customer of the subscription;
- click on the "Set/Manage Payment Method" buton;
- add a new payment method.
Issue:
An invoice is generated and therefore the next invoice date is incremented.
Cause:
We do not check the type of operation when we finalize the payment process.
And so a subscription renewal invoice is created.
Solution:
Transactions with "operation" which is equal to "validation" are for tokenizer only (without payment).
If "operation" is equal to "online_token", it is a payement which must be invoiced.
Detect payment token change, if this is the case to not generate an invoice.
opw-3061621
closesodoo/odoo#106300
X-original-commit: 29bfe42904af485614ef8546490dc2ed31ecc785
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
When creating a record, if a value is related to a monetary field and if
the currency field is a non-stored related one, the value will not be
rounding: when writing the monetary value in the database, we first call
`convert_to_column`. In the parameter, `record` is empty (it is not yet
created) and `values` only contains the stored values (so the currency
value is not present). As a result, `currency` will not be defined and
the value will not be rounded.
OPW-2955202
closesodoo/odoo#106283
X-original-commit: 28196693b50b9d424887391ad13db69c5f5dfe4f
Related: odoo/enterprise#34265
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Change class="oe-blackbox" to data-oe-protected="true" (same purpose), because
the name was decided in a rush before 16.0
When the editor history management and sanitization (sanitize.js) handle nodes
of an embedded view, OWL can become corrupted, which will lead to a traceback.
This commit uses the attribute data-oe-protected="true" to prevent
historyRollbacks or sanitization, and ensure that protected elements children
are removed during the cleanForSave operation.
The collaborative DOMPurify sanitization is untouched, for security reasons. To
properly use `data-oe-protected` in collaborative mode, a more complex
mechanism should be put in place to ensure that the protected element children
are properly reconstructed for each client, and that it is not part of the
collaboration. (i.e.: embedded view in knowledge do not support the
collaborative mode currently).
This commit also blocks the selection handling in tables which would be in a
data-oe-protected="true" node.
Task-3012552
closesodoo/odoo#106255
X-original-commit: 394e4fe567bb2eecbd0865de82914aa7396fde63
Related: odoo/enterprise#34245
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
Signed-off-by: Abeloos Damien (abd) <abd@odoo.com>
When marking a WO as done, if the serial number defined is related to an
unbuilt product, an error will be raised and the user will not be able
to mark the WO as done
To reproduce the issue:
1. Create a BoM for product P with one operation
- P is tracked by SN
2. Produce one P with serial S
3. Unbuild it
4. Create and confirm a second MO with 1 x P
5. Start the WO
6. On tablet view, set the finished lot to S
7. Mark the WO as done
Error: a UserError is raised because "This serial number [...] has
already been produced". However, this serial number has been unbuilt so
the worker should be able to use it again
When marking the WO as done, we check the uniqueness of the defined
serial number. But:
- The check is not accurate enough, hence the above error
- The lot of the WO is a computed/inverse field based on lot of the MO
- Once the WO closed, we can still change the lot of the MO
- When marking the MO as done, a better method checks the SN uniqueness
(does not fail in the above case)
Therefore, the checking on WO side is useless. We should let the MO side
handle this.
Moreover, let's say that there is already one P in stock with serial S2.
On tablet view, if the worker set the lot to S2, there should be a
warning so he can be aware of the situation. This is already the case on
MO side:
https://github.com/odoo/odoo/blob/45e37b2ad7bdcfd9f9f7e1dabbd0a99c9a0b5cdc/addons/mrp/models/mrp_production.py#L694-L705
(This commit is linked to a similar commit OE side, same opw)
OPW-3002424
closesodoo/odoo#106152
X-original-commit: 60a4c37c781ceb20123cb99603ddd2890b1c806c
Related: odoo/enterprise#34183
Signed-off-by: Tiffany Chang <tic@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
**Before this commit**
Various issues are present in the calendar filter autocomplete:
- typing a character in the input would close the autocomplete dropdown
- search for a term yielding to no results would not display the
"No records" entry
- click on the "Search more..." entry yields to a validation error
message: "a mandatory field is not set". [1]
**After this commit**
The FilterAutoComplete component has been removed as it was useless.
It was a kind of higher order component trying to manage the
AutoComplete component's input state, leading to unwanted complexity.
We decided to remove this component despite being in a stable branch
for the following reasons:
- it was not exported and only used by the CalendarFilterPanel
- it brought unnecessary complexity
- it was not working properly
- the branch is still a bit young
- the diff in the CalendarFilterPanel template is minimal
Now that the CalendarFilterPanel directly make use of the
AutoComplete component, the first listed issue has been solved.
The two other issues were simple fixes addressed in the mean time.
[1] this issue comes from opw-3031045, more infos below:
Steps to reproduce:
- Go to calendar basic view
- Click on "+ Add attendees" and then on "Search more ..."
Current behavior:
Validation error on partner_id in calendar_filter create
Expected behavior:
You can look for a partner with advanced research options
Explanation:
The code treated the "Search more ..." option like a partner
option instead off calling the onSearchMore method that creates
the advanced research dialogue.
opw-3031045
closesodoo/odoo#106292
X-original-commit: 73af1d04d9d49eace16e3f88c32ce5d457b44b83
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Martin Fockedey <mafo@odoo.com>
Co-authored-by: Hubert Van de Walle <huvw@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Graphs were not aligned depending on data. They will now stick to bottom of the card and fill consistently the space above.
closesodoo/odoo#106276
Task: 3071124
X-original-commit: f39904cbe8db3a4788b6771e2f4591d94dd38363
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Steps to reproduce:
- install sale_management module;
- go to settings of sale_management and check "Automatic invoice" parameter;
- in debug mode, we can see the template selected (do not change it);
- save the settings;
(This is just one example)
Issue:
The parameter is not added to the "ir_config_parameter" table.
Cause:
The improvement which consists in comparing the settings which one wishes to record with those which already exist in order to set the parameters which are different creates a problem.
Indeed, the current settings are retrieved directly from the model with their default value if there is one.
These are the values that will be used for the comparison.
Because of this, when we want to save a parameter which is set to its default value (on first save), the logic will not notice a difference.
Therefore, the parameter will not be saved in the "ir_config_parameter" table.
Consequence:
In the code, when we wanted to look up the value of a parameter, if it is not saved, we use its default value instead of saving it with its default value.
Example:
```
field_example = fields.Integer(string='Example', default=1000, config_parameter='model.field_example')
value_field_example = params.get_param('model.field_example', default=1000)
```
The default value is repeated.
Solution:
To know whether or not we add a new parameter in the "ir_config_parameter" table, we must look at what already exists in the table and not in the settings defined in the model.
opw-3057306
closesodoo/odoo#106188
X-original-commit: d881dfaaa163b409a94494e35afa2cbda7cf2aa2
Related: odoo/enterprise#34258
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
In the hr_contract_history list view, some owl code was set to
allow employee creation from that view. Since the create button
has been removed, that code was unused.
closesodoo/odoo#106264
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Commit [1] actually "repair" the test theme installation that was
actually not calling `_post_copy()` for the website/themes created
through the `_post_init` hook of the `test_themes` module.
By doing so, the Nano theme now correctly activated the
`footer_language_selector` view, meaning that the tour would fail as
this Nano view would mess up with the tour (that Nano view was returned
on top of the Theme custo view).
Those website standalone tests should really be part of the regular
testing suite and not in the nightly build only:
1. This is getting really annoying to fix it again and again, we
wouldn't have to do that if it was in the regular testing base as it
could not be broken. This is a waste of time for no reason, as we
need to investigate, understand and find a fix.
2. For now it only broke due to no real bug, most of the time it is
because the test need to be adapted to a theme change or something,
but one day someone will be able to break the website core mechanisms
(COW, theme install etc) and this will be problematic.
Note that if this was to happen, the runbot team will be handling the
issue and the fix with the people that broke it, as it was promised
when we discussed about moving those tests in the regular testing
suite. It was the conscensus for us to accept to leave those tests in
the nightly only (we didn't really had a choice tho).
[1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759cclosesodoo/odoo#106203
X-original-commit: 17a182fb3ee652a8a52654c5707c0ed265404630
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the conversion in OWL of the `many2one_barcode` widget, on Mobile
when we open the search more a filter value is added automatically in
the filter and so when we want to change the value we need an additional
step to remove the filter to see all records.
This commit, use a 'custom event' to open the barcode search and restore
the normal behaviour on the `click` event.
Steps to reproduce:
* Go to Timesheet
* Add a new line
* Select a project
* Try to change the project => BUG show only the selected project
closesodoo/odoo#106267
X-original-commit: 6d7f5a0abd79f6185831a2b9617b031d13da89be
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
Co-authored-by: Romain Estievenart <res@odoo.com>
It is not possible to post the journal entries related to an expense
paid by the company
Steps to reproduce:
1. Install Expense
2. Create an expense payable to company
3. Set an amount
4. Create report
5. Submit report
6. Approve report
7. Attempt to post
8. An error is thrown
Solution:
Relax the constraint on account.move.line linked to an expense paid by
the company
Problem:
The constraint `_check_payable_receivable` in the account module forbids
to post the journal entries even though they are correct
opw-3038648
closesodoo/odoo#106266
X-original-commit: 09274db12a25c178974dc20c4d669134e21cddbe
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Before this commit, new model term translations cannot be saved if it has been
translated before.
The reason is while translating fr_FR
the backend needs the mapping {old_term_fr: new_term_fr} to update old_value_fr
However the UI sent {old_term_en: new_term_fr} which was wrong
This commit fixes the bug by changing the key of the mapping from the
old_term_en to the old_term_fr
opw-3074712
closesodoo/odoo#106257
X-original-commit: f28c11917e093d0d3f5d18f0b377cfb24a7dbd92
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
The wsgi application entrypoint moved during the [httpocalypse]. Some
clients don't use the odoo builtin wsgi server and have troubles
upgrading from 15.0 to 16.0 because the `odoo.service.wsgi_server`
module doesn't exist anymore.
[httpocalypse]: https://github.com/odoo/odoo/pull/78857closesodoo/odoo#106187
X-original-commit: 4e5d7d2e93fcd082bd1b3a9e76cedab85b46f456
Signed-off-by: Julien Castiaux <juc@odoo.com>
"Demo token" badge is only displayed for tokens created under Demo provider.
This is misleading and should be connected with provider state not it's name.
It should be shown on every token created under "test mode".
task-2908903
closesodoo/odoo#101937
Related: odoo/upgrade#4023
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Before commit, clicking on the "App Store" and "Updates" menus in Apps
in debug mode causes a crash.
Why:
Since owl 2, rejecting a promise in onWillStat is considered an error
and so we have a crash. In our case, the error is already handled
(Display a notification and do a doAction). So we can resolve the promise.
The two menus ("App Store" and "Updates") will be removed in master.
closesodoo/odoo#106247
X-original-commit: 08c8d64eedb509cdeafa1cecceb28f00a3bd98f0
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
The job_title field was too narrow and misaligned on mobile.
Removed the help text for the Contacts smartbutton.
task-3070980
closesodoo/odoo#106240
X-original-commit: 37fcdb0c105674ae0f45461c85668ed0b0ee2922
Signed-off-by: Kevin Baptiste <kba@odoo.com>
**Issue:**
- Open a list view with `expand="1"` and `limit=<arbitrary small number, say 5>`.
- BUG: The pager shows that it's displaying the limited records, but in reality,
it's displaying all records under each group.
**Solution:**
This is because we are *not* limiting the number of records being fetch in the first
read_group rpc. We are now specifying the expand_limit in this commit.
closesodoo/odoo#106238
X-original-commit: e5bba9f5eb63ee95924c892801fe18feaef6d1fc
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently, in mass mailing, the user cannot be redirected to the next
page after clicking "upload a file" in the import mailing list.
This is because the contact list field is mandatory, so when the user
clicks "upload a file" with an empty contact list, it is unable to
be redirected to the next page, as it saves the wizard before executing the
action.
This commit fixes the above issue by making the contact list field
not mandatory anymore in the wizard view.
Oversight of: aa183fa29d609d2b608fa451ee48a35e3d1549b2
taks-3070829
closesodoo/odoo#106237
X-original-commit: 21272221ebf22b3075c79a759c8ad8f72825b1ef
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
**Steps to reproduce:**
- go to a product page
- replace image (=> image is shown)
- click on "Save manually" (the cloud upload icon)
- BUG: previous image is displayed.
But it was saved: if you move to another record and return then it
shows the correct one.
**Solution:**
Basically, in an image_field: If its props.value is a "binary size",
then the image source is a url pointing to a server endpoint and
this url is based on the rawCacheKey, otherwise, we use the "base64"
of the uploaded image.
The proposed solution for the said issue is to invalidate the
rawCacheKey during upload. Then, during the calculation of image url
(at `getUrl`), we reassign the rawCacheKey with the newest
"__last_update" value of the record when needed (if the props.value
is a "binary size").
closesodoo/odoo#106236
X-original-commit: 93911daab238e96c8aa9b0a951b9a268d83a9847
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Steps to reproduce the issue (see opw):
- Add a form to a page
- Add a checkbox
- Add a second checkbox that is required and visible only if the first
checkbox is not checked
- Save
- Do not check anything and try to send => Good, you can't, the required
checkbox is not set
- Check the second checkbox and try to send => Good, you can, the
required checkbox is set
- Go back to the empty form, check the first checkbox and try to send
=> Bad, you can't but you should: the required checkbox is hidden, it
is not supposed to be required anymore.
(Not that arguably, that two checkboxes setup should be replaced by a
required selection field but the issue of the OPW would remain as there
is another required conditionally-hidden field (a file upload) when the
second checkbox is checked.)
Conditionally-hidden fields should not require validation while they are
hidden. Indeed, their purpose is to be able to enter additional data
when some condition is fulfilled. If such a field is required, it is
only required when visible. The problem only occurred with checkboxes,
the other fields were already working in that case. Although there could
be issues with dates too, this commit added a series of FIXME and TODO
comments as well as some things need to be investigated.
opw-3003952
closesodoo/odoo#106204
X-original-commit: f501c25a9d33399cfbb45526d95038266d91686e
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when submitting a website form which has invalid
radio buttons, checkboxes or file upload elements, they had no visual
difference. Now they will have red labels as intended with bootstrap.
For alone checkboxes, a warning label will appear after the checkboxes.
This will only take effects for newly added checkboxes.
Related to opw-3003952
X-original-commit: 3268b4c902c92c12f50081d31eb08d4c330ca03f
Part-of: odoo/odoo#106204
With [1], checkboxes in website forms were wrapped in a <div/> with the
"form-check" bootstrap class (as they should). That forgot to mark the
checkboxes themselves with the class "form-check-input". Without it they
are misaligned.
This fixes the error for newly added checkboxes in forms. Old ones will
stay "broken".
[1]: https://github.com/odoo/odoo/commit/9ea276ae2f00c3a5ba4e10af313085947e70e265
Related to opw-3003952
X-original-commit: b3ff062e8add1e9b810a37112f05a0c1d23136be
Part-of: odoo/odoo#106204
Before this commit, if the user tried to setup a required selection
field whose first value is empty, it was possible but the empty value
appeared as a 0px-height div in the DOM preview. That empty value also
shows up when trying to use the conditionally-hidden fields feature: if
another field's visibility depends on such selection field, the editor
UI was visually broken as the first choice was an empty option element.
Now, we show "<no value>" in both cases.
Note: this is not done in earlier versions than 15.0 although the
problem exists, but it was decided that the real problem was about the
visibility select being visually broken and that feature only appeared
in 15.0.
Related to opw-3003952
X-original-commit: a62f3dbef31c4750ba16d55adf28c235a27dbc56
Part-of: odoo/odoo#106204
When we have too many products from orderpoints we cannot compute the
forecasts for all at once. Otherwise we may get a MemoryError. Here we
iterate by chunks.
This error was observed on upg-417045, where there were 381927 prodcuts.
closesodoo/odoo#106196
X-original-commit: feea4e5f147b3b26cbc032daaf0ceabbe3417912
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Alvaro Fuentes Suarez (afu) <afu@odoo.com>
This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909
Fixes 2687380
Fixes 2856101
closesodoo/odoo#106180
X-original-commit: ac0ca14c349e0d70d9f3a1aeb720f5e31f16d63e
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
This PR
Reverts the change in #105425 as the code is redundant see Discussion
Fixes the issue and explain the details as it doesn't get triggered from
inventory adjustment view but from current stock view in location X.
Steps to reproduce:
- Install inventory
- Activate storage locations
- Allow import in Locations/WH/Stock/Current Stock
- Export the current stock of WH/Stock
- Change the Location in the file to WH/Output
- Import the modified file
In the Location/Current stock view, the _load_records_write/create methods are bypassing the allowed_fields checks in the def create/write since this check only occurs when _is_inventory_mode() = True. This can cause inconsistencies if there are quants reserved. To solve the problem we set inventory_mode to True so that the method returns True and the checks are triggered (and prevent these inconsistencies).
Task id: 3007499
closesodoo/odoo#106077
X-original-commit: 7240c5b19e9c06fe22a929ca3ec83115c29a5c7f
Related: odoo/enterprise#34153
Signed-off-by: Tiffany Chang <tic@odoo.com>
Previously, we had an option on char/text fields called "onchange_on_keydown",
which allowed to trigger the onchange while the user was typing (instead of
when the field is blurred).
It was notably used when typing a phone number in the sms composer, to warn
the user that the phone number is invalid.
This feature was lost during the port to OWL, this commit restores it.
Task-3033107
closesodoo/odoo#106193
X-original-commit: 54def8969d49d6e5284cd97ab8df75e08043cd4e
Related: odoo/enterprise#34211
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The `comment` field was not properly displayed since the move to grid display.
closesodoo/odoo#106197
X-original-commit: bf98d880087ccc562712d82fa690f76d58dedfef
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Update to current runbot state, in order to better spot changes potentially
introduced with this PR.
Task-2710804 (Mail: Clean MailThread Posting API)
closesodoo/odoo#106182
Related: odoo/enterprise#34197
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since [1], the google map UI to search for locations thanks to the
google map API was not working anymore. Indeed, the lib was loaded
inside the iframe (as it should) but not outside of it, preventing to
use the `google` object in the related editor panel widget. The
autocomplete UI style was also broken as the CSS is not available
outside the iframe.
As a fix, the code outside the iframe now use the `google` object from
inside the iframe (no problem seems to come out of it) and the style is
restored via custom CSS (custom CSS already existed and was already
changing most default style anyway).
As a reminder, this snippet is only available in debug mode or if your
google map key is setup, which we do not allow to enter anymore via
standard flow since 16.0 (15.3).
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3bclosesodoo/odoo#106103
X-original-commit: 7d60d0ae4ea195edc4a12e57bf1c3b7c661bcf82
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Using the "gps picker" (for example with the "Google Map" snippet) was
not flawless. The autocomplete menu which shows up when the user enters
an address is handled by the gmap API. It was actually not working at
all on Firefox for an unknown reason. Not listening to blur events on
the input seems to solve the issue. This commit also prevents triggering
a value change if the same address is reselected which seems to make
address changes a bit more robust too.
opw-2976261
X-original-commit: 50bf0b7f1677b8125d892fad968ccc8174c974c1
Part-of: odoo/odoo#106103
Some part of the google map API was deprecated and showed a warning
at each snippet redraw. Probably harmless but since the related API are
really capricious, best satisfy them as much as possible, even in
stable versions.
opw-2976261
X-original-commit: b761c8fe0762f449bd6d9a1763c152833819247c
Part-of: odoo/odoo#106103
Before this commit, when adding a google map snippet in the DOM, the
user was asked for its API key if not already configured, thanks to an
user-friendly dialog. However, in the case it was misconfigured (while
the editor dialog prevents some misconfiguration, configuration via the
backend allow any random key to be given), the UX was terrible: the
google map is simply removed without any notification.
Misconfiguration can be:
- Invalid API key
- "Maps JavaScript API", "Places API" or "Maps Static API" not enabled
- Billing not enabled
Now notifications/messages warn about those things and reopens the key
configuration dialog, which contains links to the gmap API documentation
and now more information.
Hopefully, this can be improved even further later. Indeed, this is
still not perfect as there is no reliable way to understand google
responses. E.g. even with the three mentioned API and billing enabled,
sometimes the google map API still returns errors indicating "not
enabled APIs" but it cannot be reproduced reliably. During my test it
was systematic for 15min at some point but now there is none, ever. Like
if there was a delay after enabling an API on the google console before
it stops sending errors... although the API works immediately.
Notice that in 15.0, this snippet is shown in debug mode only and we
encourage users to use the new "Map" snippet which does not require any
configuration.
opw-2976261
X-original-commit: d9f86840e27463ccf370a748cafc7c4be32f901f
Part-of: odoo/odoo#106103
The existing code was generating misleading errors for imported Odoo
modules that could not be loaded. Although there was a specific hack
for module 'studio_customization', imported modules were not handled
properly. This patch adds the right condition in the SQL query in the
module that introduces imported modules.
closesodoo/odoo#106098
X-original-commit: e1cfc1f74000e55473f7a26f0df5a13c4d5094c0
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Ivan Yelizariev