old ORM relationships from hanging around, which was causing problems
when doing MPTT manipulations (resulting in incorrect permission
propagation-- very bad!)
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
dig deep enough, but now we form the complete message using t() style
semantics to replace % placeholders with __ style JS placeholders.
Also, stop appending the (completed) text to existing messages.. roll
it together.
1) Stop changing the menu classes in JS, instead allow us to specify
it in the Menu class itself and then set it to be gThumbMenu in Theme_View
2) Move the gThumbMenu init code to the bottom of the $(document).ready() block;
something in there was interfering with it.
action. The expectation is that we're going to reload the page (or
redirect to a new url). If we close the dialog, then we can trigger
the onhover for items we've just deleted causing errors.
Simplify the API while we're at it by getting rid of the no-longer-used
on_success argument to openDialog()
This fixes#528.
Now we don't have checkboxes, but instead we restrict you to selecting
directories and albums from only one level in the hierarchy. This
makes it easier for us to make sure that we properly create the
hierarchy that you want and avoid confusion about what's going to wind
up where.
Modify Server_Add_File_Model to have a parent_id and item_id and then
modify them as we go so that we can build up a tree structure there
*before* we create any items. This makes it much easier to figure out
where a new item is going to go and get rid of a bunch of probably
buggy code in the main task.
