The following used steps were replaced by the ones
added in this issue:
- I fill the moodle form with
- I fill in with
- I select from
- I select radio button
- I check
- I uncheck
- the field should match
Also removing test for deprecated steps:
- the ASD checkbox should be checked
- the ASD checkbox should not be checked
List of changes:
* New OOP API using PHP namespace \core\session\.
* All handlers now update the sessions table consistently.
* Experimental DB session support in Oracle.
* Full support for session file handler (filesystem locking required).
* New option for alternative session directory.
* Official memcached session handler support.
* Workaround for memcached version with non-functional gc.
* Improved security - forced session id regeneration.
* Improved compatibility with recent PHP releases.
* Fixed borked CSS during install in debug mode.
* Switched to file based sessions in new installs.
* DB session setting disappears if DB does not support sessions.
* DB session setting disappears if session handler specified in config.php.
* Fast purging of sessions used in request only.
* No legacy distinction - file, database and memcached support the same functionality.
* Session handler name included in performance info.
* Fixed user_loggedin and user_loggedout event triggering.
* Other minor bugfixing and improvements.
* Fixed database session segfault if MUC disposed before $DB.
Limitations:
* Session access time is now updated right after session start.
* Support for $CFG->sessionlockloggedinonly was removed.
* First request does not update userid in sessions table.
* The timeouts may break badly if server hosting forces PHP.ini session settings.
* The session GC is a lot slower, we do not rely on external session timeouts.
* There cannot be any hooks triggered at the session write time.
* File and memcached handlers do not support session lock acquire timeouts.
* Some low level PHP session functions can not be used directly in Moodle code.
For example, a user may create a date/time profile field and set the 'Start year'
field to '2012'. Another user, using the Hijri calendar, may edit the name of
this field. They visit the settings page and in this case the date '1/1/2012'
is converted to '7/2/1433' in Hijri. So, the year '1433' is then displayed.
The user then changes the name of this field and saves the form. This is where
the issue occurs, as the date '1/1/1433' is converted into Gregorian, which
converts to the year '26/09/2011', so the year '2011' is saved in the DB, not
'2012'.
The usergetdate function is not only used to display dates, it is also passed
to the function make_timestamp. This means users using another calendar type
other than Gregorian will generate incorrect timestamps which may be saved in
the DB or used to populate the date_selector and date_time_selector elements.
For example, when creating an assignment using another calendar type other
than Gregorian, the mod_form.php file calls $this->apply_admin_defaults()
which uses the function usergetmidnight to set the "Allow submissions from"
date to today's date and the "Due date" field to 7 days in the future. The
usergetmidnight function calls usergetdate which is then passed to
make_timestamp. Since the usergetdate function was using the calendar
type's timestamp_to_date_array function the date being passed to
make_timestamp was not in Gregorian. So, when using the hijri calendar the
year 1434 was being passed which was generating a large negative number as
the timestamp which was then used to populate the date fields.
Renamed the userdate/usergetdate functions in the calendar type to be more
descriptive and made them abstract to ensure developers implement this
functionality in their calendar type.
Also tidied up PHPDocs for these functions.
