which sucks, but it's totally unobtrusive because it's a header so
that's ok. Decided that the current version is "3.0" although it will
surely change before the final 3.0 release.
Fixes ticket #1148
just entity.
TESTS ARE NOT UPDATED YET.
- Fix item_rest::get() to maintain the proper sort order, which
requires duplicating some Item_Model code.
- Elide "weight" from the REST version of item
- Adjust the weight of members according to the order they're returned
from the client. You can't add or remove members here, you can only
reorder them.
- Changed the wire protocol to handle more complex values.
Now "entity" and "members" are JSON encoded. The Gallery3
helper does this correctly.
- Changed the wire protocol for tag_item -- now it stores the
tag and item urls in the entity, not as members. This is more
consistent.
- Added missing security for renaming and deleting tags.
- Got rid of vestigial tag_rest::post(). We add/remove tags
via the relationship.
"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()
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
mostly issues around uninitialized variables, calling non-static
functions in a static context, calling Session functions directly
instead of on its singleton, passing non-variables by reference, and
subclasses not using the same interface as the parent class.
relationships. Now when you view a resource, it has 4 top level
elements:
url: the url of this resource
resource: array of key value pairs describing the resource
members: array of urls to members of this collection
relationships: array of array of members.
Relationships are a special type of collection that links two
different resources together. To remove a relationship, just
DELETE its url. To create a relationship, POST to its
collection.
Individual modules can add their own relationships to any
resource via a callback mechanism.
Example:
Array(
[url] => http://g3.com/rest/item/1
[resource] => Array (
[id] => 1
[album_cover_item_id] => 4
[captured] =>
[created] => 1264056417
[description] =>
[height] =>
...
)
[members] => Array(
[0] => http://g3.com/rest/item/2
[1] => http://g3.com/rest/item/3
[2] => http://g3.com/rest/item/4
[3] => http://g3.com/rest/item/5
...
)
[relationships] => Array(
[tags] => Array (
[0] => http://g3.com/rest/tag_item/2,1
[1] => http://g3.com/rest/tag_item/23,1
)
)
)
