deploy: 4af654f0da

latest/openid.html

@@ -633,6 +633,8 @@ This can be optionally enabled by setting <code>backchannel_logout_enabled</code
 <li>JWT Algorithm: RS256 within the security menu of the new Relying Parties
 (<code>Options &gt; Security &gt; ID Token signature algorithm</code> and <code>Options &gt; Security &gt; Access Token signature algorithm</code>)</li>
 <li>Scopes: OpenID, Email and Profile</li>
+<li>Force claims into <code>id_token</code>
+(<code>Options &gt; Advanced &gt; Force claims to be returned in ID Token</code>)</li>
 <li>Allowed redirection addresses for login (<code>Options &gt; Basic &gt; Allowed redirection addresses for login</code> ) :
 <code>[synapse public baseurl]/_synapse/client/oidc/callback</code></li>
 </ul>

latest/postgres.html

@@ -349,25 +349,17 @@ new line, it is inserted before:</p>
 <pre><code>host    all         all             ::1/128     ident
 </code></pre>
 <h3 id="fixing-incorrect-collate-or-ctype"><a class="header" href="#fixing-incorrect-collate-or-ctype">Fixing incorrect <code>COLLATE</code> or <code>CTYPE</code></a></h3>
-<p>Synapse will refuse to set up a new database if it has the wrong values of
-<code>COLLATE</code> and <code>CTYPE</code> set. Synapse will also refuse to start an existing database with incorrect values
-of <code>COLLATE</code> and <code>CTYPE</code> unless the config flag <code>allow_unsafe_locale</code>, found in the 
-<code>database</code> section of the config, is set to true. Using different locales can cause issues if the locale library is updated from
-underneath the database, or if a different version of the locale is used on any
-replicas.</p>
+<p>Synapse will refuse to start when using a database with incorrect values of
+<code>COLLATE</code> and <code>CTYPE</code> unless the config flag <code>allow_unsafe_locale</code>, found in the
+<code>database</code> section of the config, is set to true. Using different locales can
+cause issues if the locale library is updated from underneath the database, or
+if a different version of the locale is used on any replicas.</p>
 <p>If you have a database with an unsafe locale, the safest way to fix the issue is to dump the database and recreate it with
 the correct locale parameter (as shown above). It is also possible to change the
 parameters on a live database and run a <code>REINDEX</code> on the entire database,
 however extreme care must be taken to avoid database corruption.</p>
 <p>Note that the above may fail with an error about duplicate rows if corruption
 has already occurred, and such duplicate rows will need to be manually removed.</p>
-<h3 id="fixing-inconsistent-sequences-error"><a class="header" href="#fixing-inconsistent-sequences-error">Fixing inconsistent sequences error</a></h3>
-<p>Synapse uses Postgres sequences to generate IDs for various tables. A sequence
-and associated table can get out of sync if, for example, Synapse has been
-downgraded and then upgraded again.</p>
-<p>To fix the issue shut down Synapse (including any and all workers) and run the
-SQL command included in the error message. Once done Synapse should start
-successfully.</p>
 
                     </main>
 

latest/print.html

@@ -862,25 +862,17 @@ new line, it is inserted before:</p>
 <pre><code>host    all         all             ::1/128     ident
 </code></pre>
 <h3 id="fixing-incorrect-collate-or-ctype"><a class="header" href="#fixing-incorrect-collate-or-ctype">Fixing incorrect <code>COLLATE</code> or <code>CTYPE</code></a></h3>
