@
Implements #109, and generalises it so the web/URL case falls out of the same mechanism.
The problem
Every mapping today is source element -> destination field: a rule matches content in the document, text comes out, it is written (coerced for number/date).
brochurePdf is not that. Nothing in the PDF content is captured. The value is a fact about the import itself: which file the editor picked in the Create from Source picker. The URL case for web imports is the same shape, with sourceUrl instead of mediaUnique.
So this is a second kind of mapping source: import facts, alongside captured content.
Current blockers
DestinationStructureService maps Umbraco.MediaPicker3 -> mediaPicker (line ~463) but TextMappableTypes (line ~36) does not contain it, so the field is classified and then dropped. brochurePdf never reaches the Destination tab.
map.json has no way to express a source that is not an element ID.
- The apply pass never writes it.
Not a blocker
mediaUnique (the picked media key) is already on UmbUpDocModalValue and is already destructured in both bridge files (up-doc-action.ts:122, up-doc-collection-action.element.ts:155). It is currently used only as a guard and then discarded. The value is already in scope where it needs to be written.
Decisions taken
- Two sets, not one widened set.
TextMappableTypes keeps its name and meaning (filled by rules). A new set covers types fillable from import facts. A type may appear in both (a URL goes into a plain text field), so eligibility is "in either set", and the mapping records which kind it is.
DestinationField must carry the distinction so the Destination tab picker offers "the source file" rather than the list of extracted elements.
- Adding
mediaPicker cannot pollute the Extracted tab - that view is built from source rules, and destination.json has no influence on it.
MediaPicker3 value shape
Confirmed against real content in the mirror (TailoredTravel.Web/uSync/v17/Content/ttm5063.config):
[
{
"key": "a2ad1a8b-b304-4cf0-a145-20938c8f9890",
"mediaKey": "d155485a-76a9-4d33-935c-146469ed9087",
"mediaTypeAlias": "umbracoMediaArticle",
"crops": [],
"focalPoint": null
}
]
key is a fresh GUID per picker entry; mediaKey is the media item. mediaTypeAlias varies per media item and must be resolved, not hardcoded.
Scope
URL/web targets use the same mechanism and follow once the PDF case is proven.
Notes
@
Implements #109, and generalises it so the web/URL case falls out of the same mechanism.
The problem
Every mapping today is source element -> destination field: a rule matches content in the document, text comes out, it is written (coerced for
number/date).brochurePdfis not that. Nothing in the PDF content is captured. The value is a fact about the import itself: which file the editor picked in the Create from Source picker. The URL case for web imports is the same shape, withsourceUrlinstead ofmediaUnique.So this is a second kind of mapping source: import facts, alongside captured content.
Current blockers
DestinationStructureServicemapsUmbraco.MediaPicker3->mediaPicker(line ~463) butTextMappableTypes(line ~36) does not contain it, so the field is classified and then dropped.brochurePdfnever reaches the Destination tab.map.jsonhas no way to express a source that is not an element ID.Not a blocker
mediaUnique(the picked media key) is already onUmbUpDocModalValueand is already destructured in both bridge files (up-doc-action.ts:122,up-doc-collection-action.element.ts:155). It is currently used only as a guard and then discarded. The value is already in scope where it needs to be written.Decisions taken
TextMappableTypeskeeps its name and meaning (filled by rules). A new set covers types fillable from import facts. A type may appear in both (a URL goes into a plaintextfield), so eligibility is "in either set", and the mapping records which kind it is.DestinationFieldmust carry the distinction so the Destination tab picker offers "the source file" rather than the list of extracted elements.mediaPickercannot pollute the Extracted tab - that view is built from source rules, anddestination.jsonhas no influence on it.MediaPicker3 value shape
Confirmed against real content in the mirror (
TailoredTravel.Web/uSync/v17/Content/ttm5063.config):[ { "key": "a2ad1a8b-b304-4cf0-a145-20938c8f9890", "mediaKey": "d155485a-76a9-4d33-935c-146469ed9087", "mediaTypeAlias": "umbracoMediaArticle", "crops": [], "focalPoint": null } ]keyis a fresh GUID per picker entry;mediaKeyis the media item.mediaTypeAliasvaries per media item and must be resolved, not hardcoded.Scope
mediaPickerDestinationFieldmap.jsonURL/web targets use the same mechanism and follow once the PDF case is proven.
Notes
dist/updoc.jsafter TS changes.@