| Age | Commit message (Collapse) | Author |
|---|
|
- `parseDateTime` util: we now caches "without zero" date and time formats
Taskid: 2412172
|
|
with this commit we disables autofill of autocomplete by setting
autocomplete=off, this was previously done in commit: 64293fbdb0a247f689c1b0b0c580d9ce577af510
but it was not working because we were setting autocomplete=none
it seems that none does not work all the time.
task-2462676
closes odoo/odoo#68271
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
closes odoo/odoo#68085
Signed-off-by: Christophe Monniez (moc) <moc@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
closes odoo/odoo#67358
Signed-off-by: Lucas Perais (lpe) <lpe@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
closes odoo/odoo#67373
X-original-commit: fa324ef071952d749f635f878bee0fa462cfa011
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: be5e5bc49cb9744c26ca75dcee74caf11447f250
|
|
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
closes odoo/odoo#67174
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
STEPS:
* Add related phone field to a form (e.g. partner_id.phone to sale.order form)
* Use widget "phone" + activate sms feature
* Create a record
* Click edit, select partner that has phone specified (e.g. +1 234), edit
partner's phone (e.g. +1 234 555), save
BEFORE: ``+1 234 []SMS`` is converted to ``+1 234 555 +1 234 555``
AFTER: ``+1 234 555 []SMS``
WHY:
* FieldPhone is inherited from FieldEmail
https://github.com/odoo/odoo/blob/0de069b8ca9fb005ba5b076984f5677de25889ee/addons/web/static/src/js/fields/basic_fields.js#L1549
* sms module adds SMS button to ``$el``
https://github.com/odoo/odoo/blob/0de069b8ca9fb005ba5b076984f5677de25889ee/addons/sms/static/src/js/fields_phone_widget.js#L91
* So this commit filters ``$el`` before updating it
---
opw-2425949
closes odoo/odoo#64156
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
Issue
- Install "Field Service" app
- Create new task
- Try to select Planned start/end date and valid
Daterange picker is hiding when trying to scroll down to valid selection.
Cause
The daterange picker is closed when ev.target is not inside the picker,
however ev.target always return the document element.
Solution
Do not hide daterange picker on scrolling if on mobile.
Note : It will only apply if scrolling on the daterange picker and
will still hide if scrolling outside this last one.
opw-2428099
closes odoo/odoo#65423
X-original-commit: fb01006342c6d6fd902e13a5f4c2642c87fe452d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Commit [1] adds an override of the getFocusableElement of
AbstractField in FieldRadio, but this function was already defined.
Even though it doesn't crash, this is obviously not something to
do. This commit removes the first occurence (which was overriden
by the second).
[1] https://github.com/odoo/odoo/commit/ebe118fc607391737adc37e18c3278a3d2c87b5e
closes odoo/odoo#65372
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
This is the javascript equivalent of `_("Foo %s" % bar)`
https://www.odoo.com/documentation/master/reference/translations.html#variables
closes odoo/odoo#65004
Related: odoo/enterprise#15936
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Let's assume the following scenario with 'purchase_product_matrix'
module installed:
- create a new Purchase Order
- add a line in the one2many
- select "Customizable desk" as product
- [the desk matrix opens]
- close the matrix
- select "Conference chair" instead
- [the desk matrix opens, whereas it should be the chair one]
It didn't work because of a small bug in the FieldOne2Many. This
field is configured to be reset when any other field in the view
changes. The product configurator feature relies on that. However,
when another field changes, the One2Many didn't update its internal
state with the new record (and it skipped the rendering, which is
fine). The matrix product configurator thus read an obsolete value
in the internal of the one2many.
Since the internal state is now always up-to-date, we can directly
read there the grid information, instead of looking inside other
fields that have been updated (attempt done in [1])
It would be nice to rethink the whole product configurator stuff
in master, to make it more robust, maybe when converting it to owl?
[1] https://github.com/odoo/odoo/commit/21bcafc053be7f80eed7a684fee2dc1e3caaafa5
opw~2421798
closes odoo/odoo#64552
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
stock.picking
What are the steps to reproduce your issue?
1. Install "stock"
2. Go to Inventory/Inventory Overview/Internal Transfer
3. Create new record and set manually a date with year < 1000 like "0008-10-10 18:35:00"
4. Save
What is currently happening?
An error arises when saving the record, and it is then no longer
possible to reopen the records or any view containing it.
This also prevents us from correcting the date to no longer have the error
Why is this happening?
The root cause is an inconsistency in `strftime` for years < 1000 [1, 2]. To take it into
account, a zero-padding is needed in the DateTime parser.
How to fix the bug?
The missing padding is added.
However, such dates lead to problematic behaviors in Python:
```
DT_FORMAT = "%Y-%m-%d %H:%M:%S"
new_date = "0008-02-05 18:10:10"
datetime.strptime(
datetime.strptime(
new_date, DT_FORMAT
).strftime(DT_FORMAT),
DT_FORMAT
)
```
This raises:
```
ValueError: time data '8-02-05 18:10:10' does not match format '%Y-%m-%d %H:%M:%S'
```
As of today there was no reported business cases where dates with year < 1000 would be
necessary. Therefore, we limit the range to years >= 1000.
[1] https://bugs.python.org/issue13305
[2] https://docs.python.org/dev/library/datetime.html#strftime-strptime-behavior
opw-2408260
closes odoo/odoo#62818
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
The ControlPanel has been converted in Owl [1], and the code using
it has been adapted accordingly. However, in the FieldX2Many, we
didn't properly wait for the ControlPanel to be updated (an update
of the ControlPanel was synchronous before owl, and is now async,
like every Owl renderings, as it waits for the nextAnimationFrame).
As a consequence, we might have tricky issues because the mounted
hook of the control panel might be called multiple times for a
single call to willUnmount later on. In mobile, we bind a global
event handler (on scroll) in mounted, and unbind it in willUnmount,
so we had leftover event handlers, that crashed when called after
the ControlPanel was destroyed. Note that even if the issue popped
in mobile, calling mounted on already mounted Components isn't a
good idea, and this should be fixed anyway.
The issue could be reproduced for instance in FieldService (with
collaborative pads activated in Project), in mobile, by opening
a task in Edit mode. Then, you might get a traceback by scrolling
after having discarded the edition
Here is a description of what technically happened:
- when clicking on Edit, all widgets (including the FieldX2Many
are destroyed and re-instantiated in 'edit' mode).
- the pad widget directly triggers a field_changed event which
causes a reset of the FieldX2Many (i.e. 'render' is called
again)
- the FieldX2Many detects that it already has a renderer (and a
ControlPanel) so it updates them
- it first updates the renderer, and when it's done, it updates
the ControlPanel BUT doesn't wait for its promise, so the
promise returned by that call to 'render' in FieldX2Many is
resolved before the ControlPanel is actually updated
- note that at this point, all thoses new widgets are not in the
DOM yet
- when all widgets are ready, the renderer patches the view (i.e.
the former content is removed from the DOM, and the new one is
attached into the DOM). As soon as this is done, the renderer
calls 'on_attach_callback' on its children, including the
FieldX2Many, which leads to a call to 'mounted' on the CP.
- then, just before the nextAnimationFrame, Owl complete the
rendering of the CP, and detects that it is now in the DOM (it
wasn't at the beginning), so 'mounted' is called a second time,
will cause the issue described above.
This commit fixes the issue by properly waiting for the CP to be
rendered in the FieldX2Many. However, this required on cascade
changes:
- Form view renderings with a FieldX2Many are now *really* async
(+- 16ms), meaning that the user can easily trigger concurrent
renderings by, e.g. clicking quickly several times on 'Edit',
'Save' or 'Discard'. Concurrent renderings are properly handled
so to prevent this from happening, we disable the buttons and
re-enable them when the rendering is done (like already done in
[2])
- in the FieldX2Many, '_updateControlPanel' was called at several
placed, but we never waited for it. As this method was
originally sync, its calls have probably been naively adapted,
whereas their should have been deeply rethought (for instance,
as it is async, and we need to wait for it, we don't want it
to be called multiple times sequentially when something happens).
This commit does that work, i.e. we clean the places where this
function is called such that it is (hopefully) never called
sequentially twice. To do so, we changed a bit the spec of the
pager in multi page, and we also fixed a paging-related bug.
In a few words, here is what we did/do when adding a new row
in the bottom of a full page:
- before: tweak the count in the data to fool the pager and
make it think that no new record has been added (so
basically, let it display something wrong)
- now: temporarily increase the pager limit so that the new
record is displayed on the current pager, and the pager
values are correct w.r.t. the displayed records.
Some tests needed to be adapted accordingly.
- By waiting for the ControlPanel when updating the FieldX2Many,
a bunch of QUnit tests failed. Those tests have something in
common: they spawn an X2Many (list or kanban theoretically,
but always list in practice) containing a FieldBoolean (only
field widget of /web converted in owl). When the FieldX2Many
is updated, we update the renderer (i.e. re-renderer the
FieldBoolean, so we have to wait for the nextAnimationFrame),
and when this is done, we update the page (again, we have
to wait for the nextAnimationFrame). So basically, we have
to wait for two nextAnimationFrames to see the result in the
DOM. For this, we added a new test util which basically does
a nextTick ('owlCompatibilityNextTick'), and called it
everywhere it was necessary. When everything will be written
in Owl, we could get rid of this util and its calls.
[1] https://github.com/odoo/odoo/commit/fbf347498f1cc7b74ef373179b7bcae201715c24
[2] https://github.com/odoo/odoo/commit/39f08950d6e20460e3a20a5b9c33e4ddf66dce78
closes odoo/odoo#61593
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
Fix traceback when creating a new contact by checking the id list is not empty
Filter default reporting by name rather then by campaign (as campaign is an option)
Group by Campaign only if the option is checked to enforce coherency.
> This is unblocked with a group.
Hide the 'replied' status from sms reports as it is not relevant for sms.
Remove the preview message for sms as it is not relevant elsewhere then the object of mails.
Warn the user if he's trying to send a sms with only white-space characters.
> this causes an error because the plaintext-html conversion in mail_thread.py
> consider a white-spaces-only text as empty.
Mobile placeholder added for a better understanding of the field by the user.
Task ID : 2302578
closes odoo/odoo#60426
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
|
|
The `remaining_days` widget is intended to be used for informative purpose,
hence it should not be editable.
opw-2362276
|
|
When manually updating the time on a daterange widget, the value sent to the
server is not converted to UTC and is sent as it appears on the input.
currently daterange widget send datetime value as it is, written in input field
if manually entered, so if user set 10:00:00 so while sending data it will be
send as it is 10:00:00 so when next time record reloaded after save, it will
display 15:30:00 if timezone UTC+5:30.
Instead, change the string date to moment object with current user timezone.
so that datetime send to server is UTC time and when next time it is loaded
it adds user timezone difference, so if timezone is UTC+5:30 and user enters
10:00:00 then while sending data to server it sends 04:30:00 and when displayed
again after reload it adds +5:30 timezone difference.
LINKS
PR #50132
Task 2240378
closes odoo/odoo#59208
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
if readonly attribute is given on priority widget then priority widget should
not be clickable and hover effect should be removed so that user can easily
understand that field is readonly.
task-2339680
closes odoo/odoo#59189
X-original-commit: 53dbfc7a65a8eb2f41d6b2373cf628c4800d1f57
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
When navigating fields using the keyboard, it's not possible to reach
most of widgets for selection fields. That is because most of them
consist of one main element containing several other ones, one per
possible selectable value (e.g. buttons). When their focusable element
is computed, the main element is taken, instead of its sub-elements,
which causes the field to be skipped when navigating.
This commit fixes the above, as well as some missing aria attributes and
keyboard events, for the following widgets:
- `priority`
- `state_selection`
- `statusbar`
- `radio`
opw-231112
closes #58302
closes odoo/odoo#58418
X-original-commit: 2471e7c176c5df0f310f2939f8a6cf6948c0ac0c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
currently, whenever the view is change the picture zoomed in
and still displayed, only disappears after having refreshed the page
so, in this commit the employee picture should no longer to be
zoomed in whenever change the view
closes odoo/odoo#57571
Taskid: 2311308
X-original-commit: 8214332ccd86e52c4f18de8d5428a1a22f2ad21c
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
Task 2327599
It is used in the selector of a tour to know the type of a document.
|
|
This new widget allows definition of Images through static urls stored in a Char field.
It was implemented to provide a way to reduce databases footprint by using
static files instead of duplicating them in the databases (& their backups).
|
|
The document layout preview is a complete defferent simplified template
with its own css that replicates at best the different styles.
It does not have the external layout features and lack of fidelity.
The new preview actually use the real documents templates and put the
result in an iframe. It now has a high fidelity, though not perfect.
The goal is for a better onboarding, where clients see easely how
documents will look if they had an app to generate them. Of course, the
data on the document is a false invoice.
Refactor all this from base to web.
Task ID 2304177
closes odoo/odoo#56415
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
Follow-up on 6edb7495346119e2ceb25f5b5b5568b4b890dd86, where default
`autocomplete` values were introduced as default for password fields,
according to the new autofill specs.
This patch allows developers to force the "autocomplete" attribute value
on password fields, in case there really is a need for a value that is
not `new-password` (which BTW now triggers the password generator wizard
in many browsers).
It is useful for example when a backend form really needs to ask the
user for their current password, so the correct `autocomplete`
value is `current-password`, as on the login form.
|
|
This commit adds smart date inputs for date and datetime fields.
The goal of smart date input is to provide the user some shortcuts
when setting dates.
The rule is [+-]\d+[dwmy]?
So we can enter inputs like:
+3 to have today + 3 days
-2w to have today - 2 weeks
+1y to have today + 1 year
+5m to have today + 5 months
-4d to have today - 4 days
closes odoo/odoo#55602
Task: 2270347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Currently, when form view is opened in edit mode and if you proceed
through the tab(keyboard) then focus is skiped on radio field.
For Ex: in project when you procceed through the tab it will skip the
visibility field radio.
The issue occurs because the radio is inherited from the selection
field and in selection field the focus is set on 'select' while
there is no method to set the focus in radio and radio does not have
'select' element it has 'input'
So in this commit, override the method getFocusableElement in radio
widget and set the focus on 'input' instead of 'select'.
closes odoo/odoo#52073
Taskid: 2252798
Closes: #52073
Related: odoo/upgrade#1430
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
in days
Purpose
=======
There are several places where the duration is expressed in hours even though the encoding unit is in Days.
Specifications
===========
The duration should be expressed in days instead of hours in the following places:
[x] Timesheet Entries
[x] Portal > Tickets
[x] Portal > Timesheets
[x] Portal > Tasks
[x] Portal > Sales Orders
[x] Project Overview
[x] Project task form view (in this case, the label of the field should be 'Planned Days')
[x] Timesheets > HR Timesheet/Attendence Report
[x] Project > All Tasks
Hide the following elements if the encoding unit is in days:
[x] 'Timesheet Timer' feature on the project form view
[x] 'Timesheet Timer' feature on the Helpdesk team form view
[x] the 'Round timesheets' feature in the settings of Timesheets (except if the 'Awesome Timesheet' feature is enabled)
Bonus point:
[x] Timesheet form view: 0.00 Days should be displayed in read-only if the duration = 0
Some labels need to be adapted to explicit the unit of measure (is it carrots? potatoes?): e.g. Duration (Days) or Time Spent (Hours) :
[x] Timesheet entries report
[x] on the portal
[x] Project overview: add 'recorded' next to Hours/Days
[x] Project overview: add 'Days/hours Spent' above the total by employee
[x] task form view: make sure the 'sub-tasks days spent' button/label stays on one line
[x] hide the 'start' button on project tasks and helpdesk tickets if the encoding unit is in days
Task ID : 2152322
closes odoo/odoo#46184
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
The field was hidden in UI when its value was not set or equal to 0.
Display the field if its value is set to 0.
[IMP] web: clean code
|
|
Issue
- Install Employees & Dashboard
- Add employees to kanban
- Dashboard
- Hover an employee picture
There is only the picture visible
on the page, the remaining space is white.
Cause
I found several issues.
1. The pictures are not shown on hover in employees
But they are on dashboard.
2. $attach = all `.content` and on dashboard there is
2 `.content` so the flyout is append 2 times
3. The move method is trigerred on hover too, it hides
the flyout if we are not in it. But with attachToTarget
we are not in it so it's hidden all time.
4. If everything above is solved, the image is shown but
not at the correct position because the flyout base
position is not top 0, left 0
Solution
1. Reduce the minimum required size to 128px
2. use closest instead of parents
3. Don't hide if we have the option attachToTarget
4. Calculate the flyout offset and replace it correctly
and set it to position fixed to handle scrolling
OPW-2291493
closes odoo/odoo#54333
X-original-commit: 2c6d692ee40c97d2ae63da64db7623702948407e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
Before this commit, boolean fields (without widget="boolean") in
kanban views were displayed as [Object object], because when no
widget is specified, we display the (textual) formatted value of
the field. However, the boolean formatter returns by default a
string encoding an html checkbox.
This commit passes the correct option to force a string formatting,
so it now displays "True" or "False". Moreover, this commit
uniformizes formatter options for that purpose, as another option
had been recently introduced for monetary field.
Note that those options should not be necessary, as formatters
should always return text values (no html). But this is a larger
change, that we might do in the future.
Task 2280394
closes odoo/odoo#53937
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, user could not selecta a date before year 1900.
This was an historical limitation due to python < 3.2 that didn't
support dates before 1900.
After this commit, user can select any date, user can select any
date from 01/01/0001.
taskID: 2166761
Fixes #41788
Closes #43055
closes odoo/odoo#51406
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Before this commit, any value could be added to registries and the class
needed to be overridden to assert that added values would answer to a
certain predicate.
Now, the registry can be instantiated with a given predicate function
that all added value must pass to be registered (default: all values
are accepted).
Existing implentations have been adapted:
- FieldRegistry
- FieldRegistryOwl.
|
|
A recent commit [1] made the daterangepicker automatically close
itself on scroll events. However, in firefox, a scroll event is
triggered when the daterangepicker opens. This event is triggered
inside the picker itself. As a consequence, the picker is closed
directly. This commit solves the issue by only closing it on scroll
events occurring outside the picker.
[1] https://github.com/odoo/odoo/commit/e6730c6e928587cd7438340cc101c57fee34220b
closes odoo/odoo#53497
Task: 2282571
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Before this commit, monetary fields occurring in kanban views
without widget="monetary" specified weren't correctly formatted:
the whitespace separating the value from the currency symbol was
formatted has $nbsp; (html) instead of a simple whitespace.
closes odoo/odoo#52521
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
Before this commit, the daterangepicker always opened below the input,
even when there was not enough space to display it. Moreover, when the
user scrolled while the picker was opened, it wasn't stucked to the
input, so the picker was displayed at a random position after the
scroll.
With this commit, we compute the available space above the picker
when opening it, and if there is enough space, we display it above,
otherwise, we display it below. Moreover, we automatically close
the picker when the user scrolls.
task-2117229
closes odoo/odoo#42161
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
This commit adds noLeadingZeroHour option to formatFloatTime.
The noLeadingZeroHour option can be used to format the value
like 1:30 instead of 01:30
This format behaviour is wanted for fields in web_grid module.
Task 2261853
closes odoo/odoo#52217
Related: odoo/enterprise#10870
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Hardik Prajapati <hap@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
|
|
closes odoo/odoo#52826
Related: odoo/enterprise#11084
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
closes odoo/odoo#52347
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Generally, Users are not necessarily aware that they can quick create a most
records by simply typing in their name+enter in the many2xxx field input.
The exact purpose of this commit is to make sure the user discovers the quick
create feature of our many2xxx fields.
For that, when the input is empty, display 'Start typing to create a record...'
at the bottom of the dropdown when can_create is set and no_create_edit option
not set. So the user can easily understand that by typing and pressing enter
will create the new record.
Also "Search and Create" options in the dropdown only been shown to the user
when it type anything in the input box as the same case in the "Create" option.
Task : 2266557
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
|
|
*: website, web
Move the colorpicker dialog logic into a colorpicker *widget*, which the
colorpicker dialog will now instantiate.
Part of https://github.com/odoo/odoo/pull/46088
task-2195313
|
|
In a form view, have an x2many list with two fields A and B (e.g.
A is a many2one, and B is a char). There is an onchange on the
x2many that is triggered when the user sets A, and that sets B.
In this scenario, let's assume that the user first writes something
in B, but directly deletes it. Then, he sets A. Before this commit,
in this situation, B wasn't updated with the value returned by the
onchange.
Indeed, B's field widget was still flagged as 'isDirty', because
the user interacted with it, but it didn't commit its value, as it
hasn't actually changed. Basically, it remained flagged as 'isDirty'
forever, and thus couldn't be updated with the value returned by
the onchange.
This commit ensures that the 'isDirty' status is correctly updated
when the change is actually undone.
Task 1958793
closes odoo/odoo#51085
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: pka-odoo <pka@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
Issue
- Install Projects
- All Tasks > Form View
- Edit the view
- Set statusbar clickable to '0'
Still clickable
Cause
In relational_field.js we do
`!!'0'` which returns true
like `!!'anythingelse'`
Solution
Add a '+' which will convert
the value into an integer
for a better conversion.
OPW-2235311
closes odoo/odoo#51083
X-original-commit: 53cc68fce32f46a0b4bc83a1e73a5d13a60fc995
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
before this commit,
tabbing into the date or datetime field input it has only focus, value is not
selected.
after this commit,
navigate through a view in edit mode with the TAB key, when focus comes into
date/dateetime field input then input is focused and value of date/datetime
field is also get selected.
task-2246593
closes odoo/odoo#51062
X-original-commit: 962e4e18b559d90aa3456c77035659ac8017501d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
|
|
Before this commit, it wasn't possible to multi-edit boolean
fields in list views. Actually, it didn't work for fields rendered
by Owl components. It only impacted boolean fields because it was
the only editable field widget that had already been converted in
Owl.
It didn't work because of three issues:
1) there is some sort of an hack in basic renderers: we set the
attribute '__node' on the field widgets, and this attribute is
used for instance by the controller, when it has to handle a
multi-edition. It tries to read it from the event's target
(typically the field widget). However, with owl components,
'__node' was set on the FieldWrapper (wrapping the actual
Field Component).
2) the original target (the Owl Component which triggered the
event) was lost when the event went through the compatibility
layer (for owl Component embedded in legacy widgets).
3) the multi-edition confirm dialog didn't handle Owl field
components.
Task 2254717
closes odoo/odoo#51044
X-original-commit: 36d23cfcdef3cea3539004ee5bb4479b859b8137
Signed-off-by: Michaël Mattiello <mcm-odoo@users.noreply.github.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Write something in a many2one field, and click on 'Create "..."'
to quick create a record with the given value (name_create). When
the name_create fails (e.g. because there are mandatory fields in
the model), we open a form view.
Before this commit, when this happened for many2one fields inside
x2many editable lists, it crashed, since [1].
[1] 50bf8309f88fb6c8d8e27b14d40450e92e5a4e4e
closes odoo/odoo#50948
X-original-commit: 43c513306094444ff25ad98584b426ddb8a3b525
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
Issue
- Install sale_renting
- Create a rental order
- Add a "rental" product
- In Modal, change start or end time
In Firefox, user not allowed to change the time;
time select not reacting well.
Cause
The issue seems to be that in bootstrap when
we click outside a modal, we focus on the modal:
https://github.com/odoo/odoo/blob/27f67bfcb903/addons/web/static/lib/bootstrap/js/modal.js#L332-L337
and the FieldDateRange widget contains a <select/> tag
and is added outside of the modal, so when we click
on the select, bootstrap will focus on the modal which
in firefox seems to lose the focus on the <select/>
which get closed.
Solution
not propagating focusin event when the select of the
daterange widget is focused => in my opinion this is
the less risky solution, this could be done with a
code such as (in the FieldDateRange._renderEdit method):
opw-2240220
closes odoo/odoo#50906
X-original-commit: 5a1e9e32061996ca1770c9ae9b5a7e7f53c5048f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
Having _lt in the env doesn't make much sense, as it is useless
at run time, and it would incite people to require 'web.env' to
use it (at load time). The env should never be directly imported,
it is automatically propagated from parents to children.
To sum up, in Owl components:
- when terms have to be translated at run time (e.g. in a function
called when the user clicks on a button), the env is available
and env._t must be used
- when terms have to be translated at load time (e.g. a JS module
defining a component with a translatable static property), one
must require 'web.translation' and use function _lt it exports.
closes odoo/odoo#50656
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
|
|
This commit improves the dialog that opens when a user clicks out
of an 'un-commited' many2one. It is no longer possible to edit
the value, and the sentence has been reworded.
closes odoo/odoo#49528
Task: 2234212
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
|
|
If set, this value will be displayed as column name in list views.
This attribute could be used in the future in form view for the
same purpose.
Part of task 2195254
|
|
In readonly, this widget displays the image of the related record
next to its display_name. In edit, it behaves exactly like the
regular many2one.
Part of task 2195254
|
