| Age | Commit message (Collapse) | Author |
|---|
|
|
|
incorrect event: user_change_password_form
corrected event: user_change_email_form
|
|
|
|
|
|
|
|
|
|
|
|
|
|
by the following rules:
1) An initial dialog or panel load can take either HTML or JSON, but
the mime type must accurately reflect its payload.
2) dialog form submits can handle a pure HTML response, but the mime
type must also be correct. This properly resolves the problem
where the reauth code gets a JSON response first from the reauth
code, and then an HTML response when you reauth and continue on to
a given form -- try it out with Admin > Settings > Advanced.
3) All JSON replies must set the mime type correctly. The json::reply
convenience function does this for us.
4) By default, any HTML content sent back in the JSON response should be
in the "html" field, no longer the "form" field.
The combination of these allows us to stop doing boilerplate code like
this in our controllers:
// Print our view, JSON encoded
json::reply(array("form" => (string) $view));
instead, controllers can just return HTML, eg:
// Print our view
print $view;
That's much more intuitive for developers.
|
|
|
|
dialog. Convert all the controllers
that create the data to go into a dialog to return the html as part of a json object.
|
|
"invalid_password" to remove ambiguity.
|
|
|
|
choice.
|
|
Includes fixes for user forms as well (edit user / email / password).
|
|
active authentication every 20 minutes to access the admin area.
Also renaming auth::validate_too_many_failed_password_changes to validate_too_many_failed_auth_attempts since it's used in this generalized way in 3 places now.
|
|
|
|
separate from a successful or failed login.
1) Rename user_login_failed event to user_authenticate_failed
2) Rename failed_logins table to failed_auth (bump Gallery module to
v27 to rename the table)
3) auth::too_many_failed_logins -> auth::too_many_failures
4) auth::record_failed_auth_attempts -> auth::record_failed_attempts
auth::clear_failed_auth_attempts -> auth::clear_failed_attempts
|
|
account's email address.
Still leaving the user/group admin page wide open though.
|
|
|
|
Fixes ticket #585.
Separate out the password change form from the regular edit user form.
Require the old password to enter a new one. While I'm at it, roll
the password strength javascript into a Form_Script element so that we
can get rid of the old view (which incidentally fixes a bug where the
password strength meter would go away on form errors).
|
|
|
|
Fixes ticket #995.
|
|
|
|
|
|
|
|
|
|
model based validation.
|
|
|
|
|
|
the advance settings.
|
|
Conflicts:
modules/server_add/helpers/server_add_theme.php
|
|
|
|
Create a helper class called identity to simplify call the Identity Provider. Move the contents of MY_Session.php to the new helper class and remove the MY_Session class
|
|
MY_Session class to provide the user state changes in the session and a login.php helper that has the login form.
|
|
redundant code in the user module and remove references to the Identity helper from the user module as the user module should be able to access things directly. Simplify the get_user_list api method to just accept an array of ids to return user objects for.
|
|
and group.php. Tried creating a identity helper, but the helper identity.php was confused with the library Identity.php. So got around this by making the methods on Identity static and calling the instance within the static methods. Also temporarily moved the user.php and group.php back into the user module.
|
|
module. The premise is that the plugable user module will provide the update screens if the user backend supports updates.
|
|
|
|
|
|
our approach to restfulness is that it assumes that the resource will be found in the gallery database. It may well be there, but in the case of using plugable drivers for users management, there are no guarantees that it is in our database or it could be in a ldap directory. So it was just easier to remove the restfulness and just call user::lookup instead.
(cherry picked from commit b3211cb2a8282556d410c91771baeb764d47ed10)
|
|
|
|
user_add_form_admin admin adding a user
user_edit_form_admin admin editing a user
user_add_form_admin_completed successfully added a user (admin)
user_edit_form user editing their own settings
user_edit_form_completed successfully edited a user (admin and user editing own settings)
|
|
Fixes ticket #363.
|
|
|
|
1) Allow admins to edit the admin bit of other admins
2) Don't allow admins to delete themselves (partial fix for ticket #213)
3) Inline user::update(). Don't do form processing in helper methods!
4) Inline user::_get_edit_form() so that we can treat edit forms differently.
Trying to hard to make common functions makes for weird edge cases.
|
|
1) create common update function so processing consistent between the
user edit and admin edit.
2) created common private helper function to build the user edit form
the same way.
So a user can now change their user name if the new one doesn't exist.
|
|
|
|
|
|
|
