changed $ to jQuery, because without it the system would generate the following error:
Uncaught TypeError: Property '$' of object [object Window] is not a function
This bug was introduced with the new nested CMS actions
around December 2012, but wasn't noticed until now
because checkAccessAction() would wrongly return TRUE
before the dataFieldByName() check was reached.
At the moment form actions (buttons) have the classes 'action action' as default. This is because the extraClass function adds 'action' and then calls the parent method. The parent then includes the $this->Type() ('action') again.
So I've remove this overloading of extraClass
Pull requests are always on a branch, and this branch
typically is not present on the installer.
This changes means we need to be careful when merging into 3.1
and master, but that's a necessary evil.
This will prevent empty passwords to set the encryption to 'none',
which in turn will store any subsequent password changes in cleartext.
Reproduceable e.g. with ConfirmedPasswordField and setCanBeEmpty(true).
Controller (and subclasses) failed to enforce $allowed_action restrictions
on parent classes if a child class didn't have it explicitly defined.
Controllers which are extended with $allowed_actions (through an Extension)
now deny access to methods defined on the controller, unless this class also has them in its own
$allowed_actions definition.
This will prevent empty passwords to set the encryption to 'none',
which in turn will store any subsequent password changes in cleartext.
Reproduceable e.g. with ConfirmedPasswordField and setCanBeEmpty(true).
Controller (and subclasses) failed to enforce $allowed_action restrictions
on parent classes if a child class didn't have it explicitly defined.
Controllers which are extended with $allowed_actions (through an Extension)
now deny access to methods defined on the controller, unless this class also has them in its own
$allowed_actions definition.
If creating an object using Injector::create() and constructor arguments
are passed through, in some cases where the object being created had a yml
configuration set for it, the passed in constructor arguments weren't being
passed through to the instantiation of the object.
Lazy loading no longer loads fields from the versions table when querying. This could lead to incorrect data being displayed if the data on the object and the version it pointed to did not match.
API methods to allow setting of the context of the query that generated the DataObject on that object (used by the lazy loading mechanism to correctly query the Stage, Live, or Versions tables)
See https://github.com/silverstripe/sapphire/pull/1178 for context.
