I'll second storing permission information in the model; that's pretty
clearly the best way to go about it. The less code in the views, the
better.
I'd also agree that the authorization system should be fairly generic,
operating more at the database level than as a high-level roles-based
abstrac
Jason Huggins wrote:
>
> Robert Wittams wrote:
>
>>It seems that custom authorization is a common pattern that the generic
>>views and admin interface do not handle.
>
>
> I agree.
>
>
>>Any thoughts? I'm currently doing the first option with a wrapper round
>>the generic views. But I think
Jason Huggins wrote:
> Here's how the above use-cases would be defined in my table:
Sorry, I didn't realize the formatting of my sample table only loooks
good with a fixed-width font.
> check_permissions(principal=request.user,
> permission='add_timesheet',
> user_id='jasonh')
>
> The ab
Robert Wittams wrote:
> It seems that custom authorization is a common pattern that the generic
> views and admin interface do not handle.
I agree.
> Any thoughts? I'm currently doing the first option with a wrapper round
> the generic views. But I think this should be built in.
First off, I a
It seems that custom authorisation is a common pattern that the generic
views and admin interface do not handle.
The situation is : model objects, through some set of relationships, are
related to a user object. Only if this user object matches the current
user do we want to allow update or
