RADICORE v1.86.0 released

This version contains some bug fixes and enhancements.

This version contains the following changes:

Database changes:

  • none

Other changes:

  • modified processing of datetime fields so that when the input contains only a date portion a time portion will be appended, and this will be taken from the default value. For start_date fields this will normally be '00:00:00' while for end_date fields this would be '23:59:59'.
  • modified 'std.tree_view2.inc' to set $GLOBALS['mode'] to 'tree' instead of 'read', and to call the 'getExtraData()' method on the outer entity.
  • fixed bug in 'std.multi1.inc' which removed all data except the primary key for a new record after returning from a popup screen.
  • fixed bug in 'std.buttons.xsl' and 'include.xml.php4/5.inc' to make the word 'Selections:' (in the navigation bar) translatable instead of hard-coded.
  • fixed bug in validateSortItem() function so that if the object's table name is at the start of the FROM string it will not look for any alias names for that table.
  • fixed bug in 'std.list2.inc' and 'std.list3.inc' so that when the RESET button is used it will not lose the ORDERBY sequence for the outer entity.
  • added the ability to specify that a particular field in a particular row in a multi-row update area, such as in a MULTI2 pattern, should be set to 'noedit'. This can be achieved by adding the pseudo-column 'rdc_fieldspec['fieldname']' with the value "array('noedit' => 'y')" to the row in question.
  • modified the workflow system to enable a task to set the user_id of a workitem record to a particular value. See FAQ161 for details.
  • fixed bug in 'logon.class.inc' which generated an invalid SQL query when trying to set 'is_disabled' to TRUE after the number of failed logon attempts went over the limit.
  • amended 'std.table.class.inc' so that for the 'insertRecord()' and 'updateRecord()' methods the call to $this->convertTimeZone is now done after the call to '_cm_pre_insertRecord()' and '_cm_pre_updateRecord()' respectively. This is to allow any datetime validation to take place before the values are converted from the client timezone to the server timezone.

Published: 01 September 2014