item::move(source, target) helper when the parent member has changed.
Using the move method insures that names and slugs that could conflict
in the target album are resolved properly. Changed the item::move
method so it returns a message to be displayed if the caller chooses.
And changed the move controller to display the message returned by the
move if the item name was renamed as part of the move."
Rolling this back for a couple of reasons:
1) Bug in move.php ("message.info" is not a function name)
2) Having the message come back from the API call as a side-effect is
sloppy. We should find a cleaner way to do this checking.
3) having item::move() call save() on any changed values in the ORM
is counter-intuitive. Move should move, save should save.
I think the right approach here is to roll the move() code properly into
save().
This reverts commit 2492280cc0.
method, which encapsulates saving an item and handling name and slug
conflicts. Call this instead of doing a save directly."
Rolled this back because it fails KISS. We already have an API for
saving models with Item_Model::save() that's consistent with all of
our other model code. Adding a new way to save items is confusing and
inconsistent.
This reverts commit 9504f71efc.
1) Don't call ORM_MPTT::move_to() directly. Use the new
model-based-validation approach of changing the parent_id and saving.
2) Item_Model::parent() can return null; check for it.
now only Albums_Controller::update() supports the pattern. All
form and controller based validation happening when editing an
album has been moved over.
Model based validation means that our REST controllers share the
same validation as web controllers. We'll have consistency
enforced at the model level, which is a Good Thing.
The basic pattern is now:
1) Rules are in the model
2) ORM::validate() (which is called by ORM::save() but you can
call it directly, too) checks the model for all the rules and
throws an ORM_Validation_Exception if there are failures
3) Actions are no longer taken when you call Item_Model::__set().
Instead, they're all queued up and executed when you call
Item_Model::save().
Notes:
- item::validate_xxx() functions are now in Item_Model::
- We still call $form->validate() because the form can have
rules (and forms triggered by events will likely continue to
have rules.
choosing a random image is essentially a function on an item collection.
Also implemented a bunch of other query filters for item collections.
Created item::random_query() as a way of generating a reasonable
starting point for random queries.
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.
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.
component for that given item. Album hierarchies are represented by
nested slugs. By default, we convert the filename to a slug when you
create an album, photo or movie.
old ORM relationships from hanging around, which was causing problems
when doing MPTT manipulations (resulting in incorrect permission
propagation-- very bad!)
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.
