@vertigis/viewer-spec 58.9.0 → 58.10.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/LICENSE CHANGED
@@ -1,5 +1,5 @@
1
- VertiGIS North America Ltd. ("VERTIGIS NA") hereby grants You, free of charge, a personal, non-exclusive, nontransferable, license to access and use this software and associated documentation files (the "Software") for development purposes only. You shall not deploy the Software into production or use for revenue generating purposes. If You wish to deploy the Software into production, then the use of the Software shall be governed by VERTIGIS NA's Master License Agreement, which can be found at www.geocortex.com/legal and shall supersede all other terms of use.
2
-
3
- You shall include copyright and this permission notice in all copies or works involving the Software.
4
-
1
+ VertiGIS North America Ltd. ("VERTIGIS NA") hereby grants You, free of charge, a personal, non-exclusive, nontransferable, license to access and use this software and associated documentation files (the "Software") for development purposes only. You shall not deploy the Software into production or use for revenue generating purposes. If You wish to deploy the Software into production, then the use of the Software shall be governed by VERTIGIS NA's Master License Agreement, which can be found at www.geocortex.com/legal and shall supersede all other terms of use.
2
+
3
+ You shall include copyright and this permission notice in all copies or works involving the Software.
4
+
5
5
  You acknowledge and agree that Software is provided AS IS and that VERTIGIS NA makes no representations and expressly disclaims any and all warranties of any kind, express or implied, including, but not limited to, any warranties regarding merchantability, fitness for a particular purpose, and noninfringement of intellectual property. In no event shall VERTIGIS NA be liable for any claim, damages, or other liability, whether in contract, tort, or other causes of action, arising from, out of, or in connection with the Software or use or other dealings with the Software. You shall bear all risk and liability regarding Your use of the Software and expressly acknowledge and agree that Your use of the Software is at Your own risk. You shall comply with all applicable laws.
