Bug #10466

Unknown format links lead to internal server error

Added by Sarah Romkey about 4 years ago. Updated almost 4 years ago.

Status:VerifiedStart date:10/24/2016
Priority:MediumDue date:
Assignee:-% Done:


Target version:Release 1.6
Google Code Legacy ID: Pull Request:
Sponsored:No Requires documentation:


When you click on an Unknown format (one of the newly added ones) in Preservation Planning it creates an internal server error:

Traceback (most recent call last):

File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py", line 132, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/usr/share/archivematica/dashboard/fpr/views.py", line 72, in format_detail
format = get_object_or_404(fprmodels.Format, slug=slug)
File "/usr/local/lib/python2.7/dist-packages/django/shortcuts.py", line 155, in get_object_or_404
return queryset.get(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 338, in get
(self.model._meta.object_name, num)

MultipleObjectsReturned: get() returned more than one Format -- it returned 73!


#1 Updated by Holly Becker about 4 years ago

  • Status changed from New to In progress

This happens because the AutoSlugField isn't correctly generating slugs for the new Formats & FormatVersions.

Inside the data migration, calling Format = apps.get_model('fpr', 'Format') returns a model that doesn't have the AutoSlugField's populate_from set correctly. When tested inside manage.py shell, from django.apps import apps ; apps.get_model('fpr', 'Format') works, as does from fpr.models import Format inside a data migration.

Temporary workaround applied by importing the real model inside the data migration, but this is discouraged in the Django docs. This change is incompatible with the previous FPR migration - will need to be re-deployed.

Possible long-term solutions include
  • Loading from fixtures, like how PRONOM84 handled it
  • Troubleshooting AutoSlugField
  • Using a different AutoSlugField that fixes the problem

#2 Updated by Holly Becker about 4 years ago

  • Status changed from In progress to Deploy
  • Assignee changed from Holly Becker to Nick Wilkinson
Suggested course of action:
  1. Re-deploy the testing server (reishi?) with the updated AM branch dev/issue-9213-pronom-88 (which includes the update to FPR branch dev/issue-9213-pronom-88)
  2. Analyst updates the new formats to correct groups
  3. Dev dumps the updates using manage.py dumpdata and something to detect what's been changed (needs to be developed)
  4. FPR migration updated to loaddata, similar to behaviour in the PRONOM 84 migration

#3 Updated by Nick Wilkinson almost 4 years ago

  • Assignee changed from Nick Wilkinson to Santiago Collazo

Hi Santi, can you take care of the deploy listed in Holly's step # 1 in comment # 2? https://trello.com/c/NxgO9ncY

#4 Updated by Santiago Collazo almost 4 years ago

  • Assignee changed from Santiago Collazo to Holly Becker


#5 Updated by Santiago Collazo almost 4 years ago

Environment updated, and AM instance databases recreated.

#6 Updated by Justin Simpson almost 4 years ago

  • Status changed from Deploy to Verified
  • Assignee deleted (Holly Becker)

This was deployed and I tested it and the problem is resolved.

Also available in: Atom PDF