Created attachment 186599 [details] XML Form Document - Test with older versions of LO - newer will show all with wrong type. This bug could only be reproduced with older LO versions, because newer version will show all fields as fields with wrong data type. Tested here with LO 6.4.2.2: Open the attached XML Form Document. Data types are shown in first column. Second column contains all text controls to show the data, which could be saved by the form in this datatype. There are set many wrong values, but no text control is marked by a red border as field with wrong value: Date, DateTime, Hyperlink, Year, Month, Day, Time As I understand the code all this fields are defined by forms/source/xforms/datatyperepository.cxx. So It should be impossible to set a string in a field for Time. You could use other (special) form fields. Best field will be the formatted field. But: XML form documents should throw an error if the data type is wrong and they don't. You could create new data types and will get the right result for this data types. So it seems to be only numeric types will be proofed the right way.
Confirmed with 6.4, 5.2, 3.5 on Linux. (In reply to Robert Großkopf from comment #0) > This bug could only be reproduced with older LO versions, because newer > version will show all fields as fields with wrong data type. This is bug 154734
Robert: I gave a try with https://gerrit.libreoffice.org/c/core/+/150582 for date, datetime and time part. For day, month, year, I'm searching an official and clear spec to see what's expected (eg: what's the max year, what should be the input of month - a number corresponding to the month or the name of the month...) Eike: for time part, I noticed that 00:59:60 was converted to 00:01:00, reading https://en.wikipedia.org/wiki/ISO_8601, it can be used for the "leap second" but I tried too 00:60:00, LO doesn't complain and consider "60" as a wrong "leap minute", is it expected? Here's the relevant part: #2 0x00007f6e52cad7dc in utl::ISO8601parseTime(std::basic_string_view<char16_t, std::char_traits<char16_t> >, com::sun::star::util::Time&) (aTimeStr=u"00:61:00", rTime=...) at unotools/source/misc/datetime.cxx:383 #3 0x00007f6e0dbfb55a in (anonymous namespace)::lcl_toUNOTime(std::basic_string_view<char16_t, std::char_traits<char16_t> >) (rString=u"00:61:00") at forms/source/xforms/convert.cxx:184 #4 0x00007f6e0dbfa466 in (anonymous namespace)::lcl_toAny_UNOTime(rtl::OUString const&) (rString="00:61:00") at forms/source/xforms/convert.cxx:214 #5 0x00007f6e0dbfac25 in xforms::Convert::toAny(rtl::OUString const&, com::sun::star::uno::Type const&) (this=0x7f6e0dcb8bf0 <xforms::Convert::get()::aConvert>, rValue="00:61:00", rType=invalid uno::Type) at forms/source/xforms/convert.cxx:300 #6 0x00007f6e0dbd1fbf in xforms::Binding::getValue(com::sun::star::uno::Type const&) (this=0x55e68647ce60, rType=invalid uno::Type) at forms/source/xforms/binding.cxx:971
For month, day, year, I read in https://www.w3.org/TR/xforms20/ "Data Binding Restrictions: Binds only the following list of datatypes, or datatypes derived by restriction from those in the list: xsd:duration, xsd:date, xsd:time, xsd:dateTime, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:float, xsd:double, and xsd:decimal." gYear: if I interpret well, the range is between 0 and 10000 (not 1000000) (see https://www.w3.org/TR/xmlschema11-2/#gYear + https://www.w3.org/TR/xmlschema11-2/#partial-implementation) gMonth: it seems a number between 1 and 12, not some string (see https://www.w3.org/TR/xmlschema11-2/#gMonth) gDay: ok until 31, https://www.w3.org/TR/xmlschema11-2/#gDay Robert/Eike: is it ok for you if we try to stick to this?
(In reply to Julien Nabet from comment #3) > For month, day, year, I read in https://www.w3.org/TR/xforms20/ > > "Data Binding Restrictions: Binds only the following list of datatypes, or > datatypes derived by restriction from those in the list: xsd:duration, > xsd:date, xsd:time, xsd:dateTime, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, > xsd:gDay, xsd:gMonth, xsd:float, xsd:double, and xsd:decimal." > > gYear: if I interpret well, the range is between 0 and 10000 (not 1000000) > (see https://www.w3.org/TR/xmlschema11-2/#gYear + > https://www.w3.org/TR/xmlschema11-2/#partial-implementation) What is with negative values? > > gMonth: it seems a number between 1 and 12, not some string (see > https://www.w3.org/TR/xmlschema11-2/#gMonth) Right, should be numbers from 1 up to 12, no strings. > > gDay: ok until 31, https://www.w3.org/TR/xmlschema11-2/#gDay Also right, from 1 up to 31. Would be great if you got this one working …
(In reply to Robert Großkopf from comment #4) > ... > > gYear: if I interpret well, the range is between 0 and 10000 (not 1000000) > > (see https://www.w3.org/TR/xmlschema11-2/#gYear + > > https://www.w3.org/TR/xmlschema11-2/#partial-implementation) > ... > What is with negative values? "All ·minimally conforming· processors must support nonnegative ·year· values less than 10000" Of course, we could accept negative values (and values above 10000) but, unless I miss something, if the XML generated is sent to other applications, we're not sure these apps will accept this. For the rest, I'm waiting a bit some feedback to know if the first patch is the correct way to deal with this bug.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3b4982b9c702002072dc3a9f7755f820eada08e7 Related tdf#154769: XML form, detect misformed date/datetime/time It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
For Year, Month, Day, I've submitted this patch for review here: https://gerrit.libreoffice.org/c/core/+/150652 BTW, could you tell me about Listbox and Combobox, shouldn't they be in red since Rheine don't belong to list in both case ?
(In reply to Julien Nabet from comment #7) > For Year, Month, Day, I've submitted this patch for review here: > https://gerrit.libreoffice.org/c/core/+/150652 > > BTW, could you tell me about Listbox and Combobox, shouldn't they be in red > since Rheine don't belong to list in both case ? Listbox: You only could chose this values. But all the values of the listbox are characters. So it will show nothing if there is a value, which isn't in the list. And if a listbox is the only entry for this node in a XML-form it will be impossible to input other values. Combobox: You could chose values or create your own. All should be shown by the box. So both boxes will work well if they don't appear in red.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4d8a46b819fb65ff13e306ac2c1580f87974bb6d Related tdf#154769: XML form, detect misformed year/month/day It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Have tested date, datetime and time. Date works as expected. Time and DateTime will also accept times with 24:00:00. Isn't this a wrong behavior? I could input 2023-05-31T24:00:00 and it will be shown in a formatted field as 01.06.23 00:00 (German format) I could input 24:00 and it will be shown in a time field as 23:59 Might be better to set maximum <24:00:00 and not <=24:00:00
(In reply to Robert Großkopf from comment #10) > Have tested date, datetime and time. > Date works as expected. > > Time and DateTime will also accept times with 24:00:00. Isn't this a wrong > behavior? > I could input > 2023-05-31T24:00:00 > and it will be shown in a formatted field as > 01.06.23 00:00 (German format) > I could input > 24:00 > and it will be shown in a time field as > 23:59 > > Might be better to set maximum <24:00:00 and not <=24:00:00 According to https://en.wikipedia.org/wiki/ISO_8601, sometimes "24:00:00" was removed, sometimes added but the last move was to keep it: "An amendment was published in October 2022 featuring minor technical clarifications and attempts to remove ambiguities in definitions. The most significant change, however, was the reintroduction of the "24:00:00" format to refer to the instant at the end of a calendar day". Also, if we want to change this, I suppose utl::ISO8601parseTime must be change, that means it will impact more than XML forms. Eike: any thoughts here? (just noticed I quoted you in some comments without having put you in cc, dumb me!!! :-)) Now about the specific behaviors you indicated, I must recognize I don't know if it's wrong or not. The first one seems ok 2023-05-31T24:00:00 corresponds to 2023-05-31 + 24 hours, so the next day. I'm more skeptical about 24:00 transformed into 23:59, to keep the login of the first one, I would have changed into 00:00.
(In reply to Robert Großkopf from comment #8) > ... > So both boxes will work well if they don't appear in red. Ok great! Now let's wait a bit for some feedback about your last comment concerning 24:00:00 process in LO
24:00:00 midnight and 00:00:00 midnight refer to the same moment in time, with the only difference that 24:00:00 _semantically_ makes it belong to the end of the day. On a timeline there is no difference at all. We also have no context at a floating point number. 2023-05-31T24:00:00 resulting in 2023-06-01T00:00:00 is correct. If a form application needs the context of "24:00:00 end of day" then it must somehow handle that and internally on a time-scale treat 2023-05-31T24:00:00 as 2023-05-31T23:59:59,999 or whatever precision it may need. Presenting an input of 24:00 in this context as 23:59 looks ok to me, but of course it depends on the application whether it needs to handle the _exact_ duration of 24 hours. If we changed utl::ISO8601parseTime() to accept 24:00:00 (which it currently doesn't though xforms lcl_toUNOTime() assumes it would) then it should only do so on demand. The caller would have to handle whether the result should be 23:59:59,999 or 24:00 on the same day or next day 00:00.
Thank you Eike for your detailed feedback! Let's put this one to FIXED then. Robert: don't hesitate to create a new bugtracker if you think 24:00 should be dealt specifically.
(In reply to Julien Nabet from comment #14) > Thank you Eike for your detailed feedback! > > Let's put this one to FIXED then. > > Robert: don't hesitate to create a new bugtracker if you think 24:00 should > be dealt specifically. Hi Julien, one datatype is missing: "Hyperlink". I don't know how this one could be tested at all, but it is a datatype in the GUI and also in xmlschema: https://www.w3.org/TR/xmlschema11-2/#anyURI
(In reply to Robert Großkopf from comment #15) > ... > one datatype is missing: "Hyperlink". I don't know how this one could be > tested at all, but it is a datatype in the GUI and also in xmlschema: > https://www.w3.org/TR/xmlschema11-2/#anyURI I gave a try with https://gerrit.libreoffice.org/c/core/+/150822 but here too, I'm not sure about this one. At least one thing I didn't succeed is how to implement "collapse" notion of white spaces for anyURI instead of "preserve" for a usual string.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d0ecc80ca4ab5fd19bf26dff8dc748c87444c024 Related tdf#154769: XML forms add anyURI/hyperlink datatype It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Have downloaded the current daily build (2023-04-27, rpm, LO 7.6.0.0 Alpha 0) Seems all data types are detected right now and shown as wrong type, if I type wrong content. I will set this one to VERIFIED. Many Thanks!
Have seen I could input something like '000001' for a Day, same behavior for Month and Years. Could the characters be limited? 2 for Day and Month, 4 for Year?
(In reply to Robert Großkopf from comment #19) > Have seen I could input something like '000001' for a Day, same behavior for > Month and Years. Could the characters be limited? 2 for Day and Month, 4 for > Year? eg for day, if I type '00001' for day in text control, special control will display '1'. What should be done here? Special control would be '1' but both should be red because textcontrol should have only '01' or '1'? Another subject, just to know if we should open a new bugtracker, in "Data" tab, the label of last fields is gray whereas the input at right can be modified. Either label should stay gray and the input disabled or label shouldn't be gray, what do you think?
(In reply to Julien Nabet from comment #20) > (In reply to Robert Großkopf from comment #19) > > Have seen I could input something like '000001' for a Day, same behavior for > > Month and Years. Could the characters be limited? 2 for Day and Month, 4 for > > Year? > > eg for day, if I type '00001' for day in text control, special control will > display '1'. That's right. Best for input would be the formatted field. There it is impossible to add more than defined 0. If you use textboxes it is possible to save 00001, because the xml-Data will all be saved as a string. > What should be done here? Special control would be '1' but both should be > red because textcontrol should have only '01' or '1'? All entries with more then 2 characters are wrong entries. Nobody would write a date like 2023-000005-000000001 but 2023-05-01 and will also read well 2023-5-1 > > Another subject, just to know if we should open a new bugtracker, in "Data" > tab, the label of last fields is gray whereas the input at right can be > modified. Don't know what you are writing about. Could you please send me a screenshot? So I will see if I have to open a new bug … Many thanks Robert
Created attachment 187027 [details] screenshot Here's a screenshot. The last label not grayed is "Data type" then "Whitespaces", "Pattern", etc are gray, whereas the input of each at right isn't gray. For the rest, you mean that 1) a control should be done also on the text box and not only on the formatted field by taking into account the associated datatype 2) if a text box contains something wrong (respecting to the datatype associated, eg: gday), textbox and formatted field (both) should be in red ? eg: a textbox associated to "day", which contains "001", even if the formatted field would contain "1", both would be in red Just wonder what's the difference then between formatted field and text control if both behave the same way (at least for controls). Is there any kind of official documentation about this?
(In reply to Julien Nabet from comment #22) > Created attachment 187027 [details] > screenshot > > Here's a screenshot. > The last label not grayed is "Data type" then "Whitespaces", "Pattern", etc > are gray, whereas the input of each at right isn't gray. You are right: If you could chose content in the fields the labels shouldn't appear greyed out. > > For the rest, you mean that > 1) a control should be done also on the text box and not only on the > formatted field by taking into account the associated datatype Yes, because: The content will always be saved as characters, nothing else. So there might be persons, who will create the whole form with text boxes. And it will work, but day, month and years with too many leading 0 will look a little bit stupid. > 2) if a text box contains something wrong (respecting to the datatype > associated, eg: gday), textbox and formatted field (both) should be in red > ? Yes, it works at this moment with all the changes you made. Only the leading 0 irritates. > > Just wonder what's the difference then between formatted field and text > control if both behave the same way (at least for controls). Ok, the better way to input data will be the formatted control. You could input data, date time and numbers with you local format and local decimal separator. You can't do this with a text control. Also you could format as currency - couldn't work in a text control. > Is there any kind of official documentation about this? No, there isn't. Some short descriptions. So the documentation is my part. I'm just creating it new (have created for LO 6.1) and will try all this by try and error…
(In reply to Julien Nabet from comment #22) > Created attachment 187027 [details] > screenshot > > Here's a screenshot. > The last label not grayed is "Data type" then "Whitespaces", "Pattern", etc > are gray, whereas the input of each at right isn't gray. Have had a look now to this one: The labels are greyed out, but the input is allowed. That is wrong. You are changing the datatype for you form document with this entries. This should only be possible for new data types you could add by pressing the button beneath the data type. Appears here as '+…' but at your screenshot only as '…'. So all fields for new entries should only be enabled when a new datatype will be created. They shouldn't be enabled for any of the default data types. Seems to be a very old bug. Should I file a new bug for this?
(In reply to Robert Großkopf from comment #24) > ... > Should I file a new bug for this? I didn't check if there's already one but if it's not the case, yes it would be relevant.
(In reply to Robert Großkopf from comment #23) > > 2) if a text box contains something wrong (respecting to the datatype > > associated, eg: gday), textbox and formatted field (both) should be in red > > ? > > Yes, it works at this moment with all the changes you made. Only the leading > 0 irritates. > ... I gave a try with https://gerrit.libreoffice.org/c/core/+/151238 but for date and datetime, I've changed "ISO8601parseDate", a function in "unotools" so which has a larger impact than just XML Form. With this patch, if a year value is longer than 4 or a month value is longer than 2 or a day value is longer than 2, the textbox is in red, formatted field too and the formatted field has no value (the textbox keeps its wrong value). I gave a try with time and time part of datetime, it seems already ok, typing "001:01:01" or "01:001:01" or "01:01:001" will display red. Another bug I saw is formatted field for date displays 31/12/2200 max. The datetime hasn't this pb since the year part is on 2 digits but if you put 0 for year, there's an assertion: #5 0x00007fe6cd431df2 in __GI___assert_fail (assertion=0x7fe6cc10249a "nYear != 0", file=0x7fe6cc0e0213 "/home/julien/lo/libreoffice/include/comphelper/date.hxx", line=39, function=0x7fe6cc0fd65e "sal_Int32 comphelper::date::YearToDays(sal_Int16)") at ./assert/assert.c:101 #6 0x00007fe6cc3a796d in comphelper::date::YearToDays(short) (nYear=0) at include/comphelper/date.hxx:39 #7 0x00007fe6cc3a7776 in comphelper::date::convertDateToDays(unsigned short, unsigned short, short) (nDay=31, nMonth=5, nYear=0) at include/comphelper/date.hxx:84 #8 0x00007fe6cc3a7157 in comphelper::date::convertDateToDaysNormalizing(unsigned short, unsigned short, short) (nDay=31, nMonth=5, nYear=0) at /home/julien/lo/libreoffice/comphelper/source/misc/date.cxx:55 #9 0x00007fe6bf49ca6c in dbtools::implRelativeToAbsoluteNull(com::sun::star::util::Date const&) (_rDate=...) at /home/julien/lo/libreoffice/connectivity/source/commontools/dbconversion.cxx:170 #10 0x00007fe6bf49c9d9 in dbtools::DBTypeConversion::toDays(com::sun::star::util::Date const&, com::sun::star::util::Date const&) (_rVal=..., _rNullDate=...) at /home/julien/lo/libreoffice/connectivity/source/commontools/dbconversion.cxx:175 #11 0x00007fe6bf49cb2d in dbtools::DBTypeConversion::toDouble(com::sun::star::util::DateTime const&, com::sun::star::util::Date const&) (_rVal=..., _rNullDate=...) at /home/julien/lo/libreoffice/connectivity/source/commontools/dbconversion.cxx:193 #12 0x00007fe690e2dd61 in frm::OFormattedModel::translateExternalValueToControlValue(com::sun::star::uno::Any const&) const (this=0x5619f8555330, _rExternalValue=uno::Any("com.sun.star.util.DateTime": ...)) at /home/julien/lo/libreoffice/forms/source/component/FormattedField.cxx:888 #13 0x00007fe690e4d917 in frm::OBoundControlModel::transferExternalValueToControl(frm::ControlModelLock&) (this=0x5619f8555330, _rInstanceLock=...) at /home/julien/lo/libreoffice/forms/source/component/FormComponent.cxx:2558 #14 0x00007fe690e4e075 in frm::OBoundControlModel::modified(com::sun::star::lang::EventObject const&) (this=0x5619f8555330, _rEvent=...) at /home/julien/lo/libreoffice/forms/source/component/FormComponent.cxx:2523 #15 0x00007fe690fd2dca in lcl_modified(com::sun::star::uno::Reference<com::sun::star::util::XModifyListener> const&, com::sun::star::uno::Reference<com::sun::star::uno::XInterface> const&) (xListener=uno::Reference to (frm::OFormattedModel *) 0x5619f85555e0, xSource=uno::Reference to (xforms::Binding *) 0x5619f4e60110) at /home/julien/lo/libreoffice/forms/source/xforms/binding.cxx:602 what a mess!
(In reply to Julien Nabet from comment #26) > I gave a try with https://gerrit.libreoffice.org/c/core/+/151238 but for > date and datetime, I've changed "ISO8601parseDate", a function in "unotools" > so which has a larger impact than just XML Form. Luckily it's not used anywhere else, and shouldn't.
If this is too complicated to set the right length of the string: It works with special fields like the formatted field. So I will write this down in documentation for xml form documents.
(In reply to Eike Rathke from comment #27) > (In reply to Julien Nabet from comment #26) > > I gave a try with https://gerrit.libreoffice.org/c/core/+/151238 but for > > date and datetime, I've changed "ISO8601parseDate", a function in "unotools" > > so which has a larger impact than just XML Form. > Luckily it's not used anywhere else, and shouldn't. As indicated in https://gerrit.libreoffice.org/c/core/+/151238: "ISO8601parseTime is used in forms and connectivity but is also used in ISO8601parseDateTime in unotools part (and declared as UNOTOOLS_DLLPUBLIC in include/unotools/)". It would be great we have only 1 central class to deal with date, datetime, time or perhaps 1 class per ISO if there are several ISOs.
As written there, I overlooked ISO8601parseDateTime() that is called at various places. I'm not happy with this implementation that limits years to 0..9999 and also accepts year 0 (which implies ISO 8601:2000 instead of ISO 8601:1998 Draft that XML Schema Part 2 uses; doing this here may actually be wrong) but luckily for the actual ODF content there's sax::Converter::convertDateTime(). Some documentation for the header file's declarations what the limitations of this implementation are would be welcome. It may be unwittingly used. It might also be necessary to check places where it is called if that was really the intention.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c4aa51f497db8b659cc66402dea7be88f57c2580 Related tdf#154769: XML Form add limits of length value for some datatype It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Robert: considering the length of this bugtracker, I suppose we should create a new one for dates management in XML form.