Steps to reproduce the bug:
- Create a storable product “P1”:
- route: MTO + manufacture
- uom: unit
- BOM:
- qty: 1 dozen
- component: 12 units of “C1”
- Create a SO:
- Product: 12 unit of “p1”
- uom: unit
- Confirm the SO
Problem:
The UOM set on the product is used instead of the BOM UoM on the created
manufacturing order.
wrong MO:
- 12 unit of "P1"
expcted MO:
- 1 dozen of "P1"
opw-3048190
closesodoo/odoo#106351
X-original-commit: 8c5fb8b71538462422c8f166b772b5e316ecd6b5
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Traceback when starting odoo server
ImportError: cannot import name 'errors' from 'psycopg2'
Exception management update in commit
4b430f8e30efb15f06982e4673cd73531a2119b3
would require psycopg2 version 2.8 minimum but version in
requirements is 2.7.7
closesodoo/odoo#106369
X-original-commit: b21fdf115e855d2383603e67343012bfe346cfd9
Signed-off-by: William André (wan) <wan@odoo.com>
We should always use `invoice_date` instead of the `date` of the move for currency exchange.
Re-adding some of the changes from odoo/odoo#87984
task-2807136
closesodoo/odoo#106367
X-original-commit: 76a640d05a350840bdde1c88bd052251aabd6b12
Signed-off-by: William André (wan) <wan@odoo.com>
Steps :
Go to project > settings.
Check 'timesheet' config and save.
Uncheck it back and save.
Issue :
See errors in the logs, due to on delete restrict.
Cause :
Record 'hr_timesheet.internal_project_default_stage' from data
is deleted when hr_timesheet is uninstalled.
Yet some project task records still use it, so we can't delete it.
Fix :
Delete the corresponding ir.model.data to keep the stage,
but unlink it from the 'hr_timesheet.internal_project_default_stage' ref.
task-2998416
closesodoo/odoo#106354
X-original-commit: c9e49358111521c042dd793f80ff99895d0fd179
Related: odoo/enterprise#34317
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
MockServer behaviour on fetching channel preview was different from
server. Thankfully no test rely on this slight behabiour, but it's
important to ensure same behaviour for future tests.
closesodoo/odoo#106357
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
To Reproduce
============
- start a session on pos
- on customer button create new one with a long name
- go back to pos dashboard, the name of the chosen customer goes outside of the button
Solution
========
a style was added to the button so that the long string is divided on multiple lines
opw-3074503
closesodoo/odoo#106352
X-original-commit: 4bf9627fc49439012198d9194859429bc0db89fa
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
On the ticket https://github.com/odoo/odoo/pull/101547 a constraint was added to prevent the user from changing the product type if some moves have already been made.
This was done because changing the type creates inconsistencies (like breaking the valuation).
However, it currently only checks if there are moves on the current company, when it should check in all companies.
This can be fixed by adding sudo.
closesodoo/odoo#106346
X-original-commit: e8bb4a50aa0d3829d590858784e2c573118bc392
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In hr_holidays, when the time off type has the following settings:
- Requires allocation: Yes
- Employee Requests: Not allowed
An allocation created with this time off type still requires to be validated.
This commit removes the need to validate an allocation created with the time off type described above.
task-3004313
closesodoo/odoo#106337
X-original-commit: c98e1280aee2f31e6dbf3f52dac47cf020c628d2
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Change the way the uniqueness of the sequence numbers is ensured.
Instead of using a `SELECT FOR UPDATE` approach inspired from the
`ir.sequence`, or even a true UPDATE, we can use a constraint approach.
SELECT FOR UPDATE
=================
By doing a FOR UPDATE NO WAIT, we are throwing an exception when another
transaction is creating a move using the same sequence as this one, by
locking the row that holds the current greatest sequence.
Since the row doesn't change, the lock is released and the following
UPDATE is allowed. Because of this, a "useless" UPDATE was always done
on the previous row to ensure a SerializationFailureError if two
concurrent transactions were trying to assign the same number.
This means that in a database with a lot of concurrent transactions
(typically with an online shop), many transactions were
aborted/rollbacked.
This approach also has the drawback of having the constraint implemented
python side, which is less robust.
UNIQUE CONSTRAINT
=================
Using a constraint on the database level means that the database knows
when some transactions will try to do something similar. It will
therefore make the concurrent transactions wait instead of aborting the
transaction.
It is however harder to have the constraint customized by different
modules/localization because it is now done directly in the database and
not in python. Changing the constraint means deleting/recreating the
index. For now, this only happens for Latin America l10n, so a simple
hardcoded approach is implemented.
In order to achieve this, the business code is trying to use the
sequence incrementally until it gets a number it can use for when
multiple transactions are concurrent.
closesodoo/odoo#106325
X-original-commit: 4b430f8e30efb15f06982e4673cd73531a2119b3
Related: odoo/enterprise#34297
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
2 fixes are made:
* We use a FOR NO KEY UPDATE instead of FOR UPDATE because we don't want
to prevent the insertion of lines referencing the partner as a foreign
key (i.e. new invoices).
The data is purely informative and the exact value isn't too important
anyways.
* We catch SerializationFailure on top of the previously catched
LockNotAvailable. It can happen in this use case
- T1 and T2 start
- T1 acquires the lock and updates
- T1 commits
- T2 acquires the lock: it gets it because T1 released it
- T2 updates: T1 did it as well so there is a serialization failure.
X-original-commit: b1491b7663e4c6c675e88a172e4b0a812e9b00a3
Part-of: odoo/odoo#106325
Sometimes a constraint is too complex to be expressed in the general
`_sql_contraint`.
This allows to hook on a constraint if it matches the name in order to
display a user friendly error message.
X-original-commit: e1f06479a526c703ccabc441b1e194646206b966
Part-of: odoo/odoo#106325
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
Touati Djamel (otd)