fix: add docs for 10 commits starting from 8e75babe (2026-05-29) (#1009)

Author: lulululu-debug

docs/application/dynamic-client-registration.md

@@ -90,7 +90,12 @@ The registration endpoint itself requires no authentication—this is by design
 
 Applications created through DCR belong to the organization's admin account and appear in your application list with a `dcr` tag. This tag is not just a label: DCR-registered applications run under a restricted `app-dcr` role and can only reach the OAuth/OIDC endpoints they need for the login flow (`/api/login/oauth/*`, `/api/get-oauth-token`, `/api/userinfo`, `/api/get-application`). They cannot use the client credentials to call other management APIs, which limits the blast radius of a self-registered client.
 
-So that end users can actually sign in to a self-registered app, DCR-registered applications have password sign-in enabled and inherit the OAuth/OIDC providers and sign-in methods of the organization's default application.
+So that end users can actually sign in to a self-registered app, DCR-registered applications have password sign-in enabled and inherit a set of fields from the organization's default application:
+
+- **Providers and sign-in methods** — so there is at least one working sign-in method out of the box.
+- **Branding** — the logo (only when the request omits `logo_uri`), theme, footer HTML, and form CSS, so the login page matches the rest of the organization.
+- **Sign-in items** — the same sign-in form layout as the default application.
+- **`EnableSigninSession` and `EnableWebAuthn`** — the default application's session and WebAuthn settings.
 
 Client secrets never expire by default, but you can revoke any application through the admin interface at any time. For production deployments, consider whether your organization actually needs unauthenticated registration. Many scenarios work fine with manual app creation, and leaving DCR disabled removes a potential abuse vector.
 

docs/application/overview.md

@@ -16,3 +16,9 @@ Application configuration is flexible:
 - Customize sign-up fields and sign-in options per application
 
 This section walks you through creating and configuring your first application.
+
+## Partial updates with the `columns` parameter
+
+`/api/update-application` accepts an optional `columns` query parameter to perform a **partial update**: only the listed fields are written, and every other field on the application is left untouched. Omit it (or leave it empty) to update the full application object.
+
+Field names in `columns` may be written in either **camelCase** or **snake_case** — both are accepted and map to the same underlying column. For example, `columns=displayName,logo` and `columns=display_name,logo` are equivalent.

docs/application/signup-items-table.md

@@ -41,6 +41,10 @@ Items that support **rules**: ID, Display name, Email, Agreement, Languages.
 Example: to show an email field without verification, add the Email signup item and set its rule to **No verification**.
 :::
 
+:::note
+The **Tag** signup item adds a drop-down that lets the user pick their own [tag](/docs/application/tags) during registration. It is hidden by default; make it **Visible** to show it. The options come from the item's own **Options** if set, otherwise from the application's **Tags**. A tag the user selects here takes priority over the application's **Default tag**, which is only applied when the user does not choose one.
+:::
+
 ![Signup Items Table](/img/application/signup-items-table/signup-items-table-demo-config.png)
 
 ![Signup Items Table](/img/application/signup-items-table/signup-items-table-demo-page.png)

docs/application/terminology.md

@@ -28,6 +28,7 @@ The application edit page is split into eight tabs. Fields below are grouped by
 
 - **Cookie expire** — Session cookie lifetime in hours (default: 720). Without "Remember me", the session is capped at 24 h regardless.
 - **Default group** — Group automatically assigned to new users signing up through this application, including both direct sign-up and OAuth-based registration. Providers and invitations can override this per-signup: the effective group follows the priority **invitation SignupGroup > provider SignupGroup > application Default group**.
+- **Default tag** — Tag automatically assigned to new users who sign up through this application.
 - **Enable signup** — Allow self sign-up. When off, only admins can create accounts.
 - **Disable signin** — Disable all sign-in for this application.
 - **Enable guest signin** — Allow unauthenticated guest access by presenting `code=guest-user` to the token endpoint. Requires **Enable signup** to be on as well. Not available for the `built-in` organization. See [Guest authentication](/docs/how-to-connect/guest-auth).