| Age | Commit message (Collapse) | Author |
|---|
|
wind up with weird url doubling effects. Fixes ticket #1342.
|
|
the default email address for admin to be unknown@unknown.com and when
that happens the gallery_event::user_updated() event listener fires
and sets the default values. This is hard to work around, so let's
just roll with it and use unknown@unknown.com as our default placeholder.
So now, if an admin sets their email address and the current values
are unknown@unknown.com we adopt the admin's email address for the
site's mail_from/reply_to fields.
|
|
|
|
reply-to addresses to an empty string. The first time the user model is saved, set the sendmail from and reply-to addresses. Requires an update to gallery version 38.
|
|
update the sendmail from and reply_to fields in advanced settings. Also change this if the identity provider has changed.
|
|
a call to Organize with the appropriate album open. I have not yet
figured out how to get the SWF code to highlight the active image, but
that's coming. Partial fix for #1204.
|
|
Refactor the rotate code in Quick_Controller to replace the data file,
and then have gallery_event::item_updated_data_file() pick up after
the change is saved, rebuild the image and handle album covers. This
is much more portable than before and it will allow any mechanism (eg:
REST) to replace the source image.
|
|
main site, and didn't actually log you out.
|
|
the admin dashboard.
Fixes ticket #1201
|
|
this will just replace the controller. This makes overriding that
much easier in the future.
|
|
the album cover.
Fixes ticket #1196.
|
|
deletes in bulk. This lets us avoid the problem where we continually
choose and delete album covers which makes deletes really slow. It
probably also avoids huge amounts of notification emails (untested).
Fixes ticket #1190.
|
|
also pass it along in the form creation code. This fixes ticket #1183.
|
|
as appropriate for the item type. Fixes ticket #1175.
|
|
items that may have it in the album_cover_item_id column. Fixes ticket #1172.
|
|
uploader.
|
|
reauth code.
|
|
it requires us to reproduce a bunch of complex routing logic.
Instead, just have the logout link generating code generate a link
that's visible to guests.
|
|
ticket #1157. Thanks to psvo.
|
|
- Pass the CSS selector of the active image in as an arg to site_menu
so that quick operations know what they're operating on.
- Change the ids from g-{photo,movie}-id to the generic g-item-id
- Initialize ajax handlers for site menu on the photo and movie page
- Drop the movie context menu, it's now in the site menu
|
|
|
|
the site_menu.
|
|
deleted. Fixes ticket #1083.
|
|
|
|
|
|
|
|
|
|
This reverts commit 5ddd7c9677b644396981de7df8176a3b168ffe21.
|
|
Adds a core.internal_cache_read_only config variable to Kohana's internals.
Kohana's internal_cache for find_file wasn't working in Gallery because the cache would be emptied on each request after reading it from disk and before most lookups would run.
1. Bootstrap sets initial core.modules (= include path): forge, kohana23_compat, gallery.
2. Kohana::setup() loads find_file cache from disk.
3. Gallery loads list of active modules and themes, and updates the core.modules value (=include path), which forces the internal find_file cache to be empties (which makes sense).
4. Request processing starts, and thus 80% of all Kohana::find_file() triggered is_file() invocations start off with an empty find_file cache.
In the case of my small Gallery installation, we're talking about 3100 is_file() invocations per request with or without internal_cache enabled. With this fix, this number is down to 800 invocations.
The basic idea is that we treat the cache as read only and don't write any (possibly dirty) values to it in memory until we're sure that the include path won't change later on in the request processing. Once we know the list of active modules and themes, we can update core.modules and finally flip the read-only state of the cache and start writing to it.
|
|
"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()
|
|
This reverts commit 409121942590e12692eaf4e6e9e8b71bfe5ed60c.
|
|
Also fixed a UI bug: No longer showing the edit user buttons to admins in the profile view (to be consistent with the requirements in the controller).
|
|
attributes, use & not &)
|
|
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
|
|
|
|
minute after there have been 5 consecutive failed login attempts.
Fix for ticket #589.
|
|
quick menu knows where to send you after the action is done.
|
|
|
|
Also clean the subject line and email message body of the contact user email.
|
|
Conflicts:
modules/gallery/tests/Access_Helper_Test.php
|
|
of locale tags to be consistent with the user edit form.
|
|
Conflicts:
modules/gallery/libraries/MY_ORM.php
|
|
The show_user_profile is used to provide content to the user profile page. Add the list of the users comments to the profile page.
|
|
user in messages or pages.
Partial fix for ticket #889 and a fix for #931.
|
|
Conflicts:
modules/gallery/tests/xss_data.txt
|
|
user menu. Since the information displayed is identical in both admin and
theme views, it makes sense to combine the generation to it is done in a common
location.
|
|
|
|
providers are installed in the admin module screen.
|
