The <is_null_allowed> flag for AttributeDateTime is not working.
In the documentation this flag is marked as Mandatory for the AttributeDateTime. However it did not work when I tried to use it, in fact the toolkit did not read or evaluate this flag at all. Removing the flag or entering invalid values did not trigger any error.
I confirmed that it did not work for the Work Orders either where as part of iTop's default installation the start_date and end_date are marked as compulsory. I am able to create Work Order with blank start_date and end_date.
Hi,
Thank you for the report.
I did a quick investigation: the flag is forced to 'true'. A comment says it is not required anymore, but the code has been left as is until somebody needs the feature... which is now the case. The fix is very simple (remove the override of IsNullAllowed in class AttributeDateTime), but is requires testing as the current implementation is very old (may 2010).
Removing the old code strap has side effects: each date/datetime attribute being currently configured as "null not allowed" will have its behavior changed.
Even worse, the database format is changed to "NOT NULL" which can be incompatible with the current set of data.
About the data migration issue, there are other discussions around the need for forcing the "NOT NULL" at the database level (the application takes care of it and we would like more flexibility for the upgrades).
Here are the classes concerned
Requires a discussion...
Decision: GO, and maximize the stability by changing the setting everywhere into "Null allowed"
Fixed in trunk as [3185]
I have also changed the way the default value is handled:
Still... the default value is NOT TAKEN INTO ACCOUNT when the attribute is edited during a lifecycle transition. If the attribute becomes mandatory, then it is automatically set to "now" during the transition (and it can be changed by the agent).
Replying to romainq:
Will be adressed in #938
We have found out some regressions due to this change. The situation is not as simple as we have imagined... and expected.
Decision: Rollback and postpone the fix to the next (major) release. That one will likely occur by the end of the year (december 2014). Meanwhile we will update the extension modules impacted by the future change.
More information:
Originally, the default value depended on the flag "IsNullAllowed", whereas the fact that it is mandatory or not was hardcoded to true. The fix implemented as [r3185] fixes both issues. To preserve the current behavior, the option IsNullAllowed has been set to 'true' everywhere it used to be 'false'.
BUT...
a. All the modules made outside the iTop developpement mainstream have to be updated separately.
b. The fix [r3185] is not enough to preserve the current behavior: the default value is not set automatically. We have discovered the regression with the class Event: the date of the event must be set to "now". This can be fixed by setting the default value to "now". Anyhow, this emphasizes the need for updating the extension modules. Without the update, it is likely that we will face new bugs. Moreover, that update must be done in a way that ensures a backward compatibility whenever possible (Implement the default value as an OnInsert handler -see the implementation of AsyncTask).
c. To really benefit from the fix, it must be accompanied by the fix for [#938], so that the default value is left to the end-user in the lifecycle. Do we implement that as a new parameter 'gui_default_value' ? This requires further discussion and cannot be done within such a minor release like 2.0.3.
Related
Commit: <Commit _id='5358055aa02bb175d1406271:3185' tree_id='4cedd505010b5c8692ab7593dbcc9592089de99f' committed=I{'date': datetime.datetime(2014, 6, 2, 14, 35, 28, 82000), 'email': '', 'name': 'romainq'} authored=I{'date': datetime.datetime(2014, 6, 2, 14, 35, 28, 82000), 'email': '', 'name': 'romainq'} message='#854 Flag Is null allowed not working on attributes Date and DateTime + the default value is now operant' parent_ids=I['5358055aa02bb175d1406271:3184'] child_ids=I['5358055aa02bb175d1406271:3186'] repo_ids=I[ObjectId('5358055aa02bb175d1406271')]>
Tickets:
#938Committed the rollback as [r3255]
Related
Commit: <Commit _id='5358055aa02bb175d1406271:3255' tree_id='8354a1cf6446cb1e630e2fc496a5b8fcf323ee7b' committed=I{'date': datetime.datetime(2014, 7, 9, 9, 49, 2, 919000), 'email': '', 'name': 'romainq'} authored=I{'date': datetime.datetime(2014, 7, 9, 9, 49, 2, 919000), 'email': '', 'name': 'romainq'} message='#854...ROLLBACK, undoing the commit [3185]. The implementation has been postponed to the next major relase.' parent_ids=I['5358055aa02bb175d1406271:3254'] child_ids=I['5358055aa02bb175d1406271:3256'] repo_ids=I[ObjectId('5358055aa02bb175d1406271')]>
Diff:
It must have been solved in some previous versions as this is no more the case in version 2.3