Summary
Uploading a picture into the "Extra picture" slot of a case can never succeed, on any page — routed or dialog. This is independent of the dialog case-id bug in #8031 (that issue threads a caseId down the shared chain; this one is not fixable from the frontend at all).
Why it cannot work today
The extra-picture slot and the upload endpoint are shaped for two different tables.
Extra pictures are ExtraFieldValue rows, which have no field id. eform-sdk/eFormCore/Infrastructure/Data/Entities/ExtraFieldValue.cs is keyed by CaseId + CheckListId + FieldTypeId:
public int? CaseId; public int? CheckListId; public int? CheckListDuplicateId;
public int? CheckListValueId; public int? UploadedDataId; public string FieldType; public int FieldTypeId;
There is no FieldId column.
The SDK never populates FieldId on the way out. eFormCore/Infrastructure/SqlController.cs:1817-1826 maps ExtraFieldValue → Models.FieldValue setting only Heading, Latitude, Longitude, Altitude, Accuracy, DateOfDoing, Value (plus UploadedDataObj for the picture branch). Models.FieldValue.FieldId (eFormCore/Infrastructure/Models/DataItem.cs:718) is a non-nullable int left at its default. CasesService.Read returns that ReplyElement straight to the client, so every entry in element.extraPictures serializes with fieldId: 0.
The upload endpoint requires a real field. EFormFilesController.AddNewImage (eFormAPI.Web/Controllers/Eforms/EFormFilesController.cs:271-278) resolves sdkDbContext.Fields.Where(x => x.Id == fieldId) and returns CaseNotFound when field == null. It then constructs a FieldValue { FieldId, CaseId, CheckListId, WorkerId, ... } — a FieldValue row, not an ExtraFieldValue row. Field id 0 never matches.
Do not "fix" this by binding fieldId in the template
case-edit-element.component.html renders the extra-picture <element-picture> without [fieldId]. That looks like an oversight and is tempting to patch, but binding the available value (0) makes things strictly worse: element-picture.component.html:1 gates the whole card on *ngIf="fieldId != 0". Today fieldId is undefined and undefined != 0 is truthy, so the card renders and existing thumbnails are visible. Binding 0 would make the entire extra-picture card disappear, taking already-uploaded images with it.
This was investigated and deliberately not done while fixing #8031; the [caseId] binding added there is correct and harmless but not sufficient on its own.
What a real fix needs
A server-side path that writes an ExtraFieldValue rather than a FieldValue, keyed by (caseId, checkListId, fieldTypeId) instead of fieldId — either a new endpoint or a parameterised mode on AddNewImage — plus a matching frontend call that passes that context. Touches eFormAPI.Web and probably eform-sdk. Needs a product decision on whether extra-picture upload from the web UI is actually wanted before anyone builds it.
Worth confirming first
How reachable this is in practice: extra pictures appear to be populated by device/app submissions, and it is not established that anyone has ever successfully added one from the web UI. If the answer is "the slot should be read-only on web", the correct fix is to hide the add-button rather than build the endpoint — much cheaper. Establish that before implementing.
Summary
Uploading a picture into the "Extra picture" slot of a case can never succeed, on any page — routed or dialog. This is independent of the dialog case-id bug in #8031 (that issue threads a
caseIddown the shared chain; this one is not fixable from the frontend at all).Why it cannot work today
The extra-picture slot and the upload endpoint are shaped for two different tables.
Extra pictures are
ExtraFieldValuerows, which have no field id.eform-sdk/eFormCore/Infrastructure/Data/Entities/ExtraFieldValue.csis keyed byCaseId+CheckListId+FieldTypeId:There is no
FieldIdcolumn.The SDK never populates
FieldIdon the way out.eFormCore/Infrastructure/SqlController.cs:1817-1826mapsExtraFieldValue→Models.FieldValuesetting onlyHeading, Latitude, Longitude, Altitude, Accuracy, DateOfDoing, Value(plusUploadedDataObjfor the picture branch).Models.FieldValue.FieldId(eFormCore/Infrastructure/Models/DataItem.cs:718) is a non-nullableintleft at its default.CasesService.Readreturns thatReplyElementstraight to the client, so every entry inelement.extraPicturesserializes withfieldId: 0.The upload endpoint requires a real field.
EFormFilesController.AddNewImage(eFormAPI.Web/Controllers/Eforms/EFormFilesController.cs:271-278) resolvessdkDbContext.Fields.Where(x => x.Id == fieldId)and returnsCaseNotFoundwhenfield == null. It then constructs aFieldValue { FieldId, CaseId, CheckListId, WorkerId, ... }— aFieldValuerow, not anExtraFieldValuerow. Field id0never matches.Do not "fix" this by binding fieldId in the template
case-edit-element.component.htmlrenders the extra-picture<element-picture>without[fieldId]. That looks like an oversight and is tempting to patch, but binding the available value (0) makes things strictly worse:element-picture.component.html:1gates the whole card on*ngIf="fieldId != 0". TodayfieldIdisundefinedandundefined != 0is truthy, so the card renders and existing thumbnails are visible. Binding0would make the entire extra-picture card disappear, taking already-uploaded images with it.This was investigated and deliberately not done while fixing #8031; the
[caseId]binding added there is correct and harmless but not sufficient on its own.What a real fix needs
A server-side path that writes an
ExtraFieldValuerather than aFieldValue, keyed by(caseId, checkListId, fieldTypeId)instead offieldId— either a new endpoint or a parameterised mode onAddNewImage— plus a matching frontend call that passes that context. ToucheseFormAPI.Weband probablyeform-sdk. Needs a product decision on whether extra-picture upload from the web UI is actually wanted before anyone builds it.Worth confirming first
How reachable this is in practice: extra pictures appear to be populated by device/app submissions, and it is not established that anyone has ever successfully added one from the web UI. If the answer is "the slot should be read-only on web", the correct fix is to hide the add-button rather than build the endpoint — much cheaper. Establish that before implementing.