USTP: extra blank image containers in FM

arch-kiosk / arch-kiosk-office

💼 central place for collaboration

GNU Affero General Public License v3.0

1 stars 0 forks source link

USTP: extra blank image containers in FM #2186

Open lbestock opened 1 year ago

lbestock commented 1 year ago

After yesterday's mammoth NEF-fest I have now downloaded the workstations. There are a ton of extra blank image containers created by sys with yesterday's date (I prepared this morning). Looks like it might be one for each file added from the photo import, and they are in between the iPad created trench photos and the photo import ones. Could be an artifact of the NEFs? I will do a round with jpegs today and see if the same thing happens, but it's a bug either way.

urapadmin commented 1 year ago

this might be a bug, indeed. We must simulate that with a single image to see if it is really the case. @luizaogs: Are you there? It would help to do this thoroughly on PVD:

delete an image that is connected to a dayplan in the file repository using the trash can in the file edit dialog.
is it really gone from dayplans? (I mean not a blank image container, the whole dayplan record should be gone)
If that worked (if not you can stop) try the same thing, this time by marking an image in the file repository's list and deleting it with the toolbar button on top of the list.
does that produce an empty image container in dayplans?

luizaogs commented 1 year ago

Ja. I will do this in a bit, after finishing my application to graduate (scary).

luizaogs commented 1 year ago

Ok, did the first step of the test -- deleting an image connected to a dayplan using the trash can in the file edit dialog.

Result: it is not gone from dayplans. Just a blank image container, but the record itself and the image description are still there. The deleted image is the one between Party time and Kiosk on the Main Green:

Before deletion:

After deletion:

urapadmin commented 1 year ago

okay, thanks. That cannot be right.

lbestock commented 1 year ago

Well you have found out what it was, and so my addition is useless but I will make it anyway! I did a mammoth JPG import. No problem. I did another (smaller) NEF import. No problem. I went and deleted a NEF from the File Repository and voila, next download had the empty image. So additional confirmation that @urapadmin you were right in the kitchen that it was your deletion yesterday rather than the NEFiness of it all that led to that.

urapadmin commented 1 year ago

okay, I looked this up. This is indeed what we are doing. The images containers are emptied (so the reference to the image that's about to be dropped is removed) but we do not remove the record itself. The rational behind this must have been that I did not want to lose potential data in the same record. And I can think of at least one example where that is correct: locus relations. The whole relation would be deleted if the image gets deleted.

So this works as designed right now. Whether we want to improve it and how that can be achieved is something I postpone...

urapadmin commented 2 months ago

this was postponed and would still be the case: Deleting images does not delete the recording records and hence leads to empty containers in the records of the recording app. That is technically correct and in many cases what we want. But after a bulk import that went wrong it leaves a lot of fragments. Needs an idea how to deal with that.