Change Date of Document

Paperwork
#1

Hi,

when I put new docs into my archive, they always get the actual date. But often I want to change the date, but nothing happens, also no label will be written at this moment.

When I change only the labels, all is fine.

My document-archive is onto a sambashare I created and mounted directly into myDocuments, only to work with this archive from everywhere in my LAN.

My user has all rights to do everything on this share, but I can’t change the date in paperwork after creation. If I change the folders name (which seems do represent the document date) to the date I need (no paperwork is running), and start paperwork, the documents are sorted as expected.

What’s wrong? Do I need a special group to work with paperwork? My group is named familie …

Greetz,

Christoph

#2

Hello,

At first sight, it looks like a bug.

There is a bug report feature integrated in Paperwork: application menu (aka “hamburger menu”) → “Report bug”. Can you reproduce the issue and then use this feature to send a bug report please?
By default it will include the logs in the bug report, which should help me understand what’s going on exactly.

Best regards,

#3

Hm, weird, you get the following error in the background:

Traceback (most recent call last):
  File "/app/lib/python3.7/site-packages/openpaperwork_gtk-2.0.2-py3.7.egg/openpaperwork_gtk/fs/gio.py", line 346, in fs_rename
    old.move(new, Gio.FileCopyFlags.NONE)
gi.repository.GLib.GError: g-io-error-quark: Fehler beim Verschieben der Datei ###HOME_DIR###/papers/20210306_1604_47: Keine Berechtigung (14)

That’s why the date isn’t changed.

(I feel like I’ve already seen this problem not long ago)

#4

There is something you can try:

In a terminal:

flatpak run --command=paperwork-gtk work.openpaper.Paperwork plugins add openpaperwork_core.fs.python 
flatpak run --command=paperwork-gtk work.openpaper.Paperwork plugins remove openpaperwork_gtk.fs.gio

This will disable the plugin openpaperwork_gtk.fs.gio and enable openpaperwork_core.fs.python instead. fs.python should work as well as the fs.gio plugin for the local files (including your samba mount).

If it does work with fs.python, it probably means there is a bug in either the plugin openpaperwork_gtk.fs.gio or Gio itself.

In case you want to go back to the default configuration:

flatpak run --command=paperwork-gtk work.openpaper.Paperwork plugins reset

Also beware that after some updates, Paperwork may go back automatically to the default plugins list (in other word, if it did work for you, you may have to disable fs.gio again)

#5

Hi,

I just tried it out now - but it seems not to work as expected.
In terminal it shows the same error as above? I just made the changes before starting paperwork again.
Send you the logs by error-report …

Greetz, Christoph

#6

Sorry, I forgot that openpaperwork_gtk.fs.gio was always loaded even if removed from the configuration. It’s fixed ( 269dfc34791c7df439e0792263125891c9b0b5ed ), the update is on its way.

#7

This time, disabling openpaperwork_gtk.fs.gio did work, but even with openpaperwork_core.fs.python, the error is pretty much the same:

File "/app/lib/python3.7/site-packages/openpaperwork_core-2.0.2-py3.7.egg/openpaperwork_core/fs/python.py", line 67, in fs_rename
    os.rename(old_path, new_path)
PermissionError: [Errno 13] Keine Berechtigung: '###HOME_DIR###/papers/20210306_1257_51_8' -> '###HOME_DIR###/papers/20180406_0000_00'
#8

I wonder: Is your samba share actually on a Windows system or on a GNU/Linux one ?

If the share is on a Windows system, the problem could be close to one described here: windows - Why os.rename sometimes returns error access is denied python - Stack Overflow

#9

Hi,
no, it’s a samba server inside of openmediavault - a nas-system onto debian 10.
Maybe it’s settings works a bit like windows-shares? I don’t know.

I’ve just made this test: a document scanned by paperwork is changeable, but another document which is only imported I can’t change.

Paperwork2 - SMB-Fehler5
Paperwork2 - SMB-Fehler5766×381 97.3 KB

Here are these docs - the first two lines with “osnatel…pdf” are originals, folder “20210309_1939_34” is one of these imported docs, and the last lines are belonging to a scanned doc.

Greetz, Christoph

#10

Ok, I think I may know where the problem is coming from. Poppler (the library used to read PDF files in Paperwork) probably keeps the pdf file of the document opened, which prevents renaming it. I’m going to check.

#11

Once the build #264217 is done, can you update and try again please ?

If it still doesn’t work, can you try the following command and try again please ?

flatpak run --command=paperwork-gtk work.openpaper.Paperwork plugins remove paperwork_backend.poppler.file

(it will disable the plugin paperwork_backend.poppler.file and therefore fall back on the plugin paperwork_backend.poppler.memory to open PDF files)

#12

“~$ flatpak update work.openpaper.Paperwork” won’t give any update? Just “nothing to do” is result.

#13

That’s because the the build #264217 has failed (there is a single test that fails randomly 1 out of 10 times, and I haven’t been able to figure out why yet).

I’ve restarted the tests, but now there is a problem with the datacenter where openpaper.work is hosted: Openpaper.work is down (datacenter is on fire)

#14

I think, it make no sense to try

flatpak run --command=paperwork-gtk work.openpaper.Paperwork plugins remove paperwork_backend.poppler.file

with my last build here?
I hope, your hosted data and backups will be restoreable and not lost and you will not loose to much work

#15

You can try, but when I tried with the previous version of Poppler, it failed (that’s why I wanted to update the version of Poppler in the Flatpak repository).

If you want to try and if it fails, here is the command to put back the default plugin list:

flatpak run --command=paperwork-gtk work.openpaper.Paperwork plugins reset
#16

Hi,
I tried it now again, after I get an update … and now date changing works :fu:

Greetz, Christoph