Due to the recent change of translations to transifex, some
locales changed their names, which prompted a fix to
i18n::get_available_translations() (see 00ffe7294).
This caused a regression where short locales are determined
from the YAML file names (e.g. "en"), but weren't matched up
with fully qualified locales from get_available_translations() (e.g. "en_US").
Since this list is used in the admin/myprofile dropdown for the Member.Locale value,
it didn't match up with any entries and defaulted to the first one ("Africaans").
Note that the behaviour of admin/myprofile is still a bit weird:
It defaults the locale on new members to the one set for the current administrator.
So if a site defaults to en_US in _config.php, but the admin happens to view
his backend in de_DE, all members he creates default to de_DE as well.
Thanks to @tractorcow for contributing and peer reviewing!
If there's validation errors in the ChangePasswordForm, the user
is taken to the BackURL because redirectBack() will go there if
it's set.
Instead of this, just redirect back to the "changepassword" action
on the Security controller.
Running Members() on a Group that has no Db record causes UnsavedRelationList to be returned by DirectMembers() which in turn causes alterDataQuery() to fall over when called on an UnsavedRelationList. This just adds a simple check to prevent it.
The call to Members() includes members of child groups, which was causing any members added through the grid field to be added to the child groups as well.
With this modification we can use Object::useCustomClass() to create a
custom ChangePasswordForm form:
Object::useCustomClass('ChangePasswordForm',
'CustomChangePasswordForm');
permissionDenied only works if Security::permissionFailure() is called when
there's currently no logged in Member. This fixes it so failed attempts
with logged in Member also includes the permissionDenied hook.
In addition, fix an undefined $member variable
It would invalidate this view. Only allow group editing
for new members added to this group (with a group default),
and for members edited through the "root" view.
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).
Due to changed return value of DataObject::get(),
the (negated) check always returned false.
This wasn't noticed in 3.0 because Group->canEdit() is rarely
enforced, but does become noticeable in 3.1 where GridField
checks those object-level permissions.
Thanks to @purplespider for reporting!
Sometimes Page_Controller::init() will trigger a redirection. For example, it may redirect to a
canonical URL. In this case, the Security views, which co-opt Page_Controller, need to respect
this.
