- πΊπΈUnited States trackleft2 Tucson, AZ πΊπΈ
Is this still an issue in the 2.1.x version?
When logged in as a user with the 'set user expiration' permission granted, applying updates to a user through any method other than the user forms, has an an-wanted side effect of deleting the users expiration date field.
This is because the '_user_expire_save' function relies on the 'user_expiration' and 'user_expiration_date' properties being set on the account object, which is only the case when the user is being updated from the user forms. When using a module such as Devel of Views Bulk Operations to edit a set of users, the above properties are not defined, which causes 'user_expire_set_expiration' function to be called with no timestamp, reseting the expiry date.
The following edit on line 166 should fix this problem:
if ((isset($account->user_expiration) && $account->user_expiration) || (isset($account->expiration) && is_numeric(account->expiration))) {
Adding an OR condition checking whether an 'expiration' property is defined and numeric, allowing for an existing user to be successfully saved on update.
With more time, an ideal solution would be to avoid updating the expiration date on a user update operation unless the user's expiry date has been changed.
Active
1.5
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Is this still an issue in the 2.1.x version?