package/README.md CHANGED
@@ -1,3 +1,3 @@
1
- # VertiGIS Viewer Specification
2
-
3
- This package contains specifications for app config JSON, layout XML, and a reference of all commands, operations, and events for VertiGIS Studio Web and Mobile. For more information on extending these products, visit our [Developer Center](https://developers.vertigisstudio.com).
1
+ # VertiGIS Viewer Specification
2
+
3
+ This package contains specifications for app config JSON, layout XML, and a reference of all commands, operations, and events for VertiGIS Studio Web and Mobile. For more information on extending these products, visit our [Developer Center](https://developers.vertigisstudio.com).
@@ -0,0 +1,15 @@
1
+ import type { Geocoder, GeocoderProperties } from "@vertigis/arcgis-extensions/tasks/geocoding/Geocoder";
2
+ import type { ServiceModelProperties } from "../common/ServiceModelProperties";
3
+ /**
4
+ * Properties that can be passed into the constructor for GeocodersService.
5
+ */
6
+ export interface GeocodersModelProperties extends ServiceModelProperties {
7
+ /**
8
+ * Contains all configured geocoders.
9
+ */
10
+ geocoders?: (Geocoder | GeocoderProperties)[];
11
+ /**
12
+ * A subset of geocoders to be used for geocode operations.
13
+ */
14
+ activeGeocoders: (Geocoder | GeocoderProperties)[];
15
+ }
@@ -0,0 +1 @@
1
+ export{};
@@ -1,311 +1,311 @@
1
- # VertiGIS Studio Apps
2
-
3
- ## Introduction
4
-
5
- A VertiGIS Studio App is a JSON document containing configuration for an application
6
- that is built on top of the ArcGIS Extensions API. Building on the Esri Web Map
7
- Specification, VertiGIS Studio Apps enable a declarative approach to working with the
8
- VertiGIS and Esri APIs. Rather than initializing the properties of API objects
9
- programmatically in code, you can define all of their settings externally in an
10
- App JSON document. Then, you can access the configured objects via the
11
- `AppContainer` class. Here is an example VertiGIS Studio App containing a map
12
- extension and a menu:
13
-
14
- ```
15
- {
16
- "schemaVersion": "1.0",
17
- "items": [
18
- {
19
- "$type": "map-extension",
20
- "id": "default",
21
- "title": "LA County",
22
- "webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
23
- },
24
- {
25
- "$type": "menu",
26
- "id": "i-want-to",
27
- "items": [
28
- {
29
- "id": "zoom-in",
30
- "title": "Zoom In"
31
- },
32
- {
33
- "id": "zoom-out",
34
- "title": "Zoom Out"
35
- }
36
- ]
37
- }
38
- ]
39
- }
40
- ```
41
-
42
- In code, you would then access the items defined in this App like so:
43
-
44
- ```
45
- const appJson = ... // Load the JSON from somewhere.
46
- const container = new AppContainer(appJson);
47
- const mapX = await container.get("map-extension", "default");
48
- const iwtm = await container.get("menu", "i-want-to");
49
- ```
50
-
51
- With the exception of a few special App properties like `$type`, the JSON for
52
- each item uses the same schema that is supported by the constructor for the
53
- corresponding API object. For example, this produces the same end result as the
54
- above code:
55
-
56
- ```
57
- const mapX = new MapExtension({
58
- "id": "default",
59
- "title": "LA County",
60
- "webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
61
- });
62
- const iwtm = new Menu({
63
- "id": "i-want-to",
64
- "items": [
65
- {
66
- "id": "zoom-in",
67
- "title": "Zoom In"
68
- },
69
- {
70
- "id": "zoom-out",
71
- "title": "Zoom Out"
72
- }
73
- ]
74
- });
75
- ```
76
-
77
- ## App Items
78
-
79
- The `items` property of an App contains the set of configured items for an
80
- application (order is irrelevant). At minimum, each item must have `id` and
81
- `$type` properties (see [ItemType](apidoc://ItemType/ItemType) for a list of
82
- default supported types). The combination of type and ID must be unique within
83
- an App. This means that you are permitted to have two items with an ID of
84
- `"default"`, but only if they are of different types. IDs must consist of only
85
- [unreserved URI characters](https://tools.ietf.org/html/rfc3986).
86
-
87
- Any remaining properties on an item that do not start with "\$" are its
88
- configured settings, and vary based on the type of item. For example, the map
89
- extension's `"title"` property in the previous example. These properties will
90
- get passed in to the appropriate [item factory](#Custom-Item-Types) for that
91
- item type.
92
-
93
- ### Item URIs
94
-
95
- Items in an App can be uniquely identified via URIs that use a special `item://`
96
- scheme, like so:
97
-
98
- ```
99
- item://<type>/<id>
100
- ```
101
-
102
- The AppContainer class allows retrieving an item via its `item://` URI:
103
-
104
- ```
105
- const mapX = await container.get("item://map-extension/default");
106
- ```
107
-
108
- ### Item References
109
-
110
- The property values for an item can reference other items, using `item://` URIs.
111
- For example:
112
-
113
- ```
114
- items: [
115
- {
116
- "$type": "layer-extension",
117
- "id": "incidents",
118
- "layer": {
119
- "layerType": "ArcGISFeatureLayer",
120
- "url": "http://sampleserver6.arcgisonline.com/arcgis/rest/services/SF311/FeatureServer/0"
121
- }
122
- },
123
- {
124
- $type: "map-extension",
125
- id: "default",
126
- layerExtensions: [
127
- "item://layer-extension/incidents"
128
- ]
129
- }
130
- ]
131
- ```
132
-
133
- When the `item://map-extension/default` item is requested from the AppContainer,
134
- it will first create the `item://layer-extension/incidents` object that it
135
- references, and then substitute it in place of the reference prior to creating
136
- the map extension.
137
-
138
- **NOTE**: Regardless of how many times an item is requested or referenced by
139
- other items, only a single object instance is ever created per unique item.
140
-
141
- ### Custom Item Types
142
-
143
- By default, AppContainer is pre-configured to understand the various items types
144
- that are built in the ArcGIS Extensions API, e.g. MapExtension and Menu. However, you
145
- can work with custom item types in an App by registering custom item factories
146
- with AppContainer. An item factory is just a method that takes item
147
- configuration and produces an actual object. For more information, see
148
- [AppContainer.registerType()](apidoc://AppContainer.registerType).
149
-
150
- You can also override the built-in factories for ArcGIS Extensions API items with your
151
- own factories to customize how these items are created.
152
-
153
- ## Settings
154
-
155
- An App may contain a `settings` block at the top level, which is a place to
156
- define custom, application-wide settings as a set of key/value pairs. The key is
157
- a unique name for the setting, and the value is a simple scalar value (string,
158
- boolean, or number).
159
-
160
- ```
161
- {
162
- "schemaVersion": "1.0",
163
- "settings": {
164
- "baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest/",
165
- "defaultMaxResults": 300
166
- }
167
- }
168
- ```
169
-
170
- Settings can be accessed programmatically via the
171
- [AppContainer.settings](apidoc://AppContainer.settings) property. Setting values
172
- can also be referenced within an App by using a special URI syntax:
173
-
174
- ```
175
- setting://<setting-name>.
176
- ```
177
-
178
- Whenever an item’s property has a value like this, the configuration loader will
179
- substitute it for the actual setting value. This is useful when a setting is
180
- used by more than one item in an App, as it gives you a single place to change
181
- it. You can also insert a setting’s value into a string property or other
182
- settings, by surrounding the `setting://` URI with `{}` characters within a
183
- string. For example:
184
-
185
- ```
186
- {
187
- "schemaVersion": "1.0",
188
- "settings": {
189
- "baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest"
190
- },
191
- items: [
192
- {
193
- "$type": "layer-extension",
194
- "id": "hurricanes",
195
- "layer": {
196
- "layerType": "ArcGISMapServiceLayer",
197
- "url": "{setting://baseServiceUrl}/services/Hurricanes/MapServer"
198
- }
199
- }
200
- ]
201
- }
202
- ```
203
-
204
- ## Failure Modes
205
-
206
- By default, when one item references another and the referenced item cannot be
207
- created, then the original item cannot be created either. In this case an error
208
- will occur when you attempt to get the original item from the App container. You
209
- can adjust this behavior by defining a custom failure mode for an item in the
210
- top-level `failureModes` property. This property maps an `item://` URI to the
211
- failure mode value for that item. Possible values are `"error"`, `"warn"`, and
212
- `"ignore"`, with `"error"` being the default. For example:
213
-
214
- ```
215
- {
216
- "schemaVersion": "1.0",
217
- items: [
218
- {
219
- "$type": "layer-extension",
220
- "id": "broken",
221
- "layer": {
222
- "url": "invalid URL"
223
- }
224
- },
225
- {
226
- $type: "map-extension",
227
- id: "default",
228
- layerExtensions: [
229
- "item://layer-extension/broken"
230
- ]
231
- }
232
- ],
233
- "failureModes": [
234
- "item://layer-extension/broken": "warn"
235
- ]
236
- }
237
- ```
238
-
239
- In this example, the item `item://layer-extension/broken` contains an invalid
240
- URL, and so it cannot be created. Normally this would mean that
241
- `item://map-extension/default` couldn't be created either, but because of the
242
- configured failure mode of `"warn"` for the layer extension, the map extension
243
- can still be created. The AppContainer will remove the invalid URI prior to
244
- creating the map extension, and will raise a special `configWarning` event
245
- containing details about the item that could not be created. In this case, the
246
- host application should handle this event by warning the end user about the
247
- missing layer.
248
-
249
- Failure modes are also passed on to the item factories. This means that objects
250
- that are created by the AppContainer can also respond to failure modes. For
251
- example, MapExtension will honor a layer extension's failure mode if the layer
252
- fails to load successfully (e.g. the map service is currently unavailable). The
253
- exact behavior depends on the type of object.
254
-
255
- ## App Imports
256
-
257
- An App can import one or more other Apps via the top-level `import` block. This
258
- is a list of one or more URLs pointing to other Apps to import, like so:
259
-
260
- ```
261
- {
262
- "schemaVersion": "1.0",
263
- "import": [
264
- "http://some.company.com/apps/default-basemaps.app.json",
265
- "default-layers.app.json"
266
- ]
267
- }
268
- ```
269
-
270
- When an App imports another one, the items, settings, failure modes, etc.
271
- defined in the referenced app become part of the current App, as though they had
272
- been defined inline.
273
-
274
- If the current App contains one or more items that also appear in the imported
275
- App, then the items' properties are merged, with locally defined property values
276
- overriding imported ones. Similarly, locally defined settings and failure modes
277
- override ones that are imported. If multiple Apps are imported, then content
278
- from Apps that appear later in the list of imports will override the content of
279
- earlier ones.
280
-
281
- An imported App can itself contain App imports. In that case, those inner imports
282
- are resolved first, and the resulting App is then imported into the outer one.
283
-
284
- ## Importing Apps from Portal
285
-
286
- It is possible to import Apps from a portal instance by using one of the
287
- following URI patterns:
288
-
289
- - portal://<portal-id>/<item-id>
290
- - portal://<item-id>
291
-
292
- The first version (with _portal-id_) can be used when you want to specify the
293
- portal instance where the item is located. In order for this portal:// URI to
294
- successfully be resolved, you must associate _portal-id_ with an instance of
295
- @arcgis/core/portal/Portal. This can be done using the _portals_ map in
296
- @vertigis/arcgis-extensions/config.
297
-
298
- You can import App configuration from a portal instance like this:
299
-
300
- ```
301
- {
302
- "schemaVersion": "1.0",
303
- "import": [
304
- "portal://test-portal/abcdef0123456789abcdef0123456789,
305
- ]
306
- }
307
- ```
308
-
309
- If the imported configuration has any further imports in form
310
- portal://<item-id>, these will be changed to use the _portal-id_ of the parent
311
- App.
1
+ # VertiGIS Studio Apps
2
+
3
+ ## Introduction
4
+
5
+ A VertiGIS Studio App is a JSON document containing configuration for an application
6
+ that is built on top of the ArcGIS Extensions API. Building on the Esri Web Map
7
+ Specification, VertiGIS Studio Apps enable a declarative approach to working with the
8
+ VertiGIS and Esri APIs. Rather than initializing the properties of API objects
9
+ programmatically in code, you can define all of their settings externally in an
10
+ App JSON document. Then, you can access the configured objects via the
11
+ `AppContainer` class. Here is an example VertiGIS Studio App containing a map
12
+ extension and a menu:
13
+
14
+ ```
15
+ {
16
+ "schemaVersion": "1.0",
17
+ "items": [
18
+ {
19
+ "$type": "map-extension",
20
+ "id": "default",
21
+ "title": "LA County",
22
+ "webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
23
+ },
24
+ {
25
+ "$type": "menu",
26
+ "id": "i-want-to",
27
+ "items": [
28
+ {
29
+ "id": "zoom-in",
30
+ "title": "Zoom In"
31
+ },
32
+ {
33
+ "id": "zoom-out",
34
+ "title": "Zoom Out"
35
+ }
36
+ ]
37
+ }
38
+ ]
39
+ }
40
+ ```
41
+
42
+ In code, you would then access the items defined in this App like so:
43
+
44
+ ```
45
+ const appJson = ... // Load the JSON from somewhere.
46
+ const container = new AppContainer(appJson);
47
+ const mapX = await container.get("map-extension", "default");
48
+ const iwtm = await container.get("menu", "i-want-to");
49
+ ```
50
+
51
+ With the exception of a few special App properties like `$type`, the JSON for
52
+ each item uses the same schema that is supported by the constructor for the
53
+ corresponding API object. For example, this produces the same end result as the
54
+ above code:
55
+
56
+ ```
57
+ const mapX = new MapExtension({
58
+ "id": "default",
59
+ "title": "LA County",
60
+ "webMap": "b6c7a4a9eb5a4954a0d284c6c53537d2"
61
+ });
62
+ const iwtm = new Menu({
63
+ "id": "i-want-to",
64
+ "items": [
65
+ {
66
+ "id": "zoom-in",
67
+ "title": "Zoom In"
68
+ },
69
+ {
70
+ "id": "zoom-out",
71
+ "title": "Zoom Out"
72
+ }
73
+ ]
74
+ });
75
+ ```
76
+
77
+ ## App Items
78
+
79
+ The `items` property of an App contains the set of configured items for an
80
+ application (order is irrelevant). At minimum, each item must have `id` and
81
+ `$type` properties (see [ItemType](apidoc://ItemType/ItemType) for a list of
82
+ default supported types). The combination of type and ID must be unique within
83
+ an App. This means that you are permitted to have two items with an ID of
84
+ `"default"`, but only if they are of different types. IDs must consist of only
85
+ [unreserved URI characters](https://tools.ietf.org/html/rfc3986).
86
+
87
+ Any remaining properties on an item that do not start with "\$" are its
88
+ configured settings, and vary based on the type of item. For example, the map
89
+ extension's `"title"` property in the previous example. These properties will
90
+ get passed in to the appropriate [item factory](#Custom-Item-Types) for that
91
+ item type.
92
+
93
+ ### Item URIs
94
+
95
+ Items in an App can be uniquely identified via URIs that use a special `item://`
96
+ scheme, like so:
97
+
98
+ ```
99
+ item://<type>/<id>
100
+ ```
101
+
102
+ The AppContainer class allows retrieving an item via its `item://` URI:
103
+
104
+ ```
105
+ const mapX = await container.get("item://map-extension/default");
106
+ ```
107
+
108
+ ### Item References
109
+
110
+ The property values for an item can reference other items, using `item://` URIs.
111
+ For example:
112
+
113
+ ```
114
+ items: [
115
+ {
116
+ "$type": "layer-extension",
117
+ "id": "incidents",
118
+ "layer": {
119
+ "layerType": "ArcGISFeatureLayer",
120
+ "url": "http://sampleserver6.arcgisonline.com/arcgis/rest/services/SF311/FeatureServer/0"
121
+ }
122
+ },
123
+ {
124
+ $type: "map-extension",
125
+ id: "default",
126
+ layerExtensions: [
127
+ "item://layer-extension/incidents"
128
+ ]
129
+ }
130
+ ]
131
+ ```
132
+
133
+ When the `item://map-extension/default` item is requested from the AppContainer,
134
+ it will first create the `item://layer-extension/incidents` object that it
135
+ references, and then substitute it in place of the reference prior to creating
136
+ the map extension.
137
+
138
+ **NOTE**: Regardless of how many times an item is requested or referenced by
139
+ other items, only a single object instance is ever created per unique item.
140
+
141
+ ### Custom Item Types
142
+
143
+ By default, AppContainer is pre-configured to understand the various items types
144
+ that are built in the ArcGIS Extensions API, e.g. MapExtension and Menu. However, you
145
+ can work with custom item types in an App by registering custom item factories
146
+ with AppContainer. An item factory is just a method that takes item
147
+ configuration and produces an actual object. For more information, see
148
+ [AppContainer.registerType()](apidoc://AppContainer.registerType).
149
+
150
+ You can also override the built-in factories for ArcGIS Extensions API items with your
151
+ own factories to customize how these items are created.
152
+
153
+ ## Settings
154
+
155
+ An App may contain a `settings` block at the top level, which is a place to
156
+ define custom, application-wide settings as a set of key/value pairs. The key is
157
+ a unique name for the setting, and the value is a simple scalar value (string,
158
+ boolean, or number).
159
+
160
+ ```
161
+ {
162
+ "schemaVersion": "1.0",
163
+ "settings": {
164
+ "baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest/",
165
+ "defaultMaxResults": 300
166
+ }
167
+ }
168
+ ```
169
+
170
+ Settings can be accessed programmatically via the
171
+ [AppContainer.settings](apidoc://AppContainer.settings) property. Setting values
172
+ can also be referenced within an App by using a special URI syntax:
173
+
174
+ ```
175
+ setting://<setting-name>.
176
+ ```
177
+
178
+ Whenever an item’s property has a value like this, the configuration loader will
179
+ substitute it for the actual setting value. This is useful when a setting is
180
+ used by more than one item in an App, as it gives you a single place to change
181
+ it. You can also insert a setting’s value into a string property or other
182
+ settings, by surrounding the `setting://` URI with `{}` characters within a
183
+ string. For example:
184
+
185
+ ```
186
+ {
187
+ "schemaVersion": "1.0",
188
+ "settings": {
189
+ "baseServiceUrl": "http://sampleserver6.arcgisonline.com/arcgis/rest"
190
+ },
191
+ items: [
192
+ {
193
+ "$type": "layer-extension",
194
+ "id": "hurricanes",
195
+ "layer": {
196
+ "layerType": "ArcGISMapServiceLayer",
197
+ "url": "{setting://baseServiceUrl}/services/Hurricanes/MapServer"
198
+ }
199
+ }
200
+ ]
201
+ }
202
+ ```
203
+
204
+ ## Failure Modes
205
+
206
+ By default, when one item references another and the referenced item cannot be
207
+ created, then the original item cannot be created either. In this case an error
208
+ will occur when you attempt to get the original item from the App container. You
209
+ can adjust this behavior by defining a custom failure mode for an item in the
210
+ top-level `failureModes` property. This property maps an `item://` URI to the
211
+ failure mode value for that item. Possible values are `"error"`, `"warn"`, and
212
+ `"ignore"`, with `"error"` being the default. For example:
213
+
214
+ ```
215
+ {
216
+ "schemaVersion": "1.0",
217
+ items: [
218
+ {
219
+ "$type": "layer-extension",
220
+ "id": "broken",
221
+ "layer": {
222
+ "url": "invalid URL"
223
+ }
224
+ },
225
+ {
226
+ $type: "map-extension",
227
+ id: "default",
228
+ layerExtensions: [
229
+ "item://layer-extension/broken"
230
+ ]
231
+ }
232
+ ],
233
+ "failureModes": [
234
+ "item://layer-extension/broken": "warn"
235
+ ]
236
+ }
237
+ ```
238
+
239
+ In this example, the item `item://layer-extension/broken` contains an invalid
240
+ URL, and so it cannot be created. Normally this would mean that
241
+ `item://map-extension/default` couldn't be created either, but because of the
242
+ configured failure mode of `"warn"` for the layer extension, the map extension
243
+ can still be created. The AppContainer will remove the invalid URI prior to
244
+ creating the map extension, and will raise a special `configWarning` event
245
+ containing details about the item that could not be created. In this case, the
246
+ host application should handle this event by warning the end user about the
247
+ missing layer.
248
+
249
+ Failure modes are also passed on to the item factories. This means that objects
250
+ that are created by the AppContainer can also respond to failure modes. For
251
+ example, MapExtension will honor a layer extension's failure mode if the layer
252
+ fails to load successfully (e.g. the map service is currently unavailable). The
253
+ exact behavior depends on the type of object.
254
+
255
+ ## App Imports
256
+
257
+ An App can import one or more other Apps via the top-level `import` block. This
258
+ is a list of one or more URLs pointing to other Apps to import, like so:
259
+
260
+ ```
261
+ {
262
+ "schemaVersion": "1.0",
263
+ "import": [
264
+ "http://some.company.com/apps/default-basemaps.app.json",
265
+ "default-layers.app.json"
266
+ ]
267
+ }
268
+ ```
269
+
270
+ When an App imports another one, the items, settings, failure modes, etc.
271
+ defined in the referenced app become part of the current App, as though they had
272
+ been defined inline.
273
+
274
+ If the current App contains one or more items that also appear in the imported
275
+ App, then the items' properties are merged, with locally defined property values
276
+ overriding imported ones. Similarly, locally defined settings and failure modes
277
+ override ones that are imported. If multiple Apps are imported, then content
278
+ from Apps that appear later in the list of imports will override the content of
279
+ earlier ones.
280
+
281
+ An imported App can itself contain App imports. In that case, those inner imports
282
+ are resolved first, and the resulting App is then imported into the outer one.
283
+
284
+ ## Importing Apps from Portal
285
+
286
+ It is possible to import Apps from a portal instance by using one of the
287
+ following URI patterns:
288
+
289
+ - portal://<portal-id>/<item-id>
290
+ - portal://<item-id>
291
+
292
+ The first version (with _portal-id_) can be used when you want to specify the
293
+ portal instance where the item is located. In order for this portal:// URI to
294
+ successfully be resolved, you must associate _portal-id_ with an instance of
295
+ @arcgis/core/portal/Portal. This can be done using the _portals_ map in
296
+ @vertigis/arcgis-extensions/config.
297
+
298
+ You can import App configuration from a portal instance like this:
299
+
300
+ ```
301
+ {
302
+ "schemaVersion": "1.0",
303
+ "import": [
304
+ "portal://test-portal/abcdef0123456789abcdef0123456789,
305
+ ]
306
+ }
307
+ ```
308
+
309
+ If the imported configuration has any further imports in form
310
+ portal://<item-id>, these will be changed to use the _portal-id_ of the parent
311
+ App.