1. Progress: I've made improvements to admin checks. I've also finished
implementing filtering and silencing checks. I've rebased my branch against
master again.
2. I'm afraid that there is too little time to merge django-secure.
September 16 is
suggested 'pencils down' date, so there are only less than two weeks (12
days) +
one buffer week, because firm 'pencils down' date is September 23. Merging
django-secure in such little time is actually impossible -- we must through
out
this task from schedule. I really apologize for that.
My plan is that this week I will work at documentation (at this moment
there is
only a draft). I will also try to implement as much "nice to have" things as
possible. These are:
- Writing tests which would be nice to have. I mean three tests:
- [#20974],
- test for raising error when ImageField is in use but Pillow is
not installed,
- test for raising error in `BaseCommand.__init__`.
- Moving out checks performed in `__init__`.
- Checking clashes between accessors and GenericForeignKeys.
- Checks for grouped `choices`.
The second week and the backup week is for deep review. Regarding the amount
of comments I got during the first review, I guess I need *at least* one
week
for deep review.
[#20974] https://code.djangoproject.com/ticket/20974
3. As I said, I've implemented both filtering and silencing system checks.
You can run only a subset of checks like that:
./manage.py check auth -t tag1 --tag tag2
This command will run only these checks which are labeled with `tag1` or
`tag2`
tags and only `auth` app will be validated. If there is no app name, all
apps
are checked. If there is no tag name, all checks are performed.
Your check function can be labeled in this way:
from django.core.checks import register, tag
@tag('mytag')
def my_check_function(apps, **kwargs):
# apps is a list of apps that should be validated; if None, all apps
# should be checked.
return []
register(my_check_function)
The `tag` decorator works only for entry-point functions, e.g. these one
passed
to `register` function. It doesn't work for checks
functions/methods/classmethods which are called by entry-point functions
(directly or indirectly).
To silence a specific error/warning, you need to append its `id` to
SILENCED_SYSTEM_CHECKS setting. The `id` could be any string, but we use the
following convension: "E001" for core errors, "W002" for core warnings,
"applabel.E001" for errors raised by an custom app (including contrib apps,
i.e.
"sites.E001"). The error/warning number is unique to an app, e.g.
"sites.E001",
"admin.E001" and "E001" are all allowed, but "E001" and "W001" are not OK.
You
should use "E001" and "W002". To create an error/warning with given id,
pass it
as a keyword argument:
Error('Message', hint=None, obj=invalid_object, id='myapp.E001')
4. More important changes in code:
- Introduced RAW_SETTINGS_MODULE [1]. I use it in compatibility checks to
test
if `TEST_RUNNER` setting was overriden [2].
- Introduced `BaseAppCache.get_models_from_apps` method [3]. This method
returns
all models of given set of apps (or of all apps if None is passed) and is
used
in `default_checks.py` [4].
- Admin changes are backward compatible. Admin validators are deprecated in
favour of admin checks, i.e. `BaseValidator` is deprecated in favour of
`BaseModelAdminChecks`. `BaseValidator` is an almost empty class now.
`ModelAdmin.validator` class attribute is deprecated in favour of new
`checks`
attribute. If an ModelAdmin defines `validator`, we are not ignoring it.
[1]
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/conf/__init__.py#L139
[2]
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/core/checks/default_checks.py#L33
[3]
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/db/models/loading.py#L296
[4]
https://github.com/chrismedrela/django/blob/gsoc2013-checks/django/core/checks/default_checks.py
5. I've left one comment on the pull request. (I mean this one about moving
registering admin checks to `autodiscover`.)
--
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.
