With this commit we support adding FieldDependencies on custom widget, consider
FieldDependencies given on custom widget and add it to fieldInfo so that when
modal does calls to server to fetch data it consider those fields while reading
this will let us to design custom widget which may have some other fields in
dependency, say for example weekly recurrence widget which uses sun, mon etc.
fields, so with this we can fetch data of those dependent fields without adding
it to view.
task-2335399
closesodoo/odoo#60277
Related: odoo/upgrade#2021
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
with this commit we adding weekly recurrent widget, currently proeject and
calendar shows boolean for each day vertically but with this widget we displays
week days and its boolean horizontally.
Here widget will display first day as per language's week_start field, also we
adds FieldDependencies on custom widget and consider those FieldDependencies
while processing view node in basic_view.js
We add support of registry to contain owl custom widgets and add support
of rendering owl custom widgets.
Also with this commit we removes fields like sun, mon, tue etc. from view and
instead use "web_weekly_recurrence" custom widget to display boolean for each
week day.
Co-authored-by: Mohammed Shekha <msh@odoo.com>
add support of <widget> tag for owl, In order to prepare the future,
we want to convert everything in Owl, in future widgets generated by
<widget> tag will also be converted to owl.
with this commit we support widget to instantiate using ComponentWrapper.
task-2337692
Co-authored-by: Aaron Bohy <aab@odoo.com>
The confirmUpdate method in list_editable_renderer would destroy all
rows' widgets and recreate them *except* the currently modified one
(this one gets updated).
The problem was that the widgets of the current row were recreated
anyway. It created a memory leak.
This memory leak isn't such a big deal, as anything is garbage
collected as soon as the view is left anyway (so it's a small leak
during the lifetime of the x2many list)
The fix consists in keeping the reference of the widgets on the
currently modified row, and when all rows' widgets are recreated, we
delete a replace by our reference for the current row.
closesodoo/odoo#68386
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In a list editable used as a one2many representation, inside the
confirmUpdate method, the on_attach_callback method on the field widgets
wasn't called.
It wasn't detected earlier because most of the legacy widgets didn't
implement this callback (all owl components do however).
It was problematic as the confirmUpdate function destroys and recreates
all the field widgets (with exception for the currently modified row).
Not calling the on_attach_callback would result in missing / unexpected
behavior such as _applyDecoration not being called.
The fix is simple: call the method if it exists on all the widgets after
they have been created.
Purpose of the commit is to display the default label next to the icon
for state_selection widget in list view.
also that widget support the hide_label option to hide the label in
state_selection widget of the list view.
Related Ent PR: odoo/enterprise#16559closesodoo/odoo#66589
Taskid: 2451287
Related: odoo/upgrade#2195
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Let's assume an x2many list with an onchange. When a sub-record is
modified, an onchange is performed, and it may update other records
in the relation (e.g. the debit/credit case in accounting). This
commit ensures that modifiers are correctly re-evaluated in that
situation, so that they are up-to-date with the new x2many values.
task-2373929
closesodoo/odoo#61911
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
One might design a custom field widget to display/interact with a
one2many field. Before this commit, if this field widget triggered
a field_changed event to update a related record, it crashed,
because the code assumed that there was a view associated with the
field.
Closes#68276
opw~2468238
closesodoo/odoo#68309
X-original-commit: 3826a2645b94e0f62c719814c4dbe4cc6502e1f2
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
This commit fix a bug introduced in #66551 where a mismatch has been done between
session.user_context.allowed_company_ids and session.user_companies.allowed_companies.
This commit also adds the following tests:
- a JS test in order to prevent future unwanted issues regarding multi company
in BasicModel.
- a Python test in order to ensure that session_info['user_companies'] is not
involuntarily changed.
closesodoo/odoo#68025
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Create a product with:
Cost: 60.80
Quantity On Hand: 999.0
- Go to Inventory / Reporting / Inventory Valuation
- Click on export all (little button next to "Inventory at date")
The field "Total value" have too many decimals: 60739.2000000004
This occur because of the multiplication: it yield the correct value
(60739.2), but every rounding attempt done, even in the ORM, will
mess up the representation
https://github.com/odoo/odoo/blob/042298f8c949fba470eda6ad90f94c95ca291030/odoo/fields.py#L1333
opw-2438384
closesodoo/odoo#67558
X-original-commit: 67cf82962688360cfe25c6b2118a7dbd17a6ee95
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Issue
- Install "Accounting"
- Change user language to arabic
- Go to Customer Invoices list view
- Try to filter on field "Created On"
Traceback is raised from the DatePicker Component
Cause
The cause is two fold:
There is an issue in moment that behaves abnormally when its internals
are not able to extract the month in a locale, and, instead of returning an
invalid moment, it returns a valid moment with the month set to January
which just happens to be the first month of moment's default locale
ref: https://github.com/moment/moment/issues/5600
Secondly, the defaultProps "locale" of the DatePicker was set to moment.locale()
at the file's initial loading, that is, before any user locale parameters were loaded
The bootstrap datepicker was then set with the wrong locale, and the case fell under moment's issue
After this commit, the locale of the DatePicker is always the one of the user, and there is no traceback
opw-2460156
closesodoo/odoo#68059
X-original-commit: e2c46bb80e1e312dd34ac554d79813ef35282e62
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Before this commit, calling unpatch on an object that hasn't been
patched before crashed (before reaching the code that handles the
case by throwing an Error). This scenario is now properly handled.
This commit also defines specific Error classes for the patch and
unpatch faulty cases, so that they can be elegantly catched (in
tests for example).
closesodoo/odoo#68057
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
In tests, we might want to disable a specific patch for a specific
test (e.g. to remove a monkey patch done when another addon is
installed, to test the behavior of the current addon).
Before this commit, it was possible to unpatch at the beginning of
the test, but we couldn't re-patch when the test was over.
Feature required by task~2392303
Issue
- Install "Sales"
- Switch to "German" language
- Go to Sales -> Products -> Products
- Try to filter on "Public Price" is equal to "2,3"
Not possible to add decimal point at the end (only in middle of number).
Cause
In case the 'decimal point' in DB params is not a dot '.',
the filter input will be considered as 'text' instead of
'number'.
In case of the 'number' type; HTML do already a pre and post
processing, including managing decimal point (who, for example,
is not included in ev.target.value if last char is a '.').
Unfortunalty, the library is not well working with other
language and not supported on every browser, therefore,
must use own logic.
In case of a 'text' type, the value will be send to 'parseFloat'
,then `parseNumber` will replace decimal_point by dot (also one the
issues since needed to display decimal_point according user language),
and `Number` will remove the decimal_point in case of '123,' -> '123',
and therefore we will not be able to write decimals ( apart of adding
the decimal point after writing the whole number...)
Solution
If user input is well parsed, store parsed value in condition.value and
set condition.displayedValue to the input value (an so without updating
input value). Else, replace input value with previous value (who should
be the condition.DisplayedValue).
opw-2463441
closesodoo/odoo#67978
X-original-commit: e795ce5bff14b6b748c1f4a2651946aafdc299f4
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Before this commit, clicking on the "add a line" button on a
many2many list field directly opened the dialog without
switching the form into edit mode.
This is incorrect, the form needs to switch into edit mode otherwise
the selected records are saved and cannot be discarded.
closesodoo/odoo#67919
X-original-commit: 3608e724c6099f0eff5f14cbd844e0d7507d0d1d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since the quick edit behaviour has added, embedded lists
can be edited and display the "add a line" buttons in a
readonly form but not display the remove buttons
This commit fixes that inconsistency.
X-original-commit: 7cc17a345bc9cbe165d061300d91d1ac0e583fc1
Without this commit, all tests executed after that one would use
the patched version of the FormViewDialog.
Issue spotted in the assets revamp branch, by moving form_tests.js
after calendar_tests.js
closesodoo/odoo#67887
X-original-commit: ff19ee8d8b39a719a09dd9f6060faa3afa474da3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Let's assume the following situation. We have a form view with a
one2many field A displayed as a list. In the list, there is a
one2many field B. B can't be edited, its value is computed by
an onchange. By default, it contains a single record (i.e. the
first value returned by the onchange is [[5], [0, 0, {...}]]).
When another field (say C) changes, B's value is re-computed to
[[5]]. Moreover, there is an onchange on A.
In this form view, let's assume the following scenario. Create a
new record and add a line to A. In this new line, B already
contains a record. Change C. This triggers an onchange that
returns [[5]], and B is now empty. It triggers a second onchange,
on the main record (as field A changed).
Before this commit, in this second onchange, B's value wasn't sent
among the other values of the new line.
The spec says that for onchanges, we must send all data, not only
what has really changed. From that perspective, the above scenario
highlights an issue.
That issue had two root causes. First, commit [1] wrongly fixed
another issue, and as a consequence, when building what to send
for the onchange, we didn't generate the values for fields that
hadn't changed inside an x2many (for added subrecords at least).
This commit reverts the fix of [1], and fixes it differently by
only sending a command 1 (update) after a command 4 (link to)
when the record is dirty (i.e. when it has been modified). See
[1] for context and details.
Second, the code that generates the values to send to onchanges is
the same as the one that generates the values to save records
(write or create). However, when saving, we only send what has
really changed. The values are at some point processed to remove
empty command lists from the list of changes (as it means that
nothing changed). However, here we ignored the flag that stated
whether we want all field values or just what has changed. This
commit takes the flag into account before removing the field's
value.
[1] https://github.com/odoo/odoo/commit/3e3a244e1afc4d74920a6302a14fa2590e8b6648
Issue reported in task~2352524
Model: account.move
One2Many (A): account.move.lines
Nested computed One2Many (B): tax_detail_ids
Field triggering the onchange (C): tax_ids
closesodoo/odoo#67739
X-original-commit: a3732031d38d7c7e93565cdd3cd4fdf838ae54ec
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Commit [1] altered the way the FieldMany2Many behaves with respect
to 'create' and 'delete' options. Indeed, for many2many fields,
adding or removing records doesn't mean "creating" or "deleting"
records, as it is only about adding/removing records to/from a
relation. This is completely fine and correct.
Unfortunately, a feature has been lost in the process: it is no
longer possible to state that a many2many field should be editable
but should not allow to add (or remove) record to the relation.
This commit fixes the issue by adding two new options: 'link' and
'unlink' for that purpose.
[1] https://github.com/odoo/odoo/commit/c98579d25af01c14df4baf57fb4652f3e7469096
opw~2466213
closesodoo/odoo#67495
X-original-commit: df44e65bbbba55a7ee2224ad5b4f13248a39423a
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The Many2ManyCheckboxes widget displays all values that could be
in the many2many relation, with a checkbox indicating whether each
value is in the relation or not. It is designed to be set on fields
where the comodel contains a few records (typically, we don't want
to see dozens of checkboxes in the form view). This widget shouldn't
be used on many2manys with a large comodel, as we have better tools
to handle them (like a tree view).
We deal with extreme cases (when the widget is, by mistake, set on
a field where the comodel is huge) by using the name_search limit
of 100: at most 100 checkboxes are displayed.
Before this commit, this extreme situation wasn't correctly handled.
If there were in the relation records that weren't displayed
(because they weren't inside the 100 limit), then, editing the value
by (un)selecting a checkbox would automatically remove all non
displayed values from the relation.
This commit ensures that we keep in the relation all values that
aren't displayed.
Issue spotted when working on opw~2439041
closesodoo/odoo#67400
X-original-commit: 9e9d3aa78c42ad4ffca3b56a28382ed84078cde3
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if the widget "many2many_checkboxes" was set on
a field with more than 40 values in the comodel (i.e. more than 40
checkboxes displayed), (un)selecting a checkbox that wasn't in the
first 40 checkboxes crashed. This was due to the default x2many
limit of 40: we only created a datapoint for the first 40 values,
whereas we could have up to 100 values to process (name_search
server-side limit). Note that this limit of 40 had no other impact
than limitating the number of records processed by the BasicModel,
the maximum number of checkboxes displayed being ruled by the
name_search server-side limit.
This commit ensures that all values returned by the server (at most
100 when this message is written) are processed and can be edited
as expected.
opw~2439041
X-original-commit: d037d12753179d890459b23319b0d769fce62771
A previous commit (8dbd1efef899fb637acca3c318ae99cb23838b8f) fixed a
part of the basicmodel that used _.each to iterate on an object with
field names as keys, which does not work when a field is named "length".
To fix it, I simply used a native for ... in statement. However, I
missed the fact that there was a second 'return' statement in the body
of the closure given to _.each, so the onchange method returned
prematurely.
The fix is to simply use the continue statement in that case.
closesodoo/odoo#67267
X-original-commit: d9834e65ee57511f4850fa2d74287eb0b67087b9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
# Purpose
This PR's primary objective is to ensure that the timesheet uom is working in accordance with the company settings in a multi company environment.
Prior to this PR:
- The timesheet preferences sent to the front end were always those of the default
company of the user.
- The timesheet related widgets initialisation process (adding the correct ones in
the fieldRegistry) was performed before the front end treatment of cids and coockies
which prevented applying the front end selected company settings.
After this PR:
- A dictionnary is used in the session in order to structure the companies info.
- The company timesheet preferences are sent to the front end through the company dict.
- The uom info is sent to the front end through the session.
- The timesheet uom is now managed from the frontend and is now in sync with the settings.
- Timesheet widgets are initialised during the AbstractWebClient init and are in sync with
the multicompany front end settings
task-2168337
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#66551
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit's primary objective is to ensure that the timesheet uom is working in accordance
with the company settings in a multi company environment.
Prior to this commit:
- The timesheet preferences sent to the front end were always those of the default
company of the user.
- The timesheet related widgets initialisation process (adding the correct ones in
the fieldRegistry) was performed before the front end treatment of cids and coockies
which prevented applying the front end selected company settings.
After this commit:
- A dictionnary is used in the session in order to structure the companies info.
- The company timesheet preferences are sent to the front end through the company dict.
- The uom info is sent to the front end through the session.
- The timesheet uom is now managed from the frontend and is now in sync with the settings.
- Timesheet widgets are initialised during the AbstractWebClient init and are in sync with
the multicompany front end settings
task-2168337
Closes: #66551
Before this commit:
- Some semicolon where missing
- There was a typo in the variable name
After this commit:
- The above problems are solved
task-2168337
Closes: #66551
The underscore (_) library has a bug in which the _.each method does not
work with object which contains a "length" property. This is because it
does look for that key and if it is a number, it will assume that it is
an array with that length value. Nicely done...
If that length value is set to 0, then it will just do nothing, since it
thinks that it is dealing with an empty array.
Note that if the value is set to an object, _.each is smart enough to
notice that it cannot be an array, and will do the correct thing in this
case.
Usually, our _.each calls are safe, since we usually iterate on arrays,
or on object with safe keys, or on object with values that cannot be a
number.
But there was 2 unsafe calls in basic_model, which leads to strange
bugs: some code is skipped, and the form view is then confused. The
motivation for this fix is the fact that onchanges are not applied at
all, if there is a length field set to 0.
To fix this, we can just avoid using _.each. Note to every Odoo JS
developers reading this: new Odoo code should avoid using the _ and $
libraries, because we do not really need them, and we want to keep our
dependencies to the strict mininum.
OPW: #2465808closesodoo/odoo#66126closesodoo/odoo#67172
X-original-commit: 8dbd1efef899fb637acca3c318ae99cb23838b8f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
* This feature will be useful when the user needs to "reschedule" an event.
It is more convenient to open the CalendarView around the original start date of the
event instead of "Today"
* Add a test to ensure that the context key is correctly passed to the view as the initialDate
Task ID : 2410217
PR : https://github.com/odoo/odoo/pull/63370
The color_picker widget, that can be seen for example in the track form
view for event tracks, had an issue: if the user clicked on it, then
pressed TAB, a traceback was displayed.
The problem comes from the fact that the color picker widget inherits
from FieldInput, but is not a fieldinput, so many expectations made by
the FieldInput code do not hold, such as the code run when handling
navigation (by TAB and such keypress). Because of that, the code in
_onNavigationMove crashed, because it expected an input.
Since this is a bug fix, I simply disabled the navigation in that case,
so no crash happens. Sadly, this widget has still a big issue: it
clearly does not work as most users would expect: pressing TAB or arrows
should update the selection. But this would be a more complicated
refactoring, for a bug which is clearly not critical, therefore this
commit implements the simple and safe solution.
Also, we disable the focus outline to minimize the wrong expectation.
Seeing them kind of implied that one could update the selection with the
keyboard.
Note that the widget color_picker was moved from another addon to web/, without
any tests nor documentation.
OPW 2467369
closesodoo/odoo#67195
X-original-commit: 580456b6ab36d16195eae9ffd776ff245ecd936e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
* hr, hr_holidays, im_livechat, mail, snailmail, website,
website_livechat
This commit removes `patchMixin` and improve `utils.patch`.
`utils.patch` now supports native classes and has a new parameter
used to patch class members.
`utils.patch` is now used everywhere `patchMixin` was and it must
be used to patch classes.
closesodoo/odoo#65967
Related: odoo/enterprise#16278
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: ged-odoo <ged@odoo.com>
Since commit odoo/odoo@c96e3b96f3
the TouchEvent constructor was added to the test utils.
In FireFox (no touch mode) and Safari (desktop) this constructor
doesn't exist and so the test suite won't start anymore.
This commit, inserts TouchEvent constructor only when it's supported by
the browser. So now we can run the tests in FireFox and Safari again.
closesodoo/odoo#66846
X-original-commit: 296fd86ddf90cff8d5b8f095d0c51b1c5a8b59ca
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: rfr-odoo <rfr-odoo@users.noreply.github.com>
Warning: this commit savagely patches qunitjs sourcecode. I know... I
feel bad.
Since we updated the way debug=assets work, we have a new problem in the
qunit test suite: the tracebacks displayed by QUnit are relative to the
bundle file, not the original file, which is annoying in practice.
There is really no good way that I could find to integrate with QUnit to
perform that task, so I had to do it the ugly way: modify QUnit from the
inside to use the StackTrace library to annotate the traceback with the
proper information.
closesodoo/odoo#66771
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit improves the calendar behavior.
* Before this commit, the invisible attribute were not evaluated in the calendar popover.
* Several alignment, label, improvements
taskid: 2342252
Let's assume the following scenario:
- have an action in target new (e.g. a form view)
- in the dialog, have an action/object button with confirm
attribute
- when clicking on that button, a confirm dialog opens
- if validated, the following action returned by the server
is again an action in target new
Before this commit, the confirm dialog remained in the DOM.
This issue occurred because it's parent wasn't correctly set (wrong
use of `this`), so when the first dialog was destroyed, the confirm
dialog wasn't automatically destroyed in turn.
OPW~2440712
closesodoo/odoo#66597
X-original-commit: 98f9cb4f692a15494cd8ef298673fe1c949c423c
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
before this commit: when there is only one page in the notebook tag and
there is a boolean field in form to show/hide that notebook page based on
invisibility attrs, if we toggle boolean field notebook hides, that's OK
but when we toggle boolean field again then notebook page is displayed but
it is not active and due to that content of notebook page is not displayed.
after this commit: when there is only one page in notebook and it has attrs
for invisibilty, when we toggle boolean field to hide/show notebook page
then notebook page as well as content is toggled.
task-2449053
closesodoo/odoo#66582
X-original-commit: a0b5ecd344d6ac79d8e4d194cfabf3d639259c73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since commit 2716828f25, the error dialog
has an additional JS lib dependency, which means that it may needs to
perform a request before it opens up. However, a test in the
crashmanager was only waiting for a next tick, which is possibly too
short for a network request.
So, depending on the network speed (and on the test order), this test
could fail. To fix it, we simply make sure that the test also wait for
the library to be loaded
closesodoo/odoo#66546
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, in sample mode, cover images might be displayed
in kanban views. It isn't what we want as those images are real
images from the database, not sample ones, but randomly linked to
the sample records (the id of many2one fields is randomly generated).
This commit tweaks the SampleServer to always set many2one fields
pointing to model 'ir.attachment' to false.
task-2368505
closesodoo/odoo#66381
X-original-commit: f7b2a5825e3786be53d04276af4c4c403b7a293e
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The support for "active_test" context key has been introduced in c2918c1
However, the context key is ignored in many mocked ORM methods (if not all).
This commit adds support for the `search` and `search_read` methods.
Note: this is done to easily write some tests in odoo/enterprise#16363
and it might be usefull to test futures features (or fixes) using this
context key.
closesodoo/odoo#66393
X-original-commit: 0ad1c1631eb233b3e8f98b40f8c0813d0ad7acbe
Related: odoo/enterprise#16447
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Before this commit, the 'mounted' method of the ControlPanel in
the client report action was called twice.
It happened because the client report action updated the ControlPanel
before being actually mounted, so mounted was called once when the
traceability report was mounted, and once when the update was applied.
Ideally, this should not be an issue (this isn't an issue with owl).
However, in Odoo, we mix layers of Owl Components and legacy
widgets. In these situations, the above scenario isn't properly
handled (and can't be).
As a consequence, in mobile (enterprise), it crashed because an
handler bound in mounted (thus twice) was only unbound once.
This commit avoids the issue as the update was actually useless.
Steps to reproduces (Mobile):
* Go to Inventory (Stock)
* Open the "burger menu"
* Select "Products" -> "Products"
* Select one product in the list
* Click on the "Forecasted" ("stat button")
* Select one "SO line" (sale order) to go to the form view
* Go back to the previous view using breadcrumb
* Optional: Go to another app if the screen can't scroll (e.g. go to Sales)
* Scroll the view => Bug
closesodoo/odoo#66497
X-original-commit: d3854dbf7a6e0c0f9ac00c11716908bc175808d7
Related: odoo/enterprise#16507
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The recent change in the way debug=assets works (which now bundles all
files in a bundle instead of serving them statically) had a negative
impact on the stacktrace displayed in the error dialog in debug=assets:
it now display the bundle/linenumber instead of the actual file/line
number.
This is not a huge deal, most of the time, because the errors displayed
in the console display the correct information, and the debugging
process should work as before. But it can certainly be annoying in some
cases.
With this commit, we use the Stacktrace.js library to dynamically fetch
the sourcemaps and to decorate the displayed information with the
correct file and line numbers.
closesodoo/odoo#66318
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Let's assume a <groupby> node in a list view containing a button
with an invisible modifier referencing a many2one field, e.g.
```
<tree>
<groupby>
<field name="m2o" invisible="1"/>
<button string="do it" attrs="{'invisible': [('m2o', '=',
False)]}"/>
</groupby>
</tree>
```
Before this commit, the m2o field was correctly read, but it's
value wasn't processed by the model, so the modifier wasn't
correctly evaluated.
Issue reported on PR https://github.com/odoo/odoo/pull/65316/closesodoo/odoo#66330
X-original-commit: fa7a185663f21c1c4060765c8c137b296df3a350
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Have grouped list with reference a m2o or a reference field
Select some records, edit them
Before this commit: the names of the reference fields and m2o disappeared
That was because the saveRecords function did not take into account a grouped list
manual forward port of #65999
After this commit: it works as expected
closesodoo/odoo#66043closesodoo/odoo#66175
X-original-commit: 8b6e86927941dce2018ea93f191b59856ea67e4b
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Have a list with multi_edit enabled
Have a widget boolean_toggle displayed on some field
Select some records to be in multi edit mode
Before this commit, the record on which the boolean toggle button was clicked was written
and then the multi edit feature was triggered and wrote on all the records
The first write is unnecessary and counter intuitive
After this commit, only the write with all the multi edited records is done
X-original-commit: 23fcaeda6830f2dc0de17337f9c3da8faf0338ce
The previous work on adding support for native JS modules needs to adapt
some existing files, which have an incompatible name (with a '/').
Also, we convert a few JS file in /web to the native JS module system,
to show that it can work.
Part of PR 63177
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Before this commit, select the "No" option of a boolean field in the
search bar autocompletion menu would crash.
closesodoo/odoo#66058
X-original-commit: ad5d642c455d3215857f25e0d69c593324178d29
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, clicking on the copy button on a
CopyClipboard field triggered the quick edit.
Now, clicking on the copy button won't trigger the quick edit
but clicking on the field's value will.
task 2455358
closesodoo/odoo#66035
X-original-commit: 050efe415ba7821305390be125ab3a9b059f3273
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the form renderer would call "on_attach_callback"
only when the whole _render process was over. The problem was that this
process is asynchronous and this callback should be invoked as soon as
the widgets are appended.
As such, any asynchronous operation is performed before appending the
content in a new function "__renderView".
Task 2346540
closesodoo/odoo#65991
X-original-commit: 953fb092636b9919aaa6c6a6cfaffd003ba951d5
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
