Menu

#854 The flag <is_null_allowed> is not working for AttributeDate[Time]

closed
Core/OQL
Critical
2.0.1
defect
2018-02-19
2013-12-11
Devin M.
No

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.

Discussion

  • Romain Quetiez

    Romain Quetiez - 2014-01-06
    • owner changed from etaloc to romainq
    • component changed from Data model to Core/OQL

    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).

     
  • Denis

    Denis - 2014-03-12
    • milestone set to Candidates for next release
     
  • Denis

    Denis - 2014-05-28
    • milestone changed from Candidates for next release to 2.0.3
     
  • Romain Quetiez

    Romain Quetiez - 2014-05-28
    • description modified (diff)
    • summary changed from The flag <is_null_allowed> is not working for AttributeDateTime to The flag <is_null_allowed> is not working for AttributeDate[Time]

    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

    • Internal classes: AsyncTask, !DBProperty, !CMDBChange, Event, SynchroReplica, Attachment
    • Business classes / 2.x: WorkOrder (as said in the initial bug report)
    • Business classes / 1.x: Attachment, Ticket
    • Custom modules...

    Requires a discussion...

     
  • Romain Quetiez

    Romain Quetiez - 2014-06-02

    Decision: GO, and maximize the stability by changing the setting everywhere into "Null allowed"

     
  • Romain Quetiez

    Romain Quetiez - 2014-06-02
    • status changed from new to closed
    • resolution set to fixed

    Fixed in trunk as [3185]

    I have also changed the way the default value is handled:

    • setting a default value now has an effect, wether "null" is allowed or not.
    • the default value can be a date or an interval specification (relative to the time at which the default value is computed) as understood by the PHP function strtotime. Allowed time specifications can be for instance : 'next Saturday', '+3 days', '-1 month', 'now', '10 September 2014', 'yesterday 14:00', 'Monday this week' (see relative time format)

    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).

     
  • Romain Quetiez

    Romain Quetiez - 2014-06-03

    Replying to romainq:

    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).

    Will be adressed in #938

     
  • Romain Quetiez

    Romain Quetiez - 2014-07-09
    • labels: AttributeDateTime,, null, flag --> AttributeDateTime, null, flag
    • Description has changed:

    Diff:

    
    
    • status: closed --> reopened
    • Milestone: 2.0.3 --> Candidates for next release
    • Resolution: fixed -->
    • Priority: major --> Critical
     
  • Denis

    Denis - 2015-02-18
    • Milestone: Candidates for next release --> 2.2.0
     
  • Romain Quetiez

    Romain Quetiez - 2015-09-23
    • Milestone: 2.2.0 --> Next release
     
  • Romain Quetiez

    Romain Quetiez - 2016-01-19
    • Milestone: Next release --> Candidates for next release
     
  • Vincent @ Combodo

    • status: reopened --> to-be-reviewed
     
  • Vincent @ Combodo

    • status: to-be-reviewed --> closed
     
  • Vincent @ Combodo

    It must have been solved in some previous versions as this is no more the case in version 2.3

     

Log in to post a comment.