Merge branch 'master' into macos-vfs-update

.github/workflows/openapi.yml

@@ -20,7 +20,7 @@ jobs:
           persist-credentials: false
 
       - name: Set up php
-        uses: shivammathur/setup-php@44454db4f0199b8b9685a5d763dc37cbf79108e1 # v2.36.0
+        uses: shivammathur/setup-php@accd6127cb78bee3e8082180cb391013d204ef9f # v2.37.0
         with:
           php-version: '8.1'
           # https://docs.nextcloud.com/server/stable/admin_manual/installation/source_installation.html#prerequisites-for-manual-installation

_shared_assets/static/custom.css

@@ -2,6 +2,16 @@
  * FIX THE DESIGN OF THE RTD THEME
  */
 
+body,
+h1,
+h2,
+h3,
+h4,
+h5,
+h6 {
+	font-family: system-ui, -apple-system, "Segoe UI", Roboto, Oxygen-Sans, Cantarell, Ubuntu, "Helvetica Neue", "Noto Sans", "Liberation Sans", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
+}
+
 /* NC blue */
 .wy-side-nav-search {
 	background-color: #0082c9;

admin_manual/configuration_files/encryption_details.rst

@@ -2,7 +2,7 @@
 Server-side encryption details
 ==============================
 
-This document - provided by `SysEleven <https://syseleven.de>`_ - describes the server-side encryption scheme implemented by Nextcloud's default encryption module. This includes:
+This document describes the server-side encryption scheme implemented by Nextcloud's default encryption module. This includes:
 
 - the encryption and signature of files with a master key.
 - the encryption and signature of files with a public sharing key.

admin_manual/configuration_files/primary_storage.rst

@@ -34,7 +34,7 @@ Data Backup and Recovery Implications
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 One impact of using an object store as Primary Storage is that your data backup strategy 
-needs to incorporate this. **Your data is longer stored on your Nextcloud server, but your 
+needs to incorporate this. **Your data is no longer stored on your Nextcloud server, but your 
 files are also no longer accessible by simply bypassing your Nextcloud server and accessing 
 your object store directly.**
 

admin_manual/configuration_server/config_sample_php_parameters.rst

@@ -3653,7 +3653,7 @@ minimum.supported.desktop.version
 
 ::
 
-	'minimum.supported.desktop.version' => '3.1.50',
+	'minimum.supported.desktop.version' => '3.1.81',
 
 Specify the minimum Nextcloud desktop client version allowed to sync with this
 server. Connections from earlier clients will be denied. Defaults to the
@@ -3662,7 +3662,7 @@ minimum officially supported version at the time of this server release.
 Changing this may cause older, unsupported clients to malfunction, potentially
 leading to data loss or unexpected behavior.
 
-Defaults to ``3.1.50``
+Defaults to ``3.1.81``
 
 maximum.supported.desktop.version
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

admin_manual/configuration_user/profile_configuration.rst

@@ -1,73 +1,282 @@
 .. _profile:
 
-=====================
-Profile configuration
-=====================
+========
+Profiles
+========
 
-The user profile presents the information of a user and is enabled by default
-for all users. Users may individually enable or disable their profile in their
-Personal info settings under the Personal settings section.
+The user profile displays information about an account.
+Profiles are enabled by default.
 
-As an administrator you may change the default for new users and may also
-disable profile globally to remove all profile functionality.
+Users can enable or disable their own profile in **Personal settings** under
+**Personal info**.
 
-Profile properties are also written into the :ref:`system address book<system-address-book>`.
+As an administrator, you can:
 
-.. note:: If not disabled, the profile is publicly visible.
-  The visibility of the individual profile attributes can be either controlled
-  by the assigned visibility scopes (e.g. "Private" will disable public access),
-  or by the user defined profile visibility.
+- set the default profile state for new users, and
+- disable profiles globally.
+
+Profile data can also be used by other features (for example the
+:ref:`system address book<system-address-book>`), but what is exposed depends
+on privacy controls.
+
+.. note::
+   Profile visibility is layered.
+
+   - **Profile enablement** determines if the profile feature is active at all.
+   - **Profile field visibility settings** control whether a field is shown.
+   - **Account property scopes** (for example ``private``, ``local``, ``federated``,
+     ``published``) define the intended audience for each property.
+   - **Discovery restrictions** (for example sharing/autocomplete enumeration rules)
+     can further reduce what other accounts can find or see.
+
+   In short: effective visibility is the most restrictive result of all applicable controls.
 
 Configuration
 -------------
 
-To enable or disable profile by default for new users switch the toggle in
-Basic settings under the Administration settings section.
+Set the profile default for new users
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In **Administration settings** -> **Basic settings**, use the profile default toggle.
 
 .. figure:: ../images/profile_default_setting.png
 
-You may also run the ``occ`` command below instead to change the default to ``false``:
+You can also set this via ``occ``:
 
 ::
 
   occ config:app:set settings profile_enabled_by_default --value="0"
 
-Please refer to :doc:`../occ_command` for all available
-``occ`` commands.
+Use ``--value="1"`` to enable it by default again.
 
-To disable profile globally add the following line to your ``config.php``
+See :doc:`../occ_command` for more ``occ`` usage details.
+
+Disable profiles globally
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To disable profile functionality for all users, add this to ``config.php``:
 
 ::
 
   'profile.enabled' => false,
 
-Please refer to :doc:`../configuration_server/config_sample_php_parameters` for
-all available ``config.php`` options.
+Profile field visibility settings
+---------------------------------
+
+Each profile field has its own **profile visibility** setting (stored per user in the
+profile configuration):
+
+- **Show to everyone** (``show``): visible to anyone, including unauthenticated visitors,
+  *subject to the field's property scope*.
+- **Show to logged in accounts only** (``show_users_only``): visible only to authenticated
+  users, *subject to the field's property scope*.
+- **Hide** (``hide``): never shown on profile surfaces regardless of property scope.
+
+These correspond to the visibility options in **Personal settings** -> **Personal info**
+-> **Edit your Profile visibility**.
+
+.. important::
+   Effective visibility is the most restrictive result of **both** controls:
+   the profile visibility setting and the property scope.
+
+Defaults
+^^^^^^^^
+
+By default, most profile fields are configured as **Show to everyone**, while some
+contact-related fields default to **Show to logged in accounts only**.
+
+Administrators should note that these defaults are independent from the default
+*property scopes* described below.
 
 .. _profile-property-scopes:
 
-Property scopes
----------------
+Property visibility scopes
+--------------------------
 
-User properties (Full name, Address, Website, Role, …) have specific visibility scopes (Private, Local, Federated, Published).
+User properties (Display name, Address, Website, Role, etc.) have visibility scopes:
+Private, Local, Federated, Published.
 
-The visibility scopes are explained below:
+These scopes are evaluated per attribute. A profile being reachable does not imply
+that all its attributes are visible.
+
+The visibility scopes are:
 
 :Private:
-  Contact details visible locally only
-:Local:
-  Contact details visible locally and through public link access on local instance
-:Federated:
-  Contact details visible locally, through public link access and on trusted federated servers.
-:Published:
-  Contact details visible locally, through public link access, on trusted federated servers and published to the public lookup server.
+  The most restrictive level. Data is hidden from public profiles, federation, and
+  public lookup. On the local server, it is only shown in specific features and
+  typically only to authenticated users who have a recognized relationship with the
+  account owner (for example, as a known contact).
 
-The default values for each property for each new user is listed below, but you should consult the declaration of the ``DEFAULT_SCOPES`` constant in the ``OC\Accounts\AccountManager`` class (`see the code <https://github.com/nextcloud/server/blob/master/lib/private/Accounts/AccountManager.php>`_) to make sure these are up-to-date.
+:Local:
+  Contact details visible on the local instance and in some public contexts where
+  profile/account attributes are required (for example owner/uploader metadata).
+  Not shared to federated servers and not published to the public lookup server.
+
+:Federated:
+  Contact details visible on the local instance, in relevant public contexts,
+  and on trusted federated servers.
+
+:Published:
+  Contact details visible on the local instance, in relevant public contexts,
+  on trusted federated servers, and published to the public lookup server.
+
+.. note::
+   **Public lookup server**: a public directory used to find users across Nextcloud instances.
+   Only profile fields marked Published may be exposed there.
+
+.. note::
+   Not all fields are eligible for lookup publication even if their scope is set to
+   ``Published``. Some fields are intentionally never published (for example Biography,
+   Headline, Organisation, Role, Birthdate).
+
+   In other words: ``Published`` is necessary but not always sufficient for lookup publication.
+
+.. important::
+   A reachable profile does not mean all attributes are public. Each attribute is
+   filtered by its own scope, and effective visibility can also depend on the
+   consuming feature.
+
+.. important::
+   On profile surfaces, the effective visibility is the more restrictive of
+   profile-visibility settings and property scope.
+
+Scope visibility matrix
+^^^^^^^^^^^^^^^^^^^^^^^
+
++------------+-------------------+-------------------------------------------------------+--------------------------------------+---------------------+----------------------+
+| Scope      | User themself [1] | Other users on same local instance                    | Public contexts (feature-dependent)  | Trusted federation  | Public lookup server |
++============+===================+=======================================================+======================================+=====================+======================+
+| Private    | Yes               | Limited on profile surfaces:                          | No                                   | No                  | No                   |
+|            |                   | authenticated + known-user relation required [3]      |                                      |                     |                      |
++------------+-------------------+-------------------------------------------------------+--------------------------------------+---------------------+----------------------+
+| Local      | Yes               | Yes                                                   | Yes (where applicable) [2]           | No                  | No                   |
++------------+-------------------+-------------------------------------------------------+--------------------------------------+---------------------+----------------------+
+| Federated  | Yes               | Yes                                                   | Yes (where applicable) [2]           | Yes                 | No                   |
++------------+-------------------+-------------------------------------------------------+--------------------------------------+---------------------+----------------------+
+| Published  | Yes               | Yes                                                   | Yes (where applicable) [2]           | Yes                 | Yes                  |
++------------+-------------------+-------------------------------------------------------+--------------------------------------+---------------------+----------------------+
+
+Notes:
+
+1. Scope primarily governs exposure to others; owner access follows account/endpoint behavior.
+2. Public-context visibility depends on feature path; scope alone does not guarantee display.
+3. Some non-profile surfaces may exclude Private-scoped properties entirely (for example
+   generated system address book cards), even for authenticated users.
+
+.. note::
+   The matrix describes **profile visibility behavior**. Other consuming features may apply
+   additional filtering and may not expose Private-scoped properties at all.
+
+Known-user rule for ``Private`` scope
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For ``Private`` properties, Nextcloud may allow visibility on specific local feature
+paths only when the requester is considered a *known user* of the target user.
+
+In practical terms, this relation is derived by server-side *known-contact matching*.
+In current Nextcloud versions this matching is primarily established via **phone-number
+matching** (for example through the Talk mobile contact integration), and it is directional
+(e.g., Alice might be known to Bob, but Bob isn't necessarily known to Alice).
+Users are always known to themselves.
+
+What local users can see
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+A common question is what one user can see about another user on the same instance.
+
+In general, profile visibility is controlled by each property's scope, but the
+exact UI/API surface depends on the consuming feature (for example profile page,
+share dialogs, search, mentions, Contacts, and other integrations).
+
+For local users on the same instance:
+
+- ``Private``: not generally visible to all local users; visibility is restricted
+  on applicable paths to authenticated users that satisfy the known-user relation
+  and other feature constraints.
+- ``Local``: visible on the local instance.
+- ``Federated``: visible on the local instance (and also shared with trusted federated servers).
+- ``Published``: visible on the local instance (and also federated + public lookup).
+
+.. note::
+   System address book exposure is scope-aware and context-aware:
+   private/empty-scope properties are excluded from generated cards, and
+   federated reads strip local-scoped properties.
+
+How to verify scope behavior
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Because effective visibility can vary by feature path, administrators should verify
+scope behavior in their own deployment.
+
+Recommended test procedure:
+
+1. Create test users:
+
+   - ``alice`` (target profile owner)
+   - ``bob`` (authenticated local user)
+   - ``charlie`` (second local user for control)
+
+2. As ``alice``, set distinct test values for profile fields and assign different
+   scopes where possible (for example Private vs Local via the UI, and Federated/Published
+   via API/administrative tooling if supported in your deployment).
+
+3. Verify as ``alice``:
+
+   - Confirm owner-visible values as expected.
+
+4. Verify as ``bob`` (authenticated local user):
+
+   - Check the feature paths used in your instance (for example profile page,
+     user card, share dialog, search, mentions, Contacts integrations).
+   - Confirm ``Local/Federated/Published`` fields are visible where expected.
+   - Confirm ``Private`` fields are visible only on paths that satisfy the known-user
+     relation and other feature constraints.
+
+5. Verify as unauthenticated user (private browser session):
+
+   - Confirm only public-appropriate fields are visible.
+
+6. Verify federation/publication behavior (if enabled):
+
+   - From a trusted federated server, confirm Federated/Published behavior.
+   - Confirm only Published fields are exposed to the public lookup server.
+
+7. Re-test with a newly created user after changing
+   ``account_manager.default_property_scope``:
+
+   - Confirm new defaults apply only to newly initialized accounts.
+   - Confirm existing users retain stored scopes unless explicitly changed.
+
+Scope defaults and precedence
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Visibility is determined per property using this order:
+
+1. **Server defaults** from ``OC\Accounts\AccountManager::DEFAULT_SCOPES``.
+2. **Administrator default override** via ``account_manager.default_property_scope``.
+3. **User-set value** in personal/profile settings (subject to server-side constraints).
+
+Practical implications:
+
+- Admin overrides in ``account_manager.default_property_scope`` are applied at account
+  initialization and therefore affect **new users**.
+- Existing users keep already stored scopes unless changed explicitly.
+- ``PROPERTY_DISPLAYNAME`` and ``PROPERTY_EMAIL`` cannot be ``Private``; server-side
+  validation/enforcement requires at least ``Local``.
+
+Default scope values (reference)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Default values are defined in server code and may change over time. The authoritative
+source is the ``DEFAULT_SCOPES`` constant in ``OC\Accounts\AccountManager``:
+`latest source <https://github.com/nextcloud/server/blob/master/lib/private/Accounts/AccountManager.php>`_.
+
+Example defaults (verify against your deployed version):
 
 +--------------+--------------------------+
 | Property     | Default visibility scope |
 +==============+==========================+
-| Full name    | Federated                |
+| Display name | Federated                |
 +--------------+--------------------------+
 | Address      | Local                    |
 +--------------+--------------------------+
@@ -81,6 +290,10 @@ The default values for each property for each new user is listed below, but you
 +--------------+--------------------------+
 | Twitter      | Local                    |
 +--------------+--------------------------+
+| Bluesky      | Local                    |
++--------------+--------------------------+
+| Fediverse    | Local                    |
++--------------+--------------------------+
 | Organisation | Local                    |
 +--------------+--------------------------+
 | Role         | Local                    |
@@ -89,14 +302,97 @@ The default values for each property for each new user is listed below, but you
 +--------------+--------------------------+
 | Biography    | Local                    |
 +--------------+--------------------------+
+| Birthdate    | Local                    |
++--------------+--------------------------+
+| Pronouns     | Federated                |
++--------------+--------------------------+
 
-If you'd like to override the value for one or several default visibility scopes, use the ``account_manager.default_property_scope`` ``config.php`` configuration key, which defaults to an empty array:
+Override default scopes in ``config.php``
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To override one or several default visibility scopes for *new users*, use
+``account_manager.default_property_scope`` (default: empty array):
 
 .. code-block:: php
 
   'account_manager.default_property_scope' => [
     \OCP\Accounts\IAccountManager::PROPERTY_PHONE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
-    \OCP\Accounts\IAccountManager::PROPERTY_ROLE => \OCP\Accounts\IAccountManager::SCOPE_FEDERATED
+    \OCP\Accounts\IAccountManager::PROPERTY_ROLE => \OCP\Accounts\IAccountManager::SCOPE_FEDERATED,
   ]
 
-In the above example, the phone and role properties are respectively overwritten to the private and federated scopes. Note that these changes will only apply to *new* users, not existing ones.
+In the above example, phone and role are overwritten to ``Private`` and
+``Federated`` respectively.
+
+.. note::
+   Use ``\OCP\Accounts\IAccountManager`` constants for both property keys and scope values.
+
+FAQ: How to lock profile visibility down
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+If your goal is maximum privacy:
+
+1. Disable profiles globally (strictest option):
+
+   .. code-block:: php
+
+     'profile.enabled' => false,
+
+   Effect:
+
+   - Profile functionality is removed.
+   - Profile-based discoverability/usability features are reduced accordingly.
+
+2. If profiles must remain enabled, set restrictive defaults for new users:
+
+   .. code-block:: php
+
+     'account_manager.default_property_scope' => [
+       \OCP\Accounts\IAccountManager::PROPERTY_ADDRESS => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_PHONE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_WEBSITE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_TWITTER => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_BLUESKY => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_FEDIVERSE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_ORGANISATION => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_ROLE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_HEADLINE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_BIOGRAPHY => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_BIRTHDATE => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_PRONOUNS => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+       \OCP\Accounts\IAccountManager::PROPERTY_AVATAR => \OCP\Accounts\IAccountManager::SCOPE_PRIVATE,
+     ]
+
+   Notes:
+
+   - ``PROPERTY_DISPLAYNAME`` and ``PROPERTY_EMAIL`` cannot be set to ``Private``; server-side enforcement requires at least ``Local``.
+   - Defaults apply to **new users**. Existing users keep stored scopes unless changed.
+
+What becomes limited when you lock it down?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+With more restrictive scopes (especially ``Private``), expect reduced visibility in:
+
+- User discovery/search/user cards
+- Share dialogs and mention/autocomplete context
+- Public/share-related contexts where account metadata may be shown
+- Federated visibility of profile attributes
+- Public lookup publication (only ``Published`` appears there)
+
+In short: tighter privacy reduces profile-based convenience and discoverability.
+
+.. TODO/Future additions
+   - Sharing settings + Mentions + Property Scope interactions (i.e. auto-completion, group/user-to-group/user sharing)
+   - Since default visibility scope changes only apply to new users, perhaps we can cover whether there's a migration path for existing users?
+   - better integrate (cross-link? separate out?) with chapters covering sharing and federation
+   - unify with User Manual
+   - Dev Manual coverage 
+   - better distinguish user facing profile field visibility settings from admin instance-level scope settings
+   - better "known user context" description
+   - better "public contexts" description
+   - better "lookup server" description/context
+      - https://github.com/nextcloud/lookup-server?tab=readme-ov-file#what-is-lookup-server
+      - https://github.com/nextcloud/lookup-server/blob/master/doc/architecture.md#overview
+   - better "varies by feature/UI/API/app" description
+   - more definite statements; more direct statements
+   - simplify simplify simplify
+

admin_manual/installation/nginx.rst

@@ -4,10 +4,7 @@
 NGINX configuration
 ===================
 
-.. note::
-    This page covers example NGINX configurations to run a Nextcloud server.
-    These configurations examples were originally provided by `@josh4trunks <https://github.com/josh4trunks>`_
-    and are exclusively community-maintained. (Thank you contributors!)
+This page covers how to run a Nextcloud server using NGINX backed by PHP-FPM, which is also an officially supported setup.
 
 - You need to insert the following code into **your Nginx configuration file**.
   Choose the appropriate example based on whether you are deploying :ref:`nginx_webroot_example` (i.e. :code:`https://cloud.example.com/`) or :ref:`nginx_subdir_example` (i.e. :code:`https://cloud.example.com/nextcloud`).

developer_manual/app_development/index.rst

@@ -12,4 +12,4 @@ App development
    init
    dependency_management
    dav_extension
-   translation_setup
+   translation

developer_manual/app_development/translation.rst

@@ -1,8 +1,8 @@
-.. _Translation setup:
+.. _Translation:
 
-=================
-Translation setup
-=================
+===========
+Translation
+===========
 
 Nextcloud's translation system is powered by `Transifex <https://explore.transifex.com/nextcloud/>`_. To start translating sign up and enter a group. If your community app should be translated by the `Nextcloud community on Transifex <https://explore.transifex.com/nextcloud/>`_ just follow the setup section below.
 
@@ -152,3 +152,28 @@ Now the following folder structure is available::
         |-- myapp.pot
 
 You then just need the :file:`.json` and :file:`.js` files for a working localized app.
+
+Documentation on the translation process
+----------------------------------------
+
+The following describes four processes:
+
+1. Process to translate new string
+
+.. image:: ../images/translation_process1.png
+   :alt: Process to translate new string
+
+2. Process to correct typo/grammar issue in translated string
+
+.. image:: ../images/translation_process2.png
+   :alt: Process to correct typo/grammar issue in translated string
+
+3. Process for making an untranslatable string translatable
+
+.. image:: ../images/translation_process3.png
+   :alt: Process for making an untranslatable string translatable
+
+4. Process to correct issue in source string
+
+.. image:: ../images/translation_process4.png
+   :alt: Process to correct issue in source string

developer_manual/basics/translations.rst

@@ -343,7 +343,7 @@ iOS
 Adding translations
 -------------------
 
-The steps how to set up translations for an app have been moved to it's own page in the "App development" chapter: :ref:`Translation setup`
+The steps how to set up translations for an app have been moved to it's own page in the "App development" chapter: :ref:`Translation`
 
 Testing translations
 --------------------

developer_manual/client_apis/ClientIntegration/index.rst

@@ -14,7 +14,7 @@ Supported clients
 
 Android: 3.36.0 and above
 
-Desktop: 4.1.0 and above
+Desktop: 33.0.0 and above
 
 iOS: 7.3.0 and above
 

developer_manual/client_apis/WebDAV/basic.rst

@@ -550,12 +550,18 @@ You can set some special headers that Nextcloud will interpret.
 Response Headers
 ----------------
 
-+-----------+------------------------------------------------+-----------------------------------------+
-|  Header   |                  Description                   |                 Example                 |
-+===========+================================================+=========================================+
-| OC-Etag   | | On creation, move and copy,                  | ``"50ef2eba7b74aa84feff013efee2a5ef"``  |
-|           | | the response contain the etag of the file.   |                                         |
-+-----------+------------------------------------------------+-----------------------------------------+
-| OC-FileId | | On creation, move and copy,                  | | Format: ``<padded-id><instance-id>``. |
-|           | | the response contain the fileid of the file. | | Example: ``00000259oczn5x60nrdu``     |
-+-----------+------------------------------------------------+-----------------------------------------+
++-------------------+-----------------------------------------------+-----------------------------------------+
+| Header            | Description                                   | Example                                 |
++===================+===============================================+=========================================+
+|| OC-Etag          || On creation, move and copy,                  || ``"50ef2eba7b74aa84feff013efee2a5ef"`` |
+||                  || the response contain the etag of the file.   ||                                        |
++-------------------+-----------------------------------------------+-----------------------------------------+
+|| OC-FileId        || On creation, move and copy,                  || Format: ``<padded-id><instance-id>``.  |
+||                  || the response contain the fileid of the file. || Example: ``00000259oczn5x60nrdu``      |
++-------------------+-----------------------------------------------+-----------------------------------------+
+|| X-NC-OwnerId     || On creation, the response contains the owner || Example: ``admin``                     |
+||                  || ID.                                          ||                                        |
++-------------------+-----------------------------------------------+-----------------------------------------+
+|| X-NC-Permissions || On creation, the response contains the       || Example: ``RGDNVW``                    |
+||                  || permissions string.                          ||                                        |
++-------------------+-----------------------------------------------+-----------------------------------------+

developer_manual/digging_deeper/index.rst

@@ -18,7 +18,7 @@ Digging deeper
    groupware/index
    http_client
    javascript-apis
-   translation
+   machinetranslation
    flow
    npm
    notifications

developer_manual/digging_deeper/machinetranslation.rst

@@ -1,4 +1,4 @@
-.. _translation:
+.. _machinetranslation:
 
 ===================
 Machine Translation

requirements.txt

@@ -1,7 +1,7 @@
 alabaster==1.0.0
 Babel==2.18.0
 certifi==2026.2.25
-charset-normalizer==3.4.4
+charset-normalizer==3.4.6
 docutils==0.21.2
 idna==3.11
 imagesize==1.4.1

static/css/styles.css

@@ -1,40 +1,6 @@
 
 /*---- General ----*/
 
-/* enable to reveal boxes everywhere  */
-/** {
-    border-style: solid;
-    border-color: red;
- }*/
-
-@font-face {
-    font-family: 'Open Sans';
-    font-style: normal;
-    font-weight: normal;
-    src: local('Open Sans'), local('OpenSans'), url(fonts/OpenSans-Regular.woff) format('woff'), url(fonts/OpenSans-Regular.ttf) format('ttf');
-}
-
-@font-face {
-    font-family: 'Open Sans';
-    font-style: normal;
-    font-weight: bold;
-    src: local('Open Sans Semibold'), local('OpenSans-Semibold'), url(fonts/OpenSans-Semibold.woff) format('woff'), url(fonts/OpenSans-Semibold.ttf) format('ttf');
-}
-
-@font-face {
-    font-family: 'Open Sans';
-    font-style: italic;
-    font-weight: normal;
-    src: local('Open Sans Italic'), local('OpenSans-Italic'), url(fonts/OpenSans-Italic.woff) format('woff'), url(fonts/OpenSans-Bold.ttf) format('ttf');
-}
-
-@font-face {
-    font-family: 'Open Sans';
-    font-style: normal;
-    font-weight: light;
-    src: local('Open Sans Light'), local('OpenSans-Light'), url(fonts/OpenSans-Light.woff) format('woff'), url(fonts/OpenSans-Light.ttf) format('ttf');
-}
-
 @font-face {
   font-family: 'Glyphicons Halflings';
 
@@ -54,7 +20,7 @@ span.avoidwrap {
 
 /* Make background white, font grey and default buttons a bit darker to compensate */
 body {
-    font-family: 'Open Sans', Frutiger, Calibri, 'Myriad Pro', Myriad, sans-serif !important;
+    font-family: system-ui, -apple-system, "Segoe UI", Roboto, Oxygen-Sans, Cantarell, Ubuntu, "Helvetica Neue", "Noto Sans", "Liberation Sans", Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
     color: #555;
     background: #fff;
 }

user_manual/groupware/contacts.rst

@@ -240,6 +240,10 @@ Team options
 
 Various self-explanatory options are available to configure a team, to manage invites and membership, visibility of the team, allowance of other team membership and password protection.
 
+**Prevent teams from being a member of another team**
+
+When this option is enabled, the team can no longer be directly added as a member of another team. However, this restriction only applies to new direct additions. Existing memberships are kept, and inherited memberships are still possible if this team belongs to a parent team that gets added elsewhere.
+
 Shared items
 ~~~~~~~~~~~~
 .. versionadded:: 5.5

user_manual/groupware/mail.rst

@@ -361,8 +361,6 @@ Quick actions
 -------------
 .. versionadded:: 5.5 (Nextcloud 30)
 
-.. figure:: images/mail_use-quick-actions.gif
-
 Allows you to group action steps that you would normally perform on envelopes such as tagging, moving, marking as read ... into quick actions that can be executed with a single click.
 Quick actions are scoped to one mail account and can be created and managed in the mail settings under "Quick actions" or directly from the envelope action menu.