Merge branch 'backstage:master' into tutorial

docs/features/software-templates/input-examples.md

@@ -26,6 +26,25 @@ parameters:
         ui:help: 'Hint: additional description...'
 ```
 
+#### Custom validation error message
+
+```yaml
+parameters:
+  - title: Fill in some steps
+    properties:
+      name:
+        title: Simple text input
+        type: string
+        description: Description about input
+        maxLength: 8
+        pattern: '^([a-zA-Z][a-zA-Z0-9]*)(-[a-zA-Z0-9]+)*$'
+        ui:autofocus: true
+        ui:help: 'Hint: additional description...'
+    errorMessage:
+      properties:
+        name: '1-8 alphanumeric tokens (first starts with letter) delimited by -'
+```
+
 ### Multi line text input
 
 ```yaml

docs/features/software-templates/writing-templates.md

@@ -533,6 +533,11 @@ catalogFilter:
     metadata.annotations.github.com/team-slug: { exists: true }
 ```
 
+#### Custom validation messages
+
+You may specify custom JSON Schema validation messages as supported by the
+[ajv-errors](https://github.com/ajv-validator/ajv-errors) plugin library to [ajv](https://github.com/ajv-validator/ajv).
+
 ## `spec.steps` - `Action[]`
 
 The `steps` is an array of the things that you want to happen part of this

docs/frontend-system/architecture/03-extensions.md

@@ -337,7 +337,7 @@ Similar to plugins the `ErrorBoundary` for extension allows to pass in a fallbac
 
 ### Analytics
 
-Analytics information are provided through the `AnalyticsContext`, which will give `extensionId` & `pluginId` as context to analytics event fired inside of the extension. Additionally `RouteTracker` will capture an analytics event for routable extension to inform which extension metadata gets associated with a navigation event when the route navigated to is a gathered `mountPoint`.
+Analytics information are provided through the `AnalyticsContext`, which will give `extensionId` & `pluginId` as context to analytics event fired inside of the extension. Additionally `RouteTracker` will capture an analytics event for routable extension to inform which extension metadata gets associated with a navigation event when the route navigated to is a gathered `mountPoint`. Whether an extension is routable is inferred from its outputs, but you can also explicitly control this behavior by passing the `routable` prop to `ExtensionBoundary`.
 
 The `ExtensionBoundary` can be used like the following in an extension creator:
 
@@ -359,7 +359,7 @@ export function createSomeExtension<
         path: config.path,
         routeRef: options.routeRef,
         element: (
-          <ExtensionBoundary node={node} routable>
+          <ExtensionBoundary node={node}>
             <ExtensionComponent />
           </ExtensionBoundary>
         ),

docs/frontend-system/architecture/08-naming-patterns.md

@@ -38,33 +38,31 @@ Note that while we use this naming pattern for the plugin instance this is only
 
 | Description | Pattern                         | Examples                                                            |
 | ----------- | ------------------------------- | ------------------------------------------------------------------- |
-| Creator     | `create<Kind>Extension`         | `createPageExtension`, `createEntityCardExtension`                  |
+| Blueprint   | `<Kind>Blueprint`               | `PageBlueprint`, `EntityCardBlueprint`                              |
 | ID          | `[<kind>:]<namespace>[/<name>]` | `'core.nav'`, `'page:user-settings'`, `'entity-card:catalog/about'` |
 | Symbol      | `<namespace>[<Name>][<Kind>]`   | `coreNav`, `userSettingsPage`, `catalogAboutEntityCard`             |
 
-When you create a new extension you never provide the ID directly. Instead, you indirectly or directly provide the kind, namespace, and name parts that make up the ID. The kind is always provided by the extension creator function used to create the extension, the only exception is if you use `createExtension` directly. Any extension that is provided by a plugin will by default have its namespace set to the plugin ID, so you generally only need to provide an explicit namespace if you want to override an existing extension. The name is also optional, and primarily used to distinguish between multiple extensions of the same kind and namespace. If a plugin doesn't need to distinguish between different extensions of the same kind, the name can be omitted.
+When you create a new extension you never provide the ID directly. Instead, you indirectly or directly provide the kind, namespace, and name parts that make up the ID. The kind is always provided by the blueprint creator, the only exception is if you use `createExtension` directly. Any extension that is provided by a plugin will by default have its namespace set to the plugin ID, so you generally only need to provide an explicit namespace if you want to override an existing extension. The name is also optional, and primarily used to distinguish between multiple extensions of the same kind and namespace. If a plugin doesn't need to distinguish between different extensions of the same kind, the name can be omitted.
 
 Example:
 
 ```ts
-// This is an extension creator that is used to create an extension of the 'page' kind.
-export function createPageExtension(options) {
-  return createExtension({
-    kind: 'page', // Kinds are kebab-case
-    // ...options
-  });
-}
+// This is an extension blueprint that is used to create an extension of the 'page' kind.
+export const PageBlueprint = createExtensionBlueprint({
+  kind: 'page',
+  // ...
+});
 
 // The namespace is inferred from the plugin ID, in this case 'catalog'
 // The final ID for this extension will be 'page:catalog/entity'
-const catalogEntityPage = createPageExtension({
+const catalogEntityPage = PageBlueprint.make({
   name: 'entity',
   // ...
 });
 
 // The name is omitted, because the catalog plugin only provides a single extension of this kind
 // The final ID for this extension will be 'search-result-list-item:catalog'
-const catalogSearchResultListItem = createSearchResultListItemExtension({
+const catalogSearchResultListItem = SearchResultListItemBlueprint.make({
   // ...
 });
 

docs/integrations/azure/org.md

@@ -111,6 +111,17 @@ microsoftGraphOrg:
       search: '"description:One" AND ("displayName:Video" OR "displayName:Drive")'
 ```
 
+If you don't want to only ingest groups matching the `search` and/or `filter` query, but also the groups which are members of the matched groups, you can use the `includeSubGroups` configuration:
+
+```yaml
+microsoftGraphOrg:
+  providerId:
+    group:
+      filter: securityEnabled eq false and mailEnabled eq true and groupTypes/any(c:c+eq+'Unified')
+      search: '"description:One" AND ("displayName:Video" OR "displayName:Drive")'
+      includeSubGroups: true
+```
+
 In addition to these groups, one additional group will be created for your organization.
 All imported groups will be a child of this group.