| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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>
|
|
This commit extracts the DatePicker widget's input setter to allow
overriding it and preventing from calling the `datetimepicker` lib when
not initialized (like on mobile).
Note: this change will be used on enterprise.
opw-2242880
X-original-commit: c0413868a8728500c52b7e1dd9a0035f90b654fd
|
|
Issue
- Install CRM
- CRM > Reports > Activities
- Add a custom filter > Created on
- Select the date
You can't, the date picker is not shown
Cause
Actually, the date picker is shown but
very quickly and it is closed by a scroll
event thrown by Chart.js.
Solution
Close the date picker only if the user
scrolls manually.
OPW-2245019
closes odoo/odoo#50482
X-original-commit: bda320052ac937f5bc17c7da81d84633d72a8370
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>
|
|
fa-delete does not exist => fa-trash
introduced by: 6692919d1efc63ff2a28909c4155b99791d4bf79
task-2211899
closes odoo/odoo#48207
X-original-commit: 1b830bf1c7211dad5c93ac6929c7c395b32f3f90
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
|
|
Before this commit the sentence was a bit weird as a date is not on the future but in the future. This commit resolves this.
closes odoo/odoo#45548
X-original-commit: b335c33655a707f71fbc01929f5eea2e659e7215
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
This reverts commit ff1c35513aecef5fbc30f7c2f3834450e719714e.
closes odoo/odoo#41480
X-original-commit: 116057b26e71db4692280463669f3e80d813ddcc
Related: odoo/enterprise#7110
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
FontAwesome 5 introduced new names for some icons as described on
https://fontawesome.com/how-to-use/on-the-web/setup/upgrading-from-version-4#name-changes
This commit replaces the old names to the new ones.
closes odoo/odoo#35826
Taskid: 2050241
Related: odoo/enterprise#5180
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
- Set the computer TZ so that it is UTC day + 1. For example, set to
'Australia/Adelaide' and perform the tests after 3:00 pm
- Go to Account > Customers > Invoices
- Set the Invice Date to today in the TZ
You receive the warning 'This date is on the future...'
The comparison of a UTC date without time `currentDate` is inconsistent
with `moment()`, which is not UTC and has a time set.
After playing around with `.utc()` and `startOf('d')` with no luck, we
decided to give up the idea of making `getTZOffset()` enter the game and
simply compare the string formatted values.
opw-2093186
closes odoo/odoo#40984
X-original-commit: f9eec97cb128f71796fca0116841453555ab4684
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
-Import a subscription with end date beyond 200 in the future (ex: 2500-01-01).
-Open the subscription and click the Edit button.
Before this commit:
A stacktrace appears indicating that a date is not valid. It's not possible to
edit the subscription.
After this commit:
The maxDate of the date picker has been increased to 31/12/9999, allowing the
user to edit subscriptions whose end date is that far in the future.
A test `toggle datepicker far in the future` for this case has been created.
closes odoo/odoo#38527
Opw: 2079696
X-original-commit: 32b6131c04fef7a542a0ccbdb924d177627bfe38
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
closes odoo/odoo#37372
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
closes odoo/odoo#37314
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Since fbbfa6d it's not longer possible
to write a date without separator (e.g., 0102 for 01/02/2019; 121298 for
12/12/1998; 02042018 for 02/04/2018), or a date without year (e.g.,
01/02 for 01/02/2019) in the datepicker widget.
In this commit we have decided to be as permissive as tempus dominus
that call moment.js with strict false. This allows moment.js to deduct a
date from a string in a more versatile way. This also allows a more
versatile autocomplete in the search views.
opw-2070464
opw-2070931
closes odoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
|
|
Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.
Task 2068280
|
|
Changed the style of the "Close" button to match the one on the "primary buttons".
Task 2068164
|
|
Before this rev., the 'fieldChanged' event was triggered each time
the user selected a value (a day, an hour, a minute or a second) in
the datepicker. This means that if there was an onchange on the
field, a lot of RPCs could have been done when a user set a
datetime. In addition, in a list view with multi edition, the user
was asked to save the changes at each step of the datetime
selection, making the feature unusable.
Task 2068280
|
|
|
|
There is an open issue on the tempusdominus lib:
https://github.com/tempusdominus/bootstrap-4/issues/223
It occurs when there is a valid value in a date(time) field, and
the user unsets it by setting an invalid one.
This rev. fixes the issue in Odoo by preventing to reach the buggy
piece of code in the lib. In a few words, when the user sets an
invalid date, we reset the previous valid date (which is what the
lib tries to do anyway).
Task 2057009
closes odoo/odoo#36211
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
|
|
closes odoo/odoo#36491
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
|
|
Due to forward port, _onKeydown was declared twice.
This commit should fix an issue in mobile with Android 4.4 where
it's not allowed to have two functions with the same name.
Original Commit: a3d98dae68b97
closes odoo/odoo#33495
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
|
|
|
|
Before this rev., the datepicker was opened when a date(time) field
was focused (e.g. with keyboard navigation). We don't want this
behavior anymore, and we want the datepicker to open only when the
user clicks in the input. This rev. makes this change.
Moreover, this allowed to refined the keyboard navigation (ESC) in
editable list views: when a datepicker is opened, and the user
presses ESC, we close the datepicker, but we keep the row in
edition, whereas before this rev., the row was switched to readonly.
closes odoo/odoo#32408
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
|
|
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
|
|
Fine tuning of 5ef86ef6c874ab4dc78402493d05b2460c69e7f6
Steps to reproduce:
Set a custom language settings for date by switching the %m and %d.
Create a sales order
Current behavior:
Invalid date error boxes was raised two times
fixes #33408
opw:1998971
closes odoo/odoo#33415
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
Steps to reproduce the bug:
- Go to any field Date
- Enter wrong date
Bug:
A traceback was raised.
Now a warning is raised and the wrong value is removed.
opw:1974747
closes odoo/odoo#33362
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
|
|
|
|
Dropdown from many2xxx and datepicker widgets now close on scroll
to allow access of background information when scrolling.
Related to task #1929483
closes odoo/odoo#32836
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
|
|
Backport of 7bc53ac30e.
Assume an editable list view with a date(time) widget, click to
edit a line, focus the date field (the datepicker opens), press
ESC: there is a crash in the lib, and the datepicker remains open
forever.
This fix is twofold:
- we added a check in the lib to prevent it from crashing (it is
easily reproducible: it crashes when an opened datepicker is
removed from the DOM).
- we added an event handler of ESC keydown event to hide the
datepicker before the field is removed from the DOM.
closes odoo/odoo#32647
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
|
|
When using the datepicker with norwegian locales, the dates are
correctly formatted using the norwegian locale but the name of
the months are shown in english. This cause a date validation
error and thus it is not possible to change the date.
tempusdominus.js uses moment.js to deal with dates, it sometimes
copies/creates some and set their option according to the ones
given at instantiation time and fallbacks on default options for
that are not set.
opw-1922437
closes odoo/odoo#30276
|
|
Before this commit, when focusing on a date[time] field, the value was not selected
In v11.0, it was
This is due mostly because of the migration to BootStrap 4
After this commit, the value inside the input is selected
OPW 1911333
closes odoo/odoo#28989
|
|
If no value is specified on the datefield, do not set a warnfuture message
Remove code comment that was referring the condition present at b51b0d66c2f7
but no longer present.
Add tests
Fixes #27551
closes odoo/odoo#27593
|
|
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
|
|
Used in Enterprise (sale_subscription_dashboard).
Solve a traceback as reported on BS4 pad
|
|
Purpose
=======
There's no generic way to display a warning message if the user tries to set
a date in the future.
Specification
=============
Add this new feature on the datepicker (in web module), and use it account. For
example for the invoice date on the invoice/vendor bills form view.
TaskID: 1868221
|
|
* website_form, debian
Our old library for datetimepicker for bootstrap 3 is deprecated and
an updated version is developed by the same team under the new name
"tempusdominus", for bootstrap 4.
The lib is imported by taking the *unminified build* JS and the *src*
scss. Odoo is also bundling the lib better by putting the scss file
in both backend and frontend assets instead of only in common (so that
the scss is compiled differently for the frontend and the backend).
Note: the lib also needed to be patched inline to solve a bug at one
line.
|
|
Steps to reproduce the issue in 11.0 Enterprise:
- Go to the language English
- Remove from the time format the seconds
- Refresh the page
- Go to sales
- Create a sales order;
Bug:
- You get the warning message
closes #23596 closes #22027
opw:1829577
|
|
Before this fix, the chatter always showed dates of messages in military time format.
This was not the expected behavior, as the user could have had customize
the date and time format in the settings of the current language.
Steps to reproduce the issue:
1. Set Odoo in English
2. Settings > Translations > Languages > English
2.1. Set Date Format to %m/%d/%Y
2.2. Set Time Format to %I:%M:%S %p
3. CRM > (Select any opportunity with at least one message) > Mouse hover on elapsed time (e.g. "an hour ago")
Expected:
- It shows the customized time format (e.g. 11/07/2017 5:33:36 PM)
Results:
- It shows the military time format (e.g. Tue Nov 07 2017 17:33:36 GMT+0100)
opw-781647
|
|
|
|
Before this commit, and since the combination of new views + datepicker
library update, the datepicker opened at the top left of the window
when using it in a domain selector. It also could not be used at all.
This was because the current scenario occured:
1) Click on the datepicker
2) The datepicker triggers that it has changed on opening
3) The whole domain selector is rerendered
4) The datepicker computes where it should open... on basis of the
old destroyed domain selector
As the main cause of the problem here was the (2), this commit changes
the datepicker odoo widget to only notifies that it has changed when it
has really changed.
|
|
Fix a bunch of ill-documented/incomplete/incorrect method docs
Without this, the automatic doc generation does not work.
|
|
- datepicker doesn't default to current date by default
- date string in the input is now selected when clicking the field
- adapted the existing tests to the new changes
|
|
|
|
There were two main problems with the datepicker since the lib was
updated:
- it appeared broken in the search view "Filters" menu
- it did not overflow the parent which scrolls
Indeed, before the update, the datepicker was placed in the <body/>.
Now this is a lib option. Unfortunately, the option is broken (I don't
know why they broke it since it worked before the lib update...). As the
lib does not expose its internal functions, the only found workaround was
to patch the lib code itself.
opw-745311
opw-745625
|
|
|
|
|
|
before this commit when toggling allday flag in calendar form view, it was
possible to have one day error.
The input datetime is wrong when the user don't use the datepicker widget
(insert date by keypress instead of click on datepicker)
sometimes, the value could be null (crash because try to clone false)
|
|
When you try to empty a date or datetime field, you get a traceback
saying that 'clone' and 'isSame' are not functions.
This error occurs when you empty the field because the value is 'false'
and you cannot call 'clone' or 'isSame' on false.
To fix this, we ensure that value is not false before calling these
methods on it.
This bug has been introduced in rev: https://github.com/odoo/odoo/commit/c32724eae06c987e74a0600f1669696e499edc33
|
|
The client must receive the tzOffset to apply this on all hours.
To use the date picker we must change the date to apply the change
in the user's tzOffset, without this change the result is wrong.
For datetime widget we must change like it to avoid max stack error.
The server send the tzOffset, if it's undefined, by default the client
use the browser time offset.
Every test are change to use tzOffset.
A test is added in calendar to use the click by position for the
fullcalendar lib. This test create and drag and drop an event to check
timezone error and error when we use default value in the context.
Use formating date like 2026-04-04T08:00:00Z instead of 2026-04-04 08:00:00
is important for phantomjs, because it's crash without information if the
formating is not the standard format.
For the parsing, when the client receive a server date the date is utc
formating but when it's parsed from the client is in the user's timezone
|
