On 2013-09-10 21:05, Russell Keith-Magee wrote:
> So - I think custom Meta options are something that should be
> *possible*. I don't have any particular ideas for how it should be
> implemented, though.
One of the areas I've considered trying this is annotating "private"
information about models. The models' Manager class(es) could then
grow methods taking context (such as user information, remote IP,
HTTPS status, etc) and return models that have been sanitized based on
what that context permits ("Joe is a manager on-site, so can see the
full credit-card number and social security number", "Pat is a
non-manager employee visiting from on-site, so can only see the last
4 digits of the credit card number & social", "Ellen is an off-site
user and can only see the last 4 digits of her own credit-card &
social but nobody else's").
For implementation, I'd expect to namespace based on the name of the
app implementing the functionality, so you'd have something like
class MyModel(Model):
class Meta:
...
class MyApp:
secure_fields = ["cc_num", "ssn"]
The indentation might get just a little unwieldy, but namespacing
helps prevent clashes and sensibly be accessible just by chaining
properties:
secure_fields = existing_meta.MyApp.secure_fields
My $0.02
-tkc
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
