Photos

Every photo captured anywhere on a project lands in one place: the project photo library at /admin/photos. Prestart photos, diary photos, docket and materials photos, alert and issue photos, and direct uploads all share the same library, the same filters and the same viewer.

Views

The library has a single tab bar, driven from the admin sidebar:

• Map — every geotagged photo on the project, plotted as a pin.
• All, and one tab per source — Prestart, Diary, Docket, Materials, Alert, Issues, Uploads — the paged grid, narrowed to that source.

Map is a view, not a source, so it is never combined with a source tab. The grid is paged; the map is not — every geotagged photo matching the filters is a pin, whatever page its grid tile would sit on.

Filtering

The filter row sits above the tabs and applies to whichever view is open.

Date range. The range filters on the date the photo was taken, falling back to the date it was uploaded when the camera did not record a capture date. This is the same date the grid sorts by, the same date the mobile gallery groups its headings by, and the same date the map shows on a pin — so a photo taken last month and uploaded today answers to last month everywhere.

The end date includes its own whole day. A range ending 29 July includes photos taken at any time on 29 July, not just at midnight.

Dates resolve in the project’s own timezone, not in UTC and not in the timezone of whoever is looking. A photo taken at 4 pm on site belongs to that day for everyone — the person on site, the office in another state, and the printed report. The same rule sets the day headings in the gallery, the date on a map pin, and the time shown on the photo itself.

Photos taken before this change are read the same way. A photo’s day is worked out from its capture time each time it is looked at, rather than stored when the photo lands, so older photos move onto the project’s day too — some shift to the neighbouring day heading, in almost every case onto the day they were actually taken.

Taken by. Narrow the library to one person’s photos. The list offers everyone currently on the project; choosing Anyone clears it. A photo taken by someone who has since left the project is still in the library and still opens normally — it simply is not offered in the list.

Albums. Selecting one album shows the photos in it. Selecting more than one shows photos in any of them — widening, not narrowing. The control says so on screen: Albums — any of.

Tags. Selecting one tag shows photos carrying it. Selecting more than one shows only photos carrying all of them — narrowing, not widening. The control says so too: Tags — all of. The list offers the tags actually in use on the project’s photos, so it never offers a category nobody has used, and a photo tagged before the categories existed is still findable under its own tag.

The two filters deliberately work in opposite directions, which is why each states its own on screen. Albums are curated collections, so a photo is rarely in two at once and asking for “in this album and that one” would almost always return nothing. Tags describe a photo, so a photo carries several at once and asking for “carrying this and that” is the useful question.

Search. The box at the start of the toolbar matches the photo’s description. It deliberately does not match file names or tags, so every result is explainable: each photo shown contains what was typed, somewhere in its description. A photo nobody has described never matches. Search narrows the grid, the count and page numbers below it, and the map, together.

The search, the date range, the tags, the albums and the person who took the photo apply identically to the grid and the map, so the two views never disagree about which photos exist.

On the phone, the same Taken By and Albums filters sit in the Filters sheet on both the photo gallery and the photo map. Search is on the web library only.

The photo itself

Opening a photo — from the grid, from a pin, or from the phone — shows the large image alongside what is known about it: when it was taken, where it came from, who uploaded it, its dimensions and its file size.

Description. Under those details is a description: free text, in your own words, for whatever the photo needs said about it. Type into it and click away — it saves, and it is what the search box matches. Clearing the text and clicking away clears the description. The description survives everything else you do to the photo: marking it up, tagging it, reverting an annotation.

The two report surfaces that show photos without tags — prestart alerts and the drug and alcohol report — show no description field either.

Comments. In the photo library, on the web and on the phone, a photo carries its own comment thread. Post a comment and it appears for anyone else with that photo open, without them refreshing. You can delete your own comments; full-access roles can delete anyone’s.

Photos opened from inside another record — a docket, a diary, a prestart — have no comment thread of their own. That record already has one, and two threads on one screen is a confusion rather than a feature.

Photo tag categories

Each project keeps its own list of photo tag categories, set under the gear beside Upload on the photo library. A project starts with an empty list — the categories are the ones you type, in the words your project uses. Rename them, add to them, or retire the ones you no longer want offered. The list belongs to the project, and nothing in the product behaves differently for one name over another.

Tag entry decides how tags get onto a photo, and it is set per project:

• Anyone can create tags — people pick from the list and can also type a tag that is not on it yet.
• Only the categories below — the list is the whole vocabulary. Anything else is refused, and the message names the word that was refused.

