Before this commit, autoresize input in Safari 16 had their
size underestimated, thus truncating the content.
For example, in the Discuss app, the header is a (disabled)
autoresize input, which becomes enabled when the thread can be
renamed. This is also used for threads that cannot be renamed
for consistency of style. So some screens like "Inbox" had its
name truncated to "In...".
This problem is only present in Safari, not in Chrome or Firefox.
Apparently the sizing of input and textarea is incorrect, and it is
fixed in Safari 17. Indeed, Safari 17 can be tested with Safari
Technology Preview where the bug is not present.
This commit fixes the issue by adding an offset to computing the
scroll width of autoresize input, so that it matches the Safari 17
behaviour that is correct.
closesodoo/odoo#129698
X-original-commit: cd9d900c93d22fec1c24dc3b1e77230f80191f04
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Instead of sho-horning full buttons inside a list view cell, use inline
buttons instead.
closesodoo/odoo#129679
X-original-commit: 76a4995b5037957bb5d7b1b2e04c44267273f7fc
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
In commit c0b354e14a18667463451aa6fe768bffcbb9da9a the intention was for
the calendar navigation to look like the gantt one. The arrows have been
replaced by the same `oi` icons as the gantt view's navigation.
task-3410165
part of task-3326263
closesodoo/odoo#129568
X-original-commit: c9384d12b903850f9535ca7b82ea2ef0e04fd39b
Related: odoo/enterprise#44556
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
*: calendar, google_calendar, microsoft_calendar;
task-3410165
part of task-3326263
X-original-commit: b680a6ac5769bf8e02921a9548792c7696992955
Part-of: odoo/odoo#129568
Prior this commit, there was a problem with borders that were not
displayed on the kanban header when the stage was folded and the user
was trying to drag and drop in that stage.
This commit removes the background set on `.o_kanban_header` when the
stage is folded, so it doesn't overlap and hide the border set on
`.o_kanban_group`. We can do that safely because a folded stage
can't be scrolled
task-3423682
part of task-3326263
closesodoo/odoo#129560
X-original-commit: b6cb9fed6aa46591e692e67267a7419fe15f8c68
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Prior to this commit, the `font-size` of the days and week numbers in
the Month view were very large.
There were also a couple of issues with the background circles
highlighting days on hover or "today". In both Month and Year view
they were oval instead of circular, and in the `ui-datepicker` they
would hide the number if they happened to be in the previous or next
month.
To fix the font issue the `font-size` styling on
`fc-day-number` and `fc-week-number` has been removed.
For the roundness of the circle, a `:before` element was needed, .
And for the `ui-datepicker`'s circle a simple `position-relative` on
both the `td` and the `a` or `span` fixed the issue.
task-3326564
part of task-3326263
closesodoo/odoo#129559
X-original-commit: 8fac3dd7dd6ffc69f989c9ec5cea225f3e919535
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, in a kanban view grouped on a x2m, when we created
a new column, we had a crash.
Why did this happen?
When a column is created, a resequence is triggered on the columns in
order to have the correct position. Currently, we always use the
DynamicGroupList handle field, which is not correct because if we are
grouped on an x2m we use another resModel, so we want to use the default
handle field (sequence).
closesodoo/odoo#129510
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, discard management was incorrect when you had a
non-editable x2m. This could result in changes not being completely undone.
How to reproduce:
- Go to a form view with an uneditable x2m
- Click on a record in the x2m
- Edit the record in the form view dialog
- Click on save
- Reopen the same record
- Click on discard
- Click on the discard in the main form view
- Reopen the same record
Before this commit:
The change applied is still present
After this commit:
The applied change is no longer there. The original state has been restored.
closesodoo/odoo#129509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes a lot of legacy code that we kept for the few
legacy client actions that were still to be converted to owl. Now
that the last one has been converted, we can finally get rid of a
lot of legacy code (ActionAdapter, ActionMixin, ControlPanel,
ActionMenus, DropdownMenu(Item), Pager, DomainSelector...).
Part of task~3439226
closesodoo/odoo#129314
Related: odoo/enterprise#44465
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit, the usermenu My Odoo.com account
was opening in the same tab
after this commit My Odoo.com account usermenu is
opening in a new tab
closesodoo/odoo#123627
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
This commit adds a shortcut in the orm service to call the new
"web_read" python method and adapts the few calls to use it.
closesodoo/odoo#129502
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
With this commit, it is possible to load the web client in a language
different than the user by using the `lang=` query string in the url:
For example, `/web?lang=en_US`
This is useful when we need to quickly check something, without changing
the current user settings. Note that it will only work if the url lang
has been installed on the database (if lang does not exist, it will fall
back to en_us).
closes odoo/odoo#128121
Taskid: #3420252
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
Before this commit:
When attempting to open a dynamic placeholder in email marketing, a traceback
occurs.
After this commit:
Now the dynamic placeholder works properly.
Task-3373356
closesodoo/odoo#129415
X-original-commit: bb9fb402a135baf7e7b9da9bbb40888f5323ded9
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Prior to this commit,
```xml
<t t-elif="days gt 1">In <t t-esc="days" /> days</t>
```
resulted in two separate translations: “In” and “days”.
This commit fixes the problem by explicitly putting the full text in a
gettext.
closesodoo/odoo#129388
X-original-commit: d278fc234540120e86733c2131515a5223d92c87
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The title of the “Developer Tools” section of the settings is not
translatable. This is because the extractor ignores nodes that are OWL
components. This commit solves the problem by moving the text to be
translated elsewhere.
closesodoo/odoo#129386
X-original-commit: e91370aed41847f9c89bb6ab590f929e6935ac12
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Set Document Layout to "Light" (the default)
Print an Invoice
Open in chrome (tested in Chromium Version 114.0.5735.198)
Issue: border right after table header is still visible
Note: It is reader dependent, as it may not occur with other browser or pdf
reader
opw-3324785
closesodoo/odoo#129275
X-original-commit: 28eedfeec2531c0ebfbdeb4024abad967d450a0d
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>
_askChanges doesn't apply on a single record, it asks all fields
of all records of the current model to send their changes, so it
makes more sense to have this function on the model instead.
Part of task~3179751
Part-of: odoo/odoo#114024
With this commit, we ensure that the resId of a Record datapoint
never changes. The only exception is for new records: their resId
can go from `false` to their actual id when they are created. When
we want to load another record, we must use the `load` function of
the model, which now accepts `resId` (and `resIds`) as param, when
the root is a "mono record".
As a consequence, the instance of record datapoint now changes when
using the pager. This required some changes in the AceField, to
make it properly react in that case. We took the opportunity to
simplify its implementation (several keys in the state were useless).
Part of task~3179751
Part-of: odoo/odoo#114024
Now that the RelationalModel is based on unity, datapoints expect
to receive their data as returned by unity read (i.e. x2many values
are list of records, not ids, and many2one values are objects with
keys id and display_name, not tuple, or simple ids). As a
consequence, the Record component needed to be slightly adapted for
current usecases to continue working (e.g. using a Record component
for a Many2ManyTags field, and providing the value of the many2many
as a list of ids, like in the studio action editor sidebar).
This commit completes the relational values received by the Record
component with the related records, like if they were read by
unity.
The Record component's API will be reworked soon, now that the
new RelationalModel has been merged, to be more compliant with the
new unity concept.
Part of~3179751
Part-of: odoo/odoo#114024
Have a many2many field with widget many2many_checkboxes. Before
this commit, the widget notified the model (i.e. called replaceWith
on the static list) for each change of one of its checkboxes. This
means that if the was an onchange on the field, the onchange rpc
was done once for each click. With this commit, we debounce the
call to replaceWith, which allows to tick/untick multiple
checkboxes, and a single onchange is done with the resulting value.
This allows to mitigate another issue, which is that consecutive
calls to replaceWith are error prone, because they might send a
list of ids which isn't up to date with the one of the last call
to replaceWith (if the list is computed from the value in the
datapoint), as replaceWith uses the model mutex and thus updates
the datapoint in an async way. This specific issue will be tackled
later.
Part of~3179751
Part-of: odoo/odoo#114024
This commit adds an option to _updateConfig which allows to specify
a callback to apply the new values obtained from the updated config
e.g.
1) a dynamic list updates its offset (calls _updateConfig)
2) a web_search_read is done and returns some records
3) the new config (with the new offset) is applied on this.config
4) record datapoints are created for the returned records and set
on this.records of the list
Before this commit, step 3) was done in _updateConfig, and step 4)
was done by the called of _updateConfig. As _updateConfig is async,
step 4) was actually done in the next microTick after 3). As a
consequence, those two mutations could trigger owl renderings.
To avoid this situation, _updateConfig now takes a "commit"
function, which allows it to execute 3) and 4) in the same tick.
Part of~3179751
Part-of: odoo/odoo#114024
Have a field x2many without relation_field.
Before this commit, a server error was raised because, we send changes
for the non-existing field (relation_field).
Now, we only send to the server the changes for relation_field only if
they exist.
Note that, this commit will also add an exception on the server mock
onchange if we sent changes for non-existings fields.
Part of task~3179751
Part-of: odoo/odoo#114024
Have a view with many2many_checkboxes field (e.g. product.template
form view with inventory installed, and some routes). Tick a
checkbox. Before this commit, a read was done, but the field spec
was empty (there was no field to read). So basically the read only
returned the id. This is obviously useless. This commit prevents
from doing read rpcs when the spec is empty.
Part of task~3179751
Part-of: odoo/odoo#114024
Have a form view with an x2many field A displayed as a non editable
list view. In A's form view, there's an x2many field B, which isn't
in the list. B is itself displayed in the dialog form view as a
list, which contains an x2many fields C displayed as many2many_tags.
A contains a record. For this record, B contains also a record,
which contains two tags for C.
Have an onchange on the main record which triggers an update command
for the record in A, such that the command also updates the record
in B, which deletes (or forgets), i.e. commands 2 or 3, a tag C.
Before this commit, if the user opened the x2many record of A after
the onchange, it didn't displayed the remaining tag in C. The
reason is that we received commands to remove the tag before we
actually fetched them (as we don't need them for the list of A).
The tags were then fetched when we opened the record in a dialog,
but we didn't correctly merge the values read from the server with
the commands we received earlier.
With this commit, we properly store the commands and apply them
after reading the values.
Part of task~3179751
Part-of: odoo/odoo#114024
Have an x2many list or kanban with several page, and an onchange
on the main record that returns forget or delete commands for
x2many records that aren't on the first page. Before this commit,
it crashed, because the code expected the records to be in
this.records (the record of the current page).
Part of task~3179751
Part-of: odoo/odoo#114024
With the image field widget, the image is reloaded each time the record
is updated (when `write_date` is updated). This is not always desirable
as some images are not supposed to change.
This commit adds an option to bypass the image reloading. This option
is called `no_reload` and is set to `false` by default.
Part-of: odoo/odoo#114024
- On an one2many;
- drag and drop two records;
- a resequence is called, with an onchange;
- click save;
Before this commit, if the network was a little too slow, the return of
the onchange wasn't taken it into account for the save.
Now, we await the onchange of the resequence before executing another
action.
Task 3179751
Part-of: odoo/odoo#114024
Before this commit, going into a view with a record that had no properties displayed a crash.
Why ?
If no properties exist, the value is false and was not handled.
Part-of: odoo/odoo#114024
Before this commit, there was a hook, named useModel, which eases
the use of a model in views. The main (and almost only) role of the
hook was to deal with sample data (determine whether or not they
can be enabled, fallback on the sample orm when necessary, leave
sample mode at reload...). This hook is used by all views except
form and activity as they do not implement sample data.
This commit renames that hook into "useModelWithSampleData" and
introduces a new hook "useModel", which is a lot simpler that the
other one, as it's only goal is to do the plumbing between the
component using the hook and the model (i.e. spawning required
services and loading the data on willStart and willUpdateProps).
This new hook is used in form and activity views.
Note that useModel doesn't trigger deep renderings, as it is only
used on the RelationalModel which is based on fine-grained
reactivity.
Part-of: odoo/odoo#114024
...when using the pager.
When a record is dirty and the user clicks on the pager to go to
the next/previous one, it is automatically saved. Before this
commit, the record was reloaded after the save, which is useless
as we're leaving it anyway. This commit ensures we only save, and
we do not reload.
Part-of: odoo/odoo#114024
Before this commit, the x2m present in a record's evalContext was
represented by the resIds defined in the config. It therefore did not
contain the current changes. It should therefore be represented by the
currentIds of non-virtual records.
How to reproduce:
- Create a new record with a m2m field having at least one default record
- Edit a field which triggers an onchange with a context depending on the
value of the m2m
Before this commit:
The domain and context used contain an empty list for the m2m.
After this commit:
The domain and context used contain a list with the default id for the m2m
Part-of: odoo/odoo#114024
In form views, the "display_name" field is automatically added to
the list of activeFields as we need its value to display in the
breadcrumbs. However, this isn't necessary when there's no control
panel, in particular in dialogs. Without this commit, the test
"test_addremove" of addon test_apikeys didn't pass.
Part of task~3179751
Part-of: odoo/odoo#114024
Be on an existing record containing an x2many field. Add a row
or click on an existing one to edit it. The changes sent for
onchange done for the subrecord contains a key with the changes
in the parent record. Before this commit, this object didn't
contain the id of the parent record. As a consequence, the
onchange (in py) couldn't correctly link the sub record with
its parent to compute field values. This commit ensures that we
always provide at least the id when the parent record exists.
Part of task~3179751
Part-of: odoo/odoo#114024
Before this commit, when a field of type one2many or many2many, was
added and afterward deleted, on the onchange or write call to the server
the field wasn't added as a change (because the add and delete command
cancel each other). This can cause issues because when adding the x2many
field, the onchange on the server can have side effects that we want to
remove when deleting the x2many.
Now, we follow the following rule : If a field has been modified, its
value must always be sent to the server for onchange and write.
This commit also avoid to call update on the parent record if the chil
record didn't have changes.
Task 3179751
Part-of: odoo/odoo#114024
Before this commit, the save button in the x2m form view dialog does
not wait for ongoing updates.
Why is this?
When you click on the "Save and Close" button of a form view dialog
in an x2m, you check the validity of the record to know whether you
should save or not. The askChanges function called does not wait for
ongoing updates.
Solution:
Just wait until the model mutex has finished processing all the current
functions. This ensures that the record has applied all its updates.
How to reproduce:
- Go to a form view with a non-editable x2m
- Add a line
- Edit a required field with a slow onchange
- Click "Save and close" before the onchange is complete
Before this commit:
The form dialog remains open and a notification appears telling us that
a required field is invalid.
After this commit:
The dialog is closed and the change has been applied.
Part-of: odoo/odoo#114024
Before this commit, it crashed if an x2many field inside another
x2many field had a context with a key referencing the parent
record:
```xml
<form>
<field name="foo"/>
<field name="outer_x2many">
<tree></tree>
<form>
<field name="inner_x2many" context="{'key': parent.foo}">
<tree></tree>
</field>
</form>
</field>
</form>
```
The crash occured because we tried to evaluate the context of the
static list representing inner_x2many before setting the parent
key on the eval context.
Part of task~3179751
Part-of: odoo/odoo#114024
Have a required many2manytags field and a slow network. The field
is initially empty. Add a tag to the relation and directly save.
An invalid field notification is displayed, because the field is
still considered empty. This commit ensures that we wait for the
operations done in the static list before saving.
Part of task~3179751
Part-of: odoo/odoo#114024
For char/text fields, the server can return false or "" (empty
string) depending if the field isn't set in db (NULL) or set to
the empty string. This makes no difference in the UI, but it
matters when evaluating modifiers.
Before this commit, the value of char/text fields was automatically
set to the empty string if it was falsy, as it doesn't impact the
UI, and it is cleaner type-wise. Unfortunately, we cannot do that
for the eval context, as we must be able to make the difference
between False and "" evaluating modifiers. A solution would have
been to stop fallbacking on the empty string when the value was
false, but we wanted to keep the clean API. So this commit fixes
the issue by keeping an internal structure in Record to track
the exact values we received from the server for those fields, and
use that structure to generate the eval context.
Part of task~3179751
Part-of: odoo/odoo#114024
Have an x2many field displayed with a kanban view containing sub
fields with widgets (widget="..."). Click on a record to edit it
in a form view dialog. Before this commit, the fields of the kanban
card displayed in the background were switched to "edit" when the
dialog was open. With this commit, we ensure they always remain
displayed in "readonly".
Part-of: odoo/odoo#114024
From a list or kanban view, open a form view with a statusbar
field (e.g. in crm.lead). Go back to the list. Open another record
for which the domain of the statusbar is different. Before this
commit, it crashed, because the component bound to the orm service
used by the specialData cache (i.e. the previous FormController)
is destroyed.
Part-of: odoo/odoo#114024
Have an x2many with an x2many editable list inside the form view
containing at least a row. Open a record, click discard. Open it
again, and click on a row of the x2many to switch it to edit mode.
Before this commit, the row could never be switched back to
readonly. This was the list renderer didn't correctly compute its
active element (it must wait for a micro tick for the mounted hook
of the dialog, its ancestor, to be called).
After fixing this issue, a second one arise: the row can now be
unselected, but it disappears if it is a new record. This is
because we lost the dirty flag when clicking on discard. This is
fixed by storing the dirty state alongside changes in the
savepoint.
Part-of: odoo/odoo#114024
Before this commit, x2m in list mode with several pages did not work
correctly when sorted. The order was lost when the page was changed and
any values not used for sorting were missing.
How to reproduce:
- Go to a form view with an x2m in list mode with at least 2 pages
- Sort on a column
- At least one record not present before sorting is displayed
Before this commit:
This record only contains the values used for sorting
After this commit:
This record contains all the values
- Click on next page
Before this commit:
The records displayed on the page are not ordered and contain only
the values used for sorting.
After this commit:
The records displayed are the correct ones for the sort and contain
all the values.
Part-of: odoo/odoo#114024
Before this commit, go to a form view with an x2m displayed in list mode.
If you sort the x2m on two differents fields, a crash is displayed.
How to reproduce:
- Go to a form view with an x2m in list mode with at least 2 columns sortable.
- Click on a column to order
- Click on a second column to order
Before this commit:
We have a crash
After this commit:
The list is ordered correctly
Part-of: odoo/odoo#114024
Before this commit, we had several implementations of a relational
model. The form view used the BasicRelationalModel, which was a
wrapper around the BasicModel. The list view used the
RelationalModel (a simpler version that didn't support complex
usecases of x2many fields). The kanban view used the KanbanModel,
an extension of RelationalModel.
This commit removes all these, and replaces them by a single model.
It is called RelationalModel, and as a similar structure as its
predecessor (with datapoints). It now handles tricky x2many usecases
of the form view though.
This commit also comes with several important changes:
1) The new model is based on unity reads [1]. This means that all
data required by the view is fetched at once, and datapoints are
created with their data (whereas before, they were responsible to
fetch their data). There's an exception for special data: they are
no longer handler by the model. A hook "useSpecialData" has been
created, and it allows fields (components) to fetch additional
data they require.
2) The new model uses onchange2 [2]. With onchange2, we send and
receive a diff, instead of the whole state of the record. Morever,
onchange2 uses unity, which means that returned commands for x2manys
(e.g. command 4, LINK) contain the values of the corresponding
records, so we don't need to fetch them in a separate call
afterwards.
3) The new model no longer triggers deep renderings (render(true)).
It is instead based on fine-grained reactivity (i.e. only what
depends on what has changed is re-rendered). We introduced a hook
"observeRecord" which allows a component to subscribe itself to
some keys in a record datapoint, and register a callback to
execute when those keys change (e.g. to fetch data).
[1] odoo/odoo@7d2baaa0c7
[2] odoo/odoo@f5e6494da3
Task~3179751
Part-of: odoo/odoo#114024
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: FrancoisGe <fge@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
This completes 96a98f4f4c in the case
where a many2one field has a new record as value, even when that
many2one field is not a delegate field.
Part-of: odoo/odoo#114024
Alexandre Kühn