[Bps-public-commit] jifty-plugin-recordhistory branch, master, updated. 0.04-9-gf0064ed

[Shawn Moore]

The branch, master has been updated
       via  f0064edd72aa12a1bf35dea9f6a94f0166230079 (commit)
      from  8c794937b553b86210dbe121686a2380a10bdc58 (commit)

Summary of changes:
 lib/Jifty/Plugin/RecordHistory.pm |   27 ++++++++++++++-------------
 1 files changed, 14 insertions(+), 13 deletions(-)

- Log -----------------------------------------------------------------
commit f0064edd72aa12a1bf35dea9f6a94f0166230079
Author: Shawn M Moore <sartak at bestpractical.com>
Date:   Thu Feb 24 17:55:45 2011 -0500

    Explain the new world order in the doc

diff --git a/lib/Jifty/Plugin/RecordHistory.pm b/lib/Jifty/Plugin/RecordHistory.pm
index fa31991..53163b4 100644
--- a/lib/Jifty/Plugin/RecordHistory.pm
+++ b/lib/Jifty/Plugin/RecordHistory.pm
@@ -90,20 +90,21 @@ L<Jifty::View::Declare::CRUD>.
 
 =head2 Access control
 
-By default, we delegate
-L<Jifty::Plugin::RecordHistory::Model::Change/current_user_can> and
-L<Jifty::Plugin::RecordHistory::Model::ChangeField/current_user_can> to the
-record class. The logic is if you can read the record, you can read its changes
-and its change fields. If you can change the record you can create, update, and
-delete changes and their change fields. If you want more fine-grained control
-over this, you can implement a C<current_user_can_for_change> method in your
-record class which, if present, we will use instead of this logic.
-
-When we create a Change record, we do it as the superuser because if by
+When we read a Change record, we simply ask if the current user can read the
+corresponding record.
+
+Otherwise, when we create (or update or delete) Change records, we demand that
+the current user is a superuser. In our C<after_set> and C<before_delete>
+hooks, we perform these operations as superuser.
+
+We require superuser so that ordinary users cannot use
+L<Jifty::Plugin::REST> or similar to inject forged Change entries.
+
+Also, when we create a Change record, we do it as the superuser because if by
 updating a record the ordinary user loses access to update the record, then
-they will get a permission error when we go to create the corresponding
-Change. So not only does that change not end up in the record's history, but
-also Jifty complains permission denied to the user directly.
+they will get a permission error when we go to create the corresponding Change.
+So not only does that change never end up in the record's history, but also
+Jifty complains permission denied to the user directly.
 
 =head1 SEE ALSO
 

-----------------------------------------------------------------------