The same list and the same rule apply everywhere a photo is tagged: the viewer in the office, the photo gallery on the phone, and the photo map on the phone.

Retiring a category stops it being offered. Photos already carrying it keep the label, still appear under it in the filter, and none of them is deleted. Switching a project to Only the categories below does not strip tags that are already on photos either — it only decides what can be added from then on. A photo that carries an older value keeps it and stays fully editable: only a value that is new to that photo has to be on the list.

A project needs at least one category before it can be switched to Only the categories below, since switching with an empty list would leave nobody able to tag anything. For the same reason, the last remaining category cannot be retired while the project is on Only the categories below — switch tag entry back to Anyone can create tags first.

Setting the categories and the tag entry mode needs the Manage photo tag categories permission. Everyone on the project keeps seeing the list and tagging photos as before.

Working on several photos at once

Select photos in the grid and a single toolbar appears above them, showing how many are selected, with Clear beside the count.

Tags are added and removed; there is no “set the tags” action. Adding a tag to fifty photos keeps every tag each of them already had, and removing a tag takes only that one and leaves the rest. Because every action is add-or-remove rather than replace, two people tagging the same photos at the same time cannot overwrite each other’s work.

The Add list offers the project’s configured tag categories, so it never offers a value the project would refuse. It appears once the project has at least one category configured — a project starts with an empty list, so until somebody sets the categories up under the gear beside Upload (see Photo tag categories above, which needs Manage photo tag categories), the toolbar carries no Add control at all. The album actions and Delete are unaffected. On projects set to Anyone can create tags, a brand-new tag is still invented on a single photo in the viewer — the bulk list stays the configured categories, because inventing a spelling once and stamping it on fifty photos is how a tag list fills with near-duplicates.

The Remove list offers the tags actually in use, including older values and retired categories, so anything that is on a photo can be taken off it. It appears once at least one tag is in use somewhere on the project — with nothing tagged there is nothing to take off.

If some of the selected photos could not be updated, the confirmation says how many — photos the person is not permitted to see are counted, never silently skipped.

Up to 100 photos at a time. Select more than that and the toolbar says so and the actions wait until the selection is back under the limit.

Adding and removing photos from albums works from the same toolbar — see Albums below.

Edit on the same toolbar changes the description of every selected photo at once, with Undo on the result — see Bulk Edit & Undo.

Deleting selected photos. A photo on a published prestart or a published drug & alcohol report can’t be deleted, one at a time or in a selection. If the selection holds one, nothing is deleted and the message says why — take that photo out of the selection and delete again. Deleting a photo on a drug & alcohol report also needs the permission to manage those reports.

Map

Each geotagged photo is a pin. Clicking a pin opens the photo full size in the viewer — the large image, its tags, who uploaded it, the file name and the location — without leaving the map. Closing the viewer returns to the map with the same pins and the same filters.

Photos without GPS coordinates never appear on the map. That is a property of the photo, not the filter: a photo captured with location services off carries no coordinates to plot.

The timeline strip

As soon as two or more photos with a capture time are in the map frame, a timeline appears along the bottom of the map. Each thumbnail sits at the time the photo was taken, so two shots an hour apart sit close together and a shot three days later sits far to the right. A short line drops from each thumbnail to a dot on the scale below: that dot is the photo’s exact moment. Where a thumbnail had to be nudged sideways to avoid an overlap, the line visibly slants — so where a photo sits is never mistaken for when it was taken.

The scale relabels itself as the frame changes, from hours across a single afternoon to months across a whole year.

Clusters

Photos taken close together in time stack into one tile with a count on it. Clicking the stack lists every photo in it with its time. Panning or zooming closes that list, because the stack it belonged to no longer exists.

The project’s clock

Times and days on the timeline are the project’s local time — the same clock the date filter and the gallery’s day headings use, not your computer’s. A supervisor in another state reads the same day for a photo as the person who took it.

Photos with no capture time

Some cameras record no capture time, and some photos arrive with it stripped. Those photos are never given a position on the timeline — the product does not invent a time it does not have. They sit in a No date tray at the right of the strip. Open the tray to see them; they open and page exactly like any other photo.

If everything in the frame is undated there is no timeline at all, just a line saying how many photos are there with no capture time.

What the strip is, and what it is not

