Managing photos — what changes what
A photo in the diary is not one single thing: it is in the diary view, in the photo viewer, and it can end up in the diary PDF — which may already be in a sent e-mail. This article states in one place, for each action (uploading, reordering, deleting, replacing, changing a setting), what it changes where, and what it does not. The step-by-step guide is in Upload a photo in the diary; the admin settings are in Set up photos.
The two basic rules
Section titled “The two basic rules”- The diary view and the photo viewer always show the current state. If a photo has been deleted, a trace stays in its place: “Image deleted by <name> (<time>) — reason: <reason>”. The trace cannot be removed.
- The PDF is a snapshot taken when it was generated. A PDF that has already been generated (and especially one that has been sent) is not rewritten: it is an immutable record. If the PDF gets a new version, that is a new copy and the old version is kept with its own content — and the e-mail the old PDF went out in is not sent again.
Every row below follows from these two.
In short: who changes what
Section titled “In short: who changes what”| What you do | Diary view and photo viewer | The PDF that was already generated |
|---|---|---|
| Upload a new photo to a new entry (new event, new maintenance item, handover not saved yet) | It is attached when you save the entry, and visible from then on. | If the diary already has a generated PDF, the next time it is opened a new version is made with the photo; the old version is kept. |
| Upload a new photo to an existing entry | It is saved and shown immediately; no separate save. | Same: a new version the next time it is opened; the old one is kept. |
| Reorder (◀ ▶) | For an existing entry it saves immediately; the diary view shows the new order. | No new version is made because of it: the finished PDF keeps the old order. |
| Delete before the shift is closed (the uploader, their own photo) | The photo disappears; a trace (name, time, reason) stays in its place. | No new version: in the PDF already generated the photo stays. |
| Delete after closing (administrator only) | Same: a trace in its place. The administrator also must give a reason. | No new version: in the PDF already generated and in the sent one the photo stays. |
| Replace (new image or empty value in the diary’s “Image” data point) | A trace stays in place of the old image, with the reason “replaced”; the new image is shown. | Removing the old image on its own does not produce a new version; attaching the new image does — see the example below. |
| Switching the box off by the admin | Old photos are kept and shown; no new photo can be uploaded. | The finished PDF does not change; a later new version includes the photos that remain. |
| Changing the PDF photo setting (no photos · thumbnail · large image) | No effect on the diary view or the photo viewer. | Old PDFs are not regenerated; the new setting only affects PDFs made from now on. |
| Deleting a maintenance entry in the diary | The entry and its photos disappear from the diary. In the photo viewer the photo stays, dimmed, with a “Deleted source” badge — but only for people who can also see the deleted entry on Reports › Maintenance (report:maintenance). | No new version is made: the finished PDF keeps the entry and its photo. |
Case by case
Section titled “Case by case”Uploading a new photo
Section titled “Uploading a new photo”The photo belongs to the entry: for a new entry it goes into the diary when you save the entry, for an existing one immediately. In both cases it is visible at once in the diary view and in the photo viewer.
For the PDF this means the set of photos in the diary has changed, so the finished PDF counts as out of date: the next time it is opened it gets a new version and the old one is kept. The e-mail is not sent again — what went out earlier went out with the old PDF and stays that way. If the diary has no finished PDF yet (for example the shift is still running), there is nothing to regenerate: the PDF is built with the photos that exist at that moment.
The order you set with ◀ ▶ applies in the diary view at once. It does not affect a PDF that is already finished and does not create a new version; if the PDF later gets a new version for another reason (for example a new photo), it is built with the order at that time.
Deleting before closing (the uploader)
Section titled “Deleting before closing (the uploader)”Whoever uploaded a photo can delete their own photo until the shift is closed. You must give a reason when deleting, and deletion cannot be undone. A trace stays in place of the photo: your name, the time and the reason — visible to everyone who can see the diary.
Deleting after closing (administrator only)
Section titled “Deleting after closing (administrator only)”From a closed (archived) diary only the system administrator can delete a photo, with a mandatory reason — this is the remedy for cases such as a recognisable person ending up in a photo or a photo uploaded by mistake. After closing the uploader can no longer delete (“The shift has already been closed, so the uploader can no longer delete the image. Ask an administrator.”). Deleting leaves an audit trail.
Replacing
Section titled “Replacing”At the diary’s “Image” data point (see Fill in the diary data points), replacing an image is really two steps: the old image disappears with a trace (the reason is filled in automatically: “replaced — the diary image field now holds a new image or no value”; the “deleter” is whoever saved the diary with the replacement), and the new image is attached like any new upload. The photo boxes (event, shift handover, maintenance, task) have no separate “replace”: you delete one and upload another.
If the admin let the “Image” data point take several photos (1–10, in the diary element editor), the field works as a photo box too: a photo taken out (no longer there when the diary is saved) gets the same “replaced” trace, and binding a new photo gives a new PDF version. The server checks the count when saving; a deleted photo does not take up a place.
A switched-off box
Section titled “A switched-off box”If the admin switches the box off on an element, old photos are kept and shown (in the diary view and in the photo viewer) — only new photos cannot be uploaded. Switching off changes nothing about photos already uploaded or about finished PDFs.
The PDF appearance setting
Section titled “The PDF appearance setting”The photo setting (no photos · thumbnail · large image) is under PDF & email → Appearance. Changing it does not regenerate old PDFs: a PDF that is finished stays as it was. The new setting only affects PDFs made from now on — and an old PDF that later gets a new version for another reason, because that new version is made with the current setting.
Example: the life of one shift’s PDF
Section titled “Example: the life of one shift’s PDF”| When | What happens | What the PDF contains |
|---|---|---|
| Monday 18:00 | The shift is closed, the PDF is made (version 1) and the e-mail goes out. | 2 photos (thumbnails). |
| Tuesday 09:00 | The data supervisor uploads a third photo to the closed diary. | Version 1 is unchanged. |
| Tuesday 09:05 | Someone opens the PDF: version 2 is made. The e-mail is not sent again. | Version 2 has 3 photos; version 1 is kept with 2. |
| Wednesday 10:00 | An administrator deletes a photo with a reason. | Version 2 is unchanged: all 3 photos stay in it. In the diary view a trace stands in place of the photo. |
| Thursday | The setting is switched to “large image”. | Existing versions do not change. |
| Friday | A new photo is added to the diary. On opening, version 3 is made — now with large images, and the trace in place of the deleted photo. | Version 3: the remaining photos large + the trace. Versions 1 and 2 untouched. |
Who can do what
Section titled “Who can do what”| Action | Permission |
|---|---|
| Upload a photo | The right to record the entry you attach it to: event event:create, shift handover shift_log:create, maintenance maintenance:create, task task:update_status (for a closed diary: a role allowed to correct it). |
| Delete your own photo | The uploader, until the shift is closed, with a reason. |
| Delete a photo after closing | The system administrator only, with a mandatory reason. |
| View photos | Whoever can see the photo’s source (diary, work order, permit) — within their own site access. |
| Filter by uploader in the photo viewer | photos:filter_by_uploader |
| Export the photo manifest | photos:export |
| Box on/off, count, PDF setting | The admin (see Set up photos). |
Frequent questions
Section titled “Frequent questions”| Question | Answer |
|---|---|
| I deleted a photo but it is still in the PDF. Is that a bug? | No. The PDF is a snapshot taken when it was generated; deleting does not rewrite a finished PDF. In the diary view and the photo viewer a trace shows in the photo’s place. |
| I uploaded a photo to the closed diary but the e-mail was not sent again. | By design: the e-mail does not repeat. The PDF’s new version is made the next time it is opened; the old one is kept. |
| I switched to “large image” but old PDFs are still small. | By design: the new setting only affects PDFs made from now on. |
| I cannot upload the photo although the box was there. | The box may have been switched off meanwhile, or you reached the count limit — see the error table in Upload a photo in the diary. |