This will resolve issues in cases where the site locale may be assigned a value that does not have an explicit translation. E.g. if the locale is en_NZ (and it's appropriate for this to be the assigned locale), Afrikaans will no longer be the default selected locale when creating members. Now en_US is chosen as a better fallback default.
This is a minor ease of use fix that means fewer CMS users can be accidentally created in Afrikaans within NZ based sites.
Test cases included.
Partially reverts b0f38f4990
which broke unit tests relying on the old entity name
in 3.1, where translations and the en.yml master file have been backported to.
Required to save/restore parts of the session information,
which Member nukes indiscriminately on logout.
Specific use case is restoring linkages to temporary databases
on Behat test runs.
Updates the CMS profile page and SecurityAdmin to give developers a few ways to customise the required fields.
Added extension hook updateValidator for getValidator for things like modules to inject required fields to go along with Injector for replacing the entire class for project specific use.
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!
Remove all top/bottom margins from buttons and apply to GridFieldButtonRow component. Ensure that all buttons are added to a suitable GridFieldButtonRow in ModelAdmin, SecurityAdmin and Group.
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.
In 3.0 there was some confusion about whether DataLists and ArrayLists
were mutable or not. If DataLists were immutable, they'd return the result, and your code
would look like
$list = $list->filter(....);
If DataLists were mutable, they'd operate on themselves, returning nothing, and your code
would look like
$list->filter(....);
This makes all DataLists and ArrayList immutable for all _searching_ operations.
Operations on DataList that modify the underlying SQL data store remain mutating.
- These functions no longer mutate the existing object, and if you do not capture the value
returned by them will have no effect:
ArrayList#reverse
ArrayList#sort
ArrayList#filter
ArrayList#exclude
DataList#dataQuery (use DataList#alterDataQuery to modify dataQuery in a safe manner)
DataList#where
DataList#limit
DataList#sort
DataList#addFilter
DataList#applyFilterContext
DataList#innerJoin
DataList#leftJoin
DataList#find
DataList#byIDs
DataList#reverse
- DataList#setDataQueryParam has been added as syntactic sugar around the most common
cause of accessing the dataQuery directly - setting query parameters
- RelationList#setForeignID has been removed. Always use RelationList#forForeignID
when querying, and overload RelationList#foreignIDList when subclassing.
- Relatedly,the protected variable RelationList->foreignID has been removed, as the ID is
now stored on a query parameter. Use RelationList#getForeignID to read it.
Session is not initialized by the time we need to use
the setting in DB::connect(). Cookie values get initialized
automatically for each request.
Tightened name format validation to ensure it can only
be used for temporary databases, rather than switching
the browser session to a different production database.
Encrypting token for secure cookie usage.
Added dev/generatesecuretoken to generate this token.
Not storing in YML config directly because of web access issues.
Stay consistent with main member listing in admin/security,
and de-emphasize their importantce. Having the "link existing"
closer to the actual table is a much stronger UI coupling.
Refactor the code to make it clear the distinction is made between a
plaintext token and a hashed version. Rename fields so it is more
obvious what is being written and what sent out to the user.
This reuses the salt and algorithm from the Member, which are kept
constant throughout the Member lifetime in a normal scenario. If they do
change, users will need to re-request so the hashes can be regenerated.
SecurityAdmin isn't always available for CMS users, as they might
not have permission to view that section. This fixes the problem
with session keep alive by moving the ping to Security/ping, which
is available for all users.