The strip shows what is currently in the map frame. Panning or zooming changes it. It is a way of reading the map, not another filter: the filter row above still decides which photos exist on the map at all, and the register export follows the filter row, not the map frame — the same way an export ignores which page of the gallery you happen to be on.

A single photo

One photo in the frame gets a small card with its day and its time, not a timeline. A single photo does not earn a timeline.

Moving the map

The map frames itself around the photos once when you open it, and once again whenever you change a filter or switch to another project — a new filter is a new question, and it shows you the answer. After you pan or zoom, it stays exactly where you put it.

Albums

An album is a named collection of photos on a project — “Pre-Pour Inspections”, “Week 12 Progress”. They sit under Photos → Albums, and the table there lists each album with the number of photos in it, who created it and when.

A photo can be in as many albums as it belongs in. One shot can sit in Pre-Pour Inspections and Week 12 Progress at the same time; putting it in the second does not take it out of the first. Albums are a way of collecting photos, not a place they are filed.

Photos are added to and removed from albums; there is no “set the albums” action. Select photos in the gallery, pick an album, then Add to album or Remove from album. Because every action is add-or-remove rather than replace, two people curating the same photos at the same time cannot overwrite each other’s work.

If some of the selected photos could not be added, the confirmation says how many — photos already in the album, and photos the person adding them is not permitted to see, are counted rather than silently skipped.

Removing a photo from an album deletes nothing. The photo stays in the gallery and in every other album it belongs to.

Deleting an album deletes no photos. The album disappears from the table and from the filter; every photo that was in it is still in the library and still in any other album it belongs to.

Album counts are per viewer: the number shown is the photos in that album the person looking is allowed to see. Someone restricted to their own uploads sees a count of their own photos, not the album’s full size.

Creating, renaming and deleting an album, and adding or removing photos, require the Manage photo albums permission. Everyone who can see a photo can filter by album — that needs no extra permission. Album membership is read from the album’s own view, not from the individual photo.

On the phone, albums are a filter only. Album curation is office work and stays on the web.

Who sees what

The library is scoped to the current project, and within it to whatever photo scope the org’s permission matrix grants the viewer — everything on the project, or only their own uploads, or only the photos hanging off records they supervise, or only the photos on dockets they are a worker on. See Avenues, Tiers & Scope for how a scope is granted.

That scope is applied identically to the grid, the map and the viewer, so a pin can never open a photo the viewer could not otherwise see.

Exporting the register

The Export XLSX button on the photo library toolbar produces a spreadsheet of the photos currently on screen — the same filters, the same tab. The export runs in the background: a job appears under Photos → Exports as Pending and becomes Completed on its own, with nothing to refresh.

The sheet has one row per photo and eight columns: date taken, albums, description, comments, file name, GPS latitude, GPS longitude, tags. A photo that sits in two albums shows both album names in one cell, comma-separated — it never occupies two rows, so the number of rows in the sheet always matches the number of photos on screen. A photo in no album shows an empty album cell, and a photo with no GPS leaves both coordinate cells empty rather than reading as a location it was never taken at. The date taken is the project’s own calendar day, the same day the date filter and the grid headings use.

Pressing Export again with the same filters returns the export you already have rather than starting a second one.

Exports are kept for 30 days and then removed. Deleting an export removes the file immediately; the photos themselves are untouched, and you can always export again.

If an export fails

A failed export — a spreadsheet or a photo download — shows the reason on its row (hover the status for it) and has a Retry button. Retry runs it again with the same filters, or the same photos, and the new export takes the failed one’s place.

An export never sits on Pending or Running for long:

• Each export runs on its own. Deleting a Pending or Running export stops it, and exporting the same filters again always starts a fresh one.
• An export that is still running is left to finish — up to 30 minutes for a spreadsheet, an hour for a photo download.
• An export that has stopped is marked failed within about 10 minutes.

An export belongs to whoever asked for it. The Exports list shows your own jobs only, and a colleague’s export cannot be opened, downloaded or deleted by anyone else — even by someone who can export. That is not tidiness: the sheet contains exactly the photos you can see, so handing the finished file to a colleague would hand them rows their own access excludes. Two people who need the same spreadsheet each press Export.

The register contains no images and no links to images — it is a data register.

Who can export. Exporting is a project permission (Export photo register), granted by default to master admins, organisational managers, project admins and engineers. It is an office action: a field worker from a subcontractor organisation can see and tag these photos in the app but cannot export the register, because the export is issued from the head contractor’s organisation.