Snippet List
Until [#11154] is fixed, django won't create permissions for proxy models for you as it does with other models, even the one you define using the [`permissions` option](https://docs.djangoproject.com/en/dev/ref/models/options/#django.db.models.Options.permissions) on your models.
This snippet will make sure all permissions are create for proxy models. Just make sure this code gets loaded after the `update_contenttypes` handler is registered for the `post_syncdb` signal. Putting this code in one of your `INSTALLED_APPS' after `django.contrib.contenttypes' should do it.
UPDATE: 'ORDER BY' in de regex is now optional
If enabled while coding just keep track of your console output for:
<<< WARNING >>> Query execution without ownership clause, called from "process_response"
Happy coding
Regards,
Gerard.
- middleware
- user
- permission
- ownership
- created_by
I'm using Django's FlatPages, but I want to be able to restrict admin access to Users based on a FlatPage url. For example, User John Doe should be able to edit any FlatPage objects whose URL begins with `/johndoe/` (such as `/johndoe/about/` or `/johndoe/projects/whatever/`).
For this to work, John Doe would already need the appropriate admin permissions for FlatPage (such as can_add and can_change).
I have set this up as a separate *flatpage_addons* app. It consists of the **Permission** model, which maps a starting URL to one or more django Users. It consists of the minimal necessary admin code so Permissions can be created using the admin.
The bulk of this code consists of the *ifhasflatpagepermission* template tag as well as the *flatpage_result_list* inclusion tag. The former works much like django's existing *if*, *else*, *endif* tags while the latter is modified from the django admin's *result_list* inclusion tag.
This may not be the most elegant solution to my problem, but so far it works for me. Any comments or suggestions are welcome!
- urls
- url
- permission
- permissions
- flatpage
- flatpages
=== version 2 ===
> Parts of this code are based off of source from *davidcramer* on #django and I'd like to thank him for his assistance.
Example:
# forms.py
...
class ForumPostForm(FieldAccessForm):
class Meta:
model = ForumPost
class FieldAccess:
moderator = FieldAccessLevel(
lambda user, instance: user.get_profile().is_moderator,
enable = ('approve', 'delete', 'edit')
member = FieldAccessLevel(
lambda user, instance: user.is_active,
enable = ('edit',),
exclude = ('approve', 'delete')
...
# template
...
<form action="" method="POST">
<table>
{% for field in form %}
<tr><th>{{ field.label_tag }}</th><td>
{% if not field.field.disabled %}
{{ field }}
{% else %}
{{ field.field.value }}
{% endif %}
</td></tr>
{% endfor %}
</table>
<p><input type="submit" value="Update" /></p>
</form>
...
This class will grant or deny access to individual fields according to simple rules. The first argument must be a user object, but otherwise, this class is instantiated the same as a ModelForm.
To utilize this code, inherit your form from FieldAccessForm, and create an inner class on your form called FieldAccess. Variables added to this inner class must have the same structure as that provided by the FieldAccessLevel class, which defines an access level, and the fields which apply to that access level.
FieldAccessLevel takes as it's first argument a callable rule that validates this access level. That rule will be called with two arguments: 'user' (current user requesting access) and 'instance' (model instance in question).
The keyword arguments to FieldAccessLevel are field groups which are used to determine which fields on this form are to be enabled and/or excluded, when the current user matches this access level. The term exclude indicates fields which are not to be rendered in the form at all.
Any fields not grouped in either 'enable' or 'exclude' will be disabled by default.
Superusers are always assumed to have full access. Otherwise, if a field is not specified with the FieldAccess inner class, then it is disabled by default. In other words, all users (except superusers) are denied access to all fields, unless they are
specifically given access on a per-field basis.
It is worth mentioning that multiple access levels can apply simultaneously, giving a user access to fields from all levels for which he matches the rule.
If a user is denied access to a field, then the widget for that field is flagged as disabled and readonly. The field is also given two new attributes: a boolean 'disabled', and a 'value' containing the instanced model field. These two attributes allow a template author to have great control over the display of the form. For
example, she may render the plain text value of a field instead of the disabled widget.
The FieldAccess inner class also allows one to conditionally exclude fields from being rendered by the form. These exclusions operate very similarly to the standard Meta exclude option, except that they apply only to the access level in question.
Note: The FieldAccess inner class may be used on both the form and the model; however, generally it makes more sense on the form. If you do use FieldAccess on both the form and model, be aware that both definitions will apply simultaneously. All access levels for which the user passes the rule will be processed, regardless of whether they were found on the form or the model.
- form
- field
- permission
- modelform
- access
This is a simple helper to make custom permission decorators for Django views.
Perhaps you have an edit_comment view which you want to make sure current user is the owner of:
>def edit_comment(request, comment_id):
>>if request.user == Comment(id=comment_id).user:
>>>... do authorized things ...
>>else:
>>>... do unauthorized things ...
>>...
>>...
In this view, you might do a quick check `if request.user == Comment(id=comment_id).user`, however you now need to duplicate this code all over the place whenever you want to check if a comment is owned by the current user.
Instead, you can use the built in login_required decorator, and your own decorator to do the test:
>@permission
>def user_owns_comment(request, comment_id):
>>return request.user == Comment(id=comment_id)
>
>@login_required
>@user_owns_comment
>def edit(request, comment_id):
>> ...
>> ...
>> ...
The "tester" function will post a message using the messages module built into Django, and redirect the user to the root. It allows access and executes the view if the tester function returns anything that evaluates to True.
Your permission tester should either strictly specify the same arguments as the view, or take additional *args, and **kwargs to prevent syntax errors on extra arguments being passed along.
- view
- decorator
- permission
You can use this method to send information mails to the related staff members about section specific site activity. All users which explicitly permitted to 'change' given object will be informed about activity.
If you defined get_absolute_url in your model then you can simply use it like this;
`
obj=form.save()
mail2perm(obj)
`
Or you can define your custom urls ;
`
from util.mail2perm import mail2perm,domain
reply=get_object_or_404(Reply,user=request.user,pk=id)
mail2perm(reply,url='http://%s/admin/support/show/?id=%s'%(domain,reply.id))
`
8 snippets posted so far.