Change Details

When users apply for a partner that's either not available at the moment or not present on the system, handle the error gracefully instead of an internal server error (eg. https://wikipedialibrary.wmflabs.org/applications/apply/63/). While not available partners are invisible to non-staff users, they are still capable of entering the partner_ID into the URL (/applications/apply/<that_id>), which then results in a fatal error.

When users apply for a partner that's either not available at the moment or not present on the system, handle the error gracefully instead of an internal server error (eg. https://wikipedialibrary.wmflabs.org/applications/apply/63/). While not available partners are invisible to non-staff users, they are still capable of entering the partner_ID into the URL (/applications/apply/<that_id>), which then results in a fatal error. We're likely getting a partner directly by primary key somewhere without first checking whether that partner exists (and is available). We could use the `get_object_or_404()` function (https://docs.djangoproject.com/en/1.11/topics/http/shortcuts/#get-object-or-404) to avoid this issue, returning a 404 to the user instead of a server error.

When users apply for a partner that's either not available at the moment or not present on the system, handle the error gracefully instead of an internal server error (eg. https://wikipedialibrary.wmflabs.org/applications/apply/63/). While not available partners are invisible to non-staff users, they are still capable of entering the partner_ID into the URL (/applications/apply/<that_id>), which then results in a fatal error. We're likely getting a partner directly by primary key somewhere without first checking whether that partner exists (and is available). We could use the `get_object_or_404()` function (https://docs.djangoproject.com/en/1.11/topics/http/shortcuts/#get-object-or-404) to avoid this issue, returning a 404 to the user instead of a server error.