-<p>Synapse will refuse to set up a new database if it has the wrong values of
-<code>COLLATE</code> and <code>CTYPE</code> set. Synapse will also refuse to start an existing database with incorrect values
-of <code>COLLATE</code> and <code>CTYPE</code> unless the config flag <code>allow_unsafe_locale</code>, found in the 
-<code>database</code> section of the config, is set to true. Using different locales can cause issues if the locale library is updated from
-underneath the database, or if a different version of the locale is used on any
-replicas.</p>
+<p>Synapse will refuse to start when using a database with incorrect values of
+<code>COLLATE</code> and <code>CTYPE</code> unless the config flag <code>allow_unsafe_locale</code>, found in the
+<code>database</code> section of the config, is set to true. Using different locales can
+cause issues if the locale library is updated from underneath the database, or
+if a different version of the locale is used on any replicas.</p>
 <p>If you have a database with an unsafe locale, the safest way to fix the issue is to dump the database and recreate it with
 the correct locale parameter (as shown above). It is also possible to change the
 parameters on a live database and run a <code>REINDEX</code> on the entire database,
 however extreme care must be taken to avoid database corruption.</p>
 <p>Note that the above may fail with an error about duplicate rows if corruption
 has already occurred, and such duplicate rows will need to be manually removed.</p>
-<h3 id="fixing-inconsistent-sequences-error"><a class="header" href="#fixing-inconsistent-sequences-error">Fixing inconsistent sequences error</a></h3>
-<p>Synapse uses Postgres sequences to generate IDs for various tables. A sequence
-and associated table can get out of sync if, for example, Synapse has been
-downgraded and then upgraded again.</p>
-<p>To fix the issue shut down Synapse (including any and all workers) and run the
-SQL command included in the error message. Once done Synapse should start
-successfully.</p>
 <div style="break-before: page; page-break-before: always;"></div><h1 id="using-a-reverse-proxy-with-synapse"><a class="header" href="#using-a-reverse-proxy-with-synapse">Using a reverse proxy with Synapse</a></h1>
 <p>It is recommended to put a reverse proxy such as
 <a href="https://nginx.org/en/docs/http/ngx_http_proxy_module.html">nginx</a>,
@@ -1842,7 +1834,7 @@ v1.61.0.</p>
 <tr><td>v1.85.0 – v1.91.2</td><td>v1.83.0</td></tr>
 <tr><td>v1.92.0 – v1.97.0</td><td>v1.90.0</td></tr>
 <tr><td>v1.98.0 – v1.105.0</td><td>v1.96.0</td></tr>
-<tr><td>v1.105.1 – v1.108.0</td><td>v1.100.0</td></tr>
+<tr><td>v1.105.1 – v1.109.0</td><td>v1.100.0</td></tr>
 </tbody></table>
 <h2 id="upgrading-from-a-very-old-version"><a class="header" href="#upgrading-from-a-very-old-version">Upgrading from a very old version</a></h2>
 <p>You need to read all of the upgrade notes for each version between your current
@@ -7714,6 +7706,32 @@ Set a size to change the default.</li>
     min_batch_size: 10
     default_batch_size: 50
 </code></pre>
+<hr />
+<h2 id="auto-accept-invites"><a class="header" href="#auto-accept-invites">Auto Accept Invites</a></h2>
+<p>Configuration settings related to automatically accepting invites.</p>
+<hr />
+<h3 id="auto_accept_invites"><a class="header" href="#auto_accept_invites"><code>auto_accept_invites</code></a></h3>
+<p>Automatically accepting invites controls whether users are presented with an invite request or if they
+are instead automatically joined to a room when receiving an invite. Set the <code>enabled</code> sub-option to true to
+enable auto-accepting invites. Defaults to false.
+This setting has the following sub-options:</p>
+<ul>
+<li><code>enabled</code>: Whether to run the auto-accept invites logic. Defaults to false.</li>
+<li><code>only_for_direct_messages</code>: Whether invites should be automatically accepted for all room types, or only
+for direct messages. Defaults to false.</li>
+<li><code>only_from_local_users</code>: Whether to only automatically accept invites from users on this homeserver. Defaults to false.</li>
+<li><code>worker_to_run_on</code>: Which worker to run this module on. This must match the &quot;worker_name&quot;.</li>
+</ul>
+<p>NOTE: Care should be taken not to enable this setting if the <code>synapse_auto_accept_invite</code> module is enabled and installed.
+The two modules will compete to perform the same task and may result in undesired behaviour. For example, multiple join
+events could be generated from a single invite.</p>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">auto_accept_invites:
+    enabled: true
+    only_for_direct_messages: true
+    only_from_local_users: true
+    worker_to_run_on: &quot;worker_1&quot;
+</code></pre>
 <div style="break-before: page; page-break-before: always;"></div><h1 id="homeserver-sample-configuration-file"><a class="header" href="#homeserver-sample-configuration-file">Homeserver Sample Configuration File</a></h1>
 <p>Below is a sample homeserver configuration file. The homeserver configuration file 
 can be tweaked to change the behaviour of your homeserver. A restart of the server is 
@@ -8697,6 +8715,8 @@ This can be optionally enabled by setting <code>backchannel_logout_enabled</code
 <li>JWT Algorithm: RS256 within the security menu of the new Relying Parties
 (<code>Options &gt; Security &gt; ID Token signature algorithm</code> and <code>Options &gt; Security &gt; Access Token signature algorithm</code>)</li>
 <li>Scopes: OpenID, Email and Profile</li>
+<li>Force claims into <code>id_token</code>
+(<code>Options &gt; Advanced &gt; Force claims to be returned in ID Token</code>)</li>
 <li>Allowed redirection addresses for login (<code>Options &gt; Basic &gt; Allowed redirection addresses for login</code> ) :
 <code>[synapse public baseurl]/_synapse/client/oidc/callback</code></li>
 </ul>

latest/upgrade.html

@@ -267,7 +267,7 @@ v1.61.0.</p>
 <tr><td>v1.85.0 – v1.91.2</td><td>v1.83.0</td></tr>
 <tr><td>v1.92.0 – v1.97.0</td><td>v1.90.0</td></tr>
 <tr><td>v1.98.0 – v1.105.0</td><td>v1.96.0</td></tr>
-<tr><td>v1.105.1 – v1.108.0</td><td>v1.100.0</td></tr>
+<tr><td>v1.105.1 – v1.109.0</td><td>v1.100.0</td></tr>
 </tbody></table>
 <h2 id="upgrading-from-a-very-old-version"><a class="header" href="#upgrading-from-a-very-old-version">Upgrading from a very old version</a></h2>
 <p>You need to read all of the upgrade notes for each version between your current

latest/usage/configuration/config_documentation.html

@@ -4094,6 +4094,32 @@ Set a size to change the default.</li>
     min_batch_size: 10
     default_batch_size: 50
 </code></pre>
+<hr />
+<h2 id="auto-accept-invites"><a class="header" href="#auto-accept-invites">Auto Accept Invites</a></h2>
+<p>Configuration settings related to automatically accepting invites.</p>
+<hr />
+<h3 id="auto_accept_invites"><a class="header" href="#auto_accept_invites"><code>auto_accept_invites</code></a></h3>
+<p>Automatically accepting invites controls whether users are presented with an invite request or if they
+are instead automatically joined to a room when receiving an invite. Set the <code>enabled</code> sub-option to true to
+enable auto-accepting invites. Defaults to false.
+This setting has the following sub-options:</p>
+<ul>
+<li><code>enabled</code>: Whether to run the auto-accept invites logic. Defaults to false.</li>
+<li><code>only_for_direct_messages</code>: Whether invites should be automatically accepted for all room types, or only
+for direct messages. Defaults to false.</li>
+<li><code>only_from_local_users</code>: Whether to only automatically accept invites from users on this homeserver. Defaults to false.</li>
+<li><code>worker_to_run_on</code>: Which worker to run this module on. This must match the &quot;worker_name&quot;.</li>
+</ul>
+<p>NOTE: Care should be taken not to enable this setting if the <code>synapse_auto_accept_invite</code> module is enabled and installed.
+The two modules will compete to perform the same task and may result in undesired behaviour. For example, multiple join
+events could be generated from a single invite.</p>
+<p>Example configuration:</p>
+<pre><code class="language-yaml">auto_accept_invites:
+    enabled: true
+    only_for_direct_messages: true
+    only_from_local_users: true
+    worker_to_run_on: &quot;worker_1&quot;
+</code></pre>
 
                     </main>