Too strict checks on urlpatterns

[pakal]

I've used my own view, which directly uses the "field_file" of the django model, and filters on instances "PKs, but the framework checks still require a precise urlpattern with a "path" in it.

Wouldn't it be better to just issue a Warning, and give to these checks Tags and IDs so they can be silenced from django conf?

[danielquinn]

Hi, sorry I took so long to respond to this. I'm not clear on the problem, and some code samples would go a long way to helping me understand. I'm open to making the URLs configurable, but I'm hesitant to defaulting to throwing out warnings.

[pakal]

Alright, here are the checks below, the reverse() check is a bit strong as it requires a specific view to exist, whereas users like me are using a different approach to access data.
Just adding ids and tags to these checks would allow users to silence them (while still hard-warning new users).
Similarly, the url() method of encrypted models relies heavily on this FETCH_URL_NAME to exist, but it's less a problem - we just have not to call it if we didn't implement FETCH_URL_NAME.

(Thanks for the awesome lib btw)

@register()    <--- missing id+tag
def constants_check(app_configs, **kwargs):

    check_messages = []

    message = "{} must be defined in your environment for " \
              "django-encrypted-filefield to work."

    if not SALT:
        check_messages.append(Error(message.format("DEFF_SALT")))
    if not PASSWORD:
        check_messages.append(Error(message.format("DEFF_PASSWORD")))

    return check_messages


@register()   <--- missing id+tag
def fetch_url_check(app_configs, **kwargs):

    if not FETCH_URL_NAME:  
        return []  # We've got bigger problems

    try:
        reverse(FETCH_URL_NAME, kwargs={"path": "anything"})   <--- strong check
    except NoReverseMatch:
        return [Error(
            "django-encrypted-filefield requires that you define a url for "
            "the fetching the files."
        )]

    return []

[danielquinn]

It's been a long time, but I've finally found some time to address this. I've added a tag to each of these checks as part of the move to 0.3.0 (release notes). I hope this solves your problem. If not, just reopen this ticket and I'll get to it when I can.