AttributeError at /admin/documents/document/

[pengc99]

While attempting to edit tags for a document that was ingested, I get the following error now when I attempt to access the "Documents" section of the page:

`

Request Method:	GET
http://192.168.1.11/admin/documents/document/
2.0.8
AttributeError
'NoneType' object has no attribute 'year'
/home/paperless/.local/lib/python3.5/site-packages/django/contrib/admin/templatetags/admin_list.py in , line 402
/usr/bin/python3
3.5.3
['/usr/local/src/paperless/src', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-x86_64-linux-gnu', '/usr/lib/python3.5/lib-dynload', '/home/paperless/.local/lib/python3.5/site-packages', '/usr/local/lib/python3.5/dist-packages', '/usr/lib/python3/dist-packages']
Mon, 1 Oct 2018 03:48:03 +0000
`

I know it's a bit messy, but I've linked the traceback to this location:
http://dpaste.com/2RWY6HY

The error appears whenever I attempt to access the Documents section of the page. Paperless is installed on bare metal on a Debian 9.6 server and was happily ingesting ~60 or so documents before this happened.

[pengc99]

This is the blub that is referenced in /home/paperless/.local/lib/python3.5/site-packages/django/contrib/admin/templatetags/admin_list.py on line 402:

  else:
        years = getattr(cl.queryset, 'dates')(field_name, 'year')
        return {
            'show': True,
            'choices': [{
                'link': link({year_field: str(year.year)}),
                'title': str(year.year),
            } for year in years]
        }

[pengc99]

I have traced the problem down to a document that OCRd and had year of 0590-01-07 (see photo). I was able to pull up the document and edit the date to the correct date, and this has solved the problem. Perhaps the OCR date assignment needs some logic checking or a regex to prevent OCR dates from clobbering up the UI?

[Sblop]

In the latest release (docker) I have this problem whenever I edit tags, consumers, try to delete docs etc? I have not been able to solve this yet.

[mannp]

Same issue here with the latest release docker image.

[danielquinn]

Hi @pengc99, thanks for reporting this, as it's the sort of thing that's easy to overlook when writing the code. I've added a fix and a test for this situation that should prevent such problems in the future. Basically, if a date is detected that appears unlikely (prior to 1900), we don't capture that date and move on to the next one (if any). Hopefully that'll solve this problem so I'm closing this ticket.

To @Sblop and @mannp, I think you may be talking about #394, which I'm still having trouble reproducing so I can't fix it. If you have some input to offer, like a process I can follow to reproduce the problem, that'll help me figure it out.

[mannp]

@danielquinn apologies I saw the title and initial detail and it seemed the same as mine.

After a more detailed look it appears mine is related to admin password or something so I have created a new issue here -> #415