trailing ?> and that causes File_Structure_Test to be sad. So instead
use echo and tack on our own newline. But this also requires a
semicolon. Weird, I know but still easier than fixing up the test.
Instead of overwriting Kohana_Exception::handle() (which we were doing
in MY_Kohana_Exception) we instead use their existing template system.
gallery/views/kohana/error.php overrides system/views/kohana/error.php
and is the standard error template for all exceptions. Our version of
error.php figures out the appropriate view based on context (cli,
authenticated admin, guest viewing a 404, guest viewing a system
error) and delegates appropriately. Each delegated view has a narrow
responsibility.
This paves the way for us to add new error views per module. For
example, the rest module will define its own template in
Rest_Exception and then its exceptions can be rendered the way that it
wants (json encoded, in that case).
"display_all" is too coarse, and we should be letting event handlers
make the appropriate decision on what to display and when. This
duplicates some code, but it's now very clear in the event handlers
what's getting shown.
Throw a 404 if we try to view the user profile for a missing user.
The only feature change in this should be that we now display the
name, full name and website for a user to any other registered user,
which makes sense since these are typically public fields.
Don't show any of the edit buttons unless identity::is_writable()
right after initial install so that we're not requiring the user to
re-enter the auto-generated password to change their password and
email.
Fixes ticket #1007
populate the action buttons and other content such as the list of scheduled
tasks."
Leaving this api out of RC1.
This reverts commit 19fee6b5e4.
Conflicts:
modules/gallery/views/admin_maintenance.html.php
a) the edit user form doesn't include the password anymore
b) the new admin would probably also like to change the email, so directing him to the profile page with options to change the pw / email.
Ideally, we'd have a special purpose edit profile page for the install experience, without prompting for the randomly generated password. But that's something for another task.
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.
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).
