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
closesodoo/odoo#55602
Task: 2270347
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#41788Closes#43055closesodoo/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 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
closesodoo/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>
Before this commit the % symbol was part of the input. We could write a
value with the % symbol to divide the value by 100 (50% = 0.5, 50 = 50)
This commit removes the % symbol from the input and adds it in a span
after the input so we do not need to write the % symbol anymore.
The value from the input will be saved as $value / 100 in database.
task-2065078
closesodoo/odoo#43995
Signed-off-by: Aaron Bohy (aab) <aab@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
closesodoo/odoo#37095
Forward-port-of: odoo/odoo#36821
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.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
closesodoo/odoo#30276
When a percentage if formatted, the decimal separator used is always
`.`, while it should be the decimal separator of the language.
opw-1908220
closesodoo/odoo#30030
A recent modification of the float and integer
formatters allowing the rendering to be human readable
causes a bug in the percentage formatter for large values.
The reason is that the latter formatter uses formatFloat (wich can
now produce 'numbers' like 3k) and then parse the result. In the case
of 3k an error is raised since 3k is not recognized as a true number.
This fixes avoid to parse the number in case it has been formatted
to be 'readable'. Note that the parsing was essentially used
to produces better percentages like 10% instead of 10.00%.
This is not necessary in our case since utils.human_number takes care
of the unwanted (not all) decimals for us (the original number is always
rounded by utils.human_number).
Binary fields were simply shown simply by their textual representation in list views,
e.g. the base64 string.
There was no formatter for binary fields, therefore it has been implemented so that
it displays its estimated size.
Binary fields in list views had a download link in v10.0.
We provide this feature back by means of a widget called 'download_link'.
It is also possible to define an option to set the field name having the filename as its value.
Example:
<tree>
<field name="fname"/>
<field name="datas" widget="download_link" options="{'filename': 'fname'}"/>
</tree>
with the following record: {fname: 'document.txt', datas: 'Cg=='},
we get a file named "document.txt" by clicking on the download link.
Closes#21996
The parsing of the integers does not escape the thousands separator.
issue: Integers are currently not properly parsed. For example, create
a database in Spanish language, install product_expiry and in settings
activate Lots & Serial Numbers. Go to Products and create a new product.
Choose to track by lots and specify the use_time, life_time, etc.
When saving, all integers are set to 0
With the new views, we stopped using the browser timezone to
display the dates in Odoo, and we used the timezone defined on
the User profile instead. When loading the webclient, the
timezone offset was put into the session and used to display all
dates. This wasn't a good idea.
The given offset was computed for the current time, meaning that
it may be incorrect for specific dates (e.g. with the daylight
saving, the UTC offset of today is not the same as 6 months ago).
Moreover (but less likely), as the offset was stored in the
session, it wasn't recalculated afterwards. So if the offset
actually changed during the session (e.g. from or to daylight
saving time), the displayed dates were incorrect until the user
reloaded the page.
With this rev., we don't retrieve the offset from the server
anymore and we use the browser timezone again (like before the new
views). However, we keep the computation of the offset (on the fly)
in the session, so that it can be mocked in the test environment.
Before this rev., all date fields values were off by one day as
soon as the user timezone was negative.
With the new views, all dates manipulated by the JS are moment
instances in UTC, and when being displayed, they are correctly
formatted in the user locale by applying the timezone offset.
However, this should obviously not be done for date fields as
when no time is specified when creating a moment instance, it
defaults to 00:00:00, so applying a negative offset always leads
to the day before.
Remark:
It happens that datetime fields are displayed as a date (e.g.
purchase order line form view). In that case, the offset is
applied on the displayed date.
In field_utils, the parse monetary method was remapped to parsefloat. In this commit, we add a specific parseMonetary method to handle currency specific formatting.
In a slightly too naive way, we apparently tried to improve the
parse_float method while rewriting the new views. This was done by
using a regexp to match all occurences of a thousand separator.
The way the regexp was built was fine, until the thousand separator is a
'.', which, if used as a regexp, matches all characters. Also, sadly,
'.' is not so rare as a thousand separator...
Before this commit, it was not possible to see the difference between an
unset float field (with a 'false' value) and a set field (for ex, with
value 0)
This was due to the fact that the formatFloat/formatMonetary functions
format false values as the number 0, unlike many other formatting
functions.
Before this rev., the function that parses monetary fields (i.e.
the one that converts the string value of the input into a
numerical value) totally ignored the sign of the value.
Actually, parsing a monetary field is exactly the same as parsing
a float field, so we simply use the same function.
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
Michael Mattiello (mcm)