| Age | Commit message (Collapse) | Author |
|---|
|
guess how to send the user back. Instead, proxy the originating item
id through the edit forms so that we can tell exactly what page we
were on when we began editing. If we were viewing the item, then
redirect to its new url (in case it changed) to fix ticket #745. But
if we were viewing some other item, then just stay on the current page
to fix #940.
The page_type approach didn't work because you'd have the same
"collection" page_type when doing a context menu edit for an album.
|
|
|
|
|
|
1) The new default route is "albums", and Albums_Controller::index() does the right thing
2) Items_Controller redirects to the appropriate specific controller
3) All item controllers now have show() instead of _show(), so that
the routing code in url::parse_url() can get to it. But that code is protected against
receiving bogus requests.
|
|
|
|
where clauses and adds them to the existing query. Update all
existing queries that take an additional where clause to use it.
|
|
Convert all open_paren() calls to and_open() or or_open() as appropriate.
|
|
Partial fix for ticket #917
|
|
types, and a subtype for specifics. Currently the top level bucket
collection, item, other
Here are the core subtypes so far:
collection: album, search, tag
item: movie, photo
other: login, reset, comment-fragment, comment
It's legal to create new page_subtypes whenever you want. Use the
appropriate page_type to get the coarse grain behavior that you want.
|
|
Was also able to remove the sub-select from the calculation of the current position as we already have the child item containing the sort column value.
Also added a where clause that ignores albums to the get_position, children and children_count method calls in photos.php and movies.php
|
|
from the context menu or from its photo or album page.
Fixes ticket #745. Thanks to jankoprowski for the referrer approach.
|
|
part of the response. This insures that if the internet address changes, then
the page will reload properly.
|
|
If you can change the extension, then you can alter the way the server
handles the file, which is a security problem. So for example, you
can change a .JPG to a .PHP and then if you put some malicious PHP
code in the EXIF data, you can get the server to execute
it. Vulnerability is low because only users who have edit permissions
could do this.
Fixes ticket #846
|
|
|
|
This is not currently necessary (nor is it a security hole) because we
don't constrain permissions at the child level in the core, but it
makes our security audits easier and will enable the scenario where
somebody writes a module to add per-photo permissions.
|
|
row has a null value in the sort field. Fix for #627
Note: this changes get_position() to take an Item_Model instead of an id!
|
|
we're not relying on overriding url::site() to do tricks around item
urls. This means that you won't get item urls by doing
url::site("albums/37"), for example, but it also means that we won't
get pretty urls where we don't expect them (like in the action of a
<form> element).
Incidentally, this will help us move over to using the slug format
because if you've got a bad character in a url, the edit forms will
now work on it since they'll be id based.
|
|
2. Fix up an issue where we were crashing if there were no conflicting rows
3. Amend Item_Model so that if you change the slug, it flushes the cache
for all children
|
|
validation for the fields.
|
|
|
|
|
|
SafeString::purify().
Removing any p::clean() calls for arguments to t() and t2() since their args are wrapped in a SafeString anyway.
|
|
tag_event:item_edit_form to use the new Form_Script library to inject
script into a form.
Signed-off-by: Tim Almdal <tnalmdal@shaw.ca>
|
|
This required putting a wrapper view around the forms and passing
this view as the parameter to the item_edit_form event. The view
contains a $script variable that the modules can add script to be
included in the form html when rendered as part of the ajax response.
|
|
good pattern for allowing modules to add their own hooks to item forms!
1) Album, photo and movie forms now all use edit_item as the group and
we publish item_edit_form and item_edit_form_completed events which
makes it much easier in the module to handle all events. They can
still differentiate based on $item->type if they want to.
2) Added tag::clear_all() and tag::compact() functions which takes the
place of hiwilson's tag::update() function and is now used in
tag_event::item_delete(). This provides a simple API that allows
us to have a lot less event handling code. It's less efficient
than what hiwilson was doing before in that it will delete and
re-add tags, but if that ever turns out to be a performance issue
we can do something about it then.
|
|
functionality. (3)support multi-word tagging.
|
|
related events from within the model handling code. The only
exception to this currently is item_created which is challenging
because we have to save the item using ORM_MPTT::add_to_parent()
before the object itself is fully set up. When we get that down to
one call to save() we can publish that event from within the model
also.
|
|
1) The item_updated event no longer takes the old and new items.
Instead we overload ORM to track the original data and make
that available via the item. This will allow us to move event
publishing down into the API methods which in turn will give us
more stability since we won't require each controller to remember
to do it.
2) ORM class now tracks the original values. It doesn't track
the original relationships (no need for that, yet)
3) Added new events:
item_deleted
group_deleted
user_deleted
|
|
using the checklist in ticket #385.
|
|
grandparent id. Oops. This caused navigation from photo back up to
album to be broken.
Also update Photos_Controller to use the active sort order.. it was
still hardcoded to use the id. It's more efficient now, yay.
Fixes ticket #340.
|
|
and verifying user permissions, but there are several above-the-bar
changes:
1) Server add is now only available to admins. This is a hard
requirement because we have to limit server access (eg:
server_add::children) to a user subset and the current permission
model doesn't include that. Easiest fix is to restrict to admins.
Got rid of the server_add permission.
2) We now know check permissions at every level, which means in
controllers AND in helpers. This "belt and suspenders" approach will
give us defense in depth in case we overlook it in one area.
3) We now do CSRF checking in every controller method that changes the
code, in addition to the Forge auto-check. Again, defense in depth
and it makes scanning the code for security much simpler.
4) Moved Simple_Uploader_Controller::convert_filename_to_title to
item:convert_filename_to_title
5) Fixed a bug in sending notification emails.
6) Fixed the Organize code to verify that you only have access to your
own tasks. In general, added permission checks to organize which had
pretty much no validation code.
I did my best to verify every feature that I touched.
|
|
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
|
