IntegrityError on deleting document #394
Comments
|
Ew. Ok well this is probably a relations thing, where deleting a document is blowing up because stuff that's linked to that document isn't being deleted automatically. I'm on mobile right now, but I'll try to have a look in the next couple days. |
|
Unfortunately, I can't reproduce this. I had a document in my own instance and managed to delete it just fine by going to the admin, clicking on the name of the document and then clicking the When you click the Big Red Delete Button, it should show you a page of what will be deleted and ask for confirmation. Can you post what's on that page? |
|
I am also getting the same error if I try to rename the document, add a tag, change the correspondent, anything really. It's not just this document. I tested a few others with the same results. |
|
That's just too weird. I just can't reproduce this. Judging by your traceback, it looks like you're running Sqlite, and not one of the more robust database servers, but have you been poking around in the database manually anyway? |
|
No, I haven't touched the database. I run it in the Docker container. The only thing I do weird is change some paths in my entrypoint file to work in a subdirectory, but I tried getting rid of that to test and got the same result. |
|
Naw, I can't see how that'd be a problem. This definitely reads like a database problem, but an I'm sorry, but I'm at a loss right now. I'm going to suggest two things, both of which suck:
It's pretty late here, so I have to sign off, but I hope that one of those pans out for you. |
|
I don't know enough for number one, but I tried number two. I'm still getting the same error. Interestingly, this time, something is different. When I go back from the error page, there is a banner: The file itself is gone, but the item is still there in Paperless. |
|
So it's not just documents. I get the same error when trying to edit anything, including just renaming a tag. This is after backing up and reimporting Paperless from scratch, so I don't know now this is limited to me. |
|
I can poke around in sqlite if you tell me what I am looking for. |
|
Here's an interesting thought: what if you set the permissions on I'm reaching, but I'm running out of ideas. |
|
No change with the permissions, unfortunately. I found this though: https://docs.djangoproject.com/en/2.0/releases/2.0/#foreign-key-constraints-are-now-enabled-on-sqlite I know very little about Django or SQLite, but that looks like a change when moving to Django 2.0 is causing this. When attempting to replicate, have you tried creating a test instance with an older version of Paperless and upgrading? |
|
I can reproduce this with Django 2.0 + the current paperless master, I'll post instructions later today. |
|
Hooray for confirmation! Alright once @erikarvstedt has a reproducable case, that'll give me (or them) something to work with! |
|
Here comes the repro. I could trigger this bug by upgrading the Paperless nix package to Django 2.0.8. 1. Run PaperlessRun this Dockerfile or, even better, install Nix and run this in a shell: paperless=$(nix-build --no-out-link -E '
with (import <nixpkgs> {});
let
pkgs = import (fetchFromGitHub {
owner = "erikarvstedt";
repo = "nixpkgs";
rev = "paperless-django2";
sha256 = "1wcrsf7ai8m5r855dcdw434qs8zc96bc5zw8y2zpya3jxr1spc8i";
}) {};
in
pkgs.paperless-django2.withConfig {
dataDir = /tmp/paperless-django2;
config = {
PAPERLESS_DISABLE_LOGIN = "true";
};
}
')
$paperless migrate
$paperless runserver --noreload localhost:8000
rm -r /tmp/paperless-django2 # remove app data2. Trigger the bugBrowse to http://localhost:8000/admin/documents/tag/add/ and add a new tag. Curiously, the error doesn't occur when adding a tag with the REST api (http://localhost:8000/api/tags/). You may change I know too little about Django to have any idea what's going on here. 😐 |
|
I you want to experiment and run Paperless from your local source, try the following. |
|
I'm sorry, I can't reproduce this, and I'm not in a position to support Nix right now, so that Dockerfile doesn't really help me :-( What I can tell you is that I ran the following commands and everything worked as expected docker system prune --all --volumes
docker-compose up
docker-compose run --rm webserver createsuperuser
docker-compose run --rm consumer /usr/src/paperless/src/manage.py document_importer /exportThis is my version: '2'
services:
webserver:
image: danielquinn/paperless
ports:
- "8000:8000"
volumes:
- data:/usr/src/paperless/data
- media:/usr/src/paperless/media
env_file: docker-compose.env
environment:
- PAPERLESS_OCR_LANGUAGES=
command: ["runserver", "--insecure", "0.0.0.0:8000"]
consumer:
image: danielquinn/paperless
volumes:
- data:/usr/src/paperless/data
- media:/usr/src/paperless/media
- /tmp/paperless/consume:/consume
- /tmp/paperless/export:/export
env_file: docker-compose.env
command: ["document_consumer"]
volumes:
data:
media:The import data came from another working installation, but even if you don't import anything and just start from scratch, I managed to create tags & delete them without issue. To fix this, I need to reproduce it in the simplest way possible. Ideally, this means without even using Docker as it reduces the number of things that might be breaking stuff. At the moment, I'm going with the assumption that there's something broken on a Docker volume somewhere, but I have no proof to back that up. |
|
I really don't understand how you aren't able to replicate this. It's not my database, or my configuration, or my proxy. I'm getting the same error with a blank database, no files, no special configuration, and no proxy. I can run: |
|
Ah, it's probably the disabled login which causes this. Enabling login (which means not setting @danielquinn, changing should trigger the bug in your config. |
|
Wow, I never would have guessed that this would be linked to the login disabling... Alright I've looked into this (and reproduced it!) and the result is not-awesome. Basically in disabling the login requirement, anything you do as a user in the admin can't be attributed to you, but "you" is no one. We've avoided this 'til now because most of the actions you do in the admin are read-only, and there's no action logging for reads. However, there is a log for things like tag creation/deletion. Now the fix for this can go a few different ways, so I'm looking for some input here: 1. Change the Hack User IDCurrently login-free sessions are handled with this crazy hack of a model which has a hard-coded value of An easy fix might be to hard-code 2. Disable Logging if Logins are disabled.Currently, this problem is being triggered because Django is trying to log the act of adding/deleting a tag, so if we hack around this decision-making process to choose not to log if logins are disabled, that'd work. However it would only fix the problem in the case of logging. Should we later add something that assumes a logged-in user, things would explode again. 3. Write a Proper Front-endThis is the preferred solution, because Paperless at its core is an abuse of the Django admin. Much of what's breaking is a direct result of us imposing things on the admin that it was never meant to shoulder. However, I don't have time to write this, so while it's the best option for the project, it's not likely to happen unless someone picks up this task. So basically we're looking at 1 or 2 I guess, but I'm curious how you guys use it. For example, Option 1 will only work if there's a user to assign to the logged-in user's process. I'm pretty sure Paperless doesn't work unless you've at least (followed the setup docs to) run So what do you think? I have no strong feelings either way we go, but it's important to me that this not mess up other people's working instances. |
|
Either 1 or 2 would work for how I use it, i.e. with a single user. I would think option 1 would be a better long term option, because as you said, things could break again in the future. Would a variation of #1 be possible, where in the settings file, when you disable login you choose the 'default' user? Something like PAPERLESS_NO_LOGIN_USER="kmlucy"? |
|
Ok! I think I've fixed this in the latest push, so I'm going to close it. If it's still a thing though, feel free to re-open. For the record, I ended up on going with a variation of option 1. @erikarvstedt thanks for digging up how we solved this before, but I didn't want to go too far down the road of creating a bunch of non-users to facilitate a hack. The right way will always be option 3, but until that happens, I don't to create too much of a hack foundation to build on. |
When I try to delete a document, I get the following error:
with traceback:
Let me know if you can reproduce or not or if you need more information. I am running the Docker container.
The text was updated successfully, but these errors were encountered: