Tableau de bord de l’administration
Amélioré par CatodonVoyez en un coup d’œil les utilisateurs, la fédération, la file et l’activité, avec une pastille pour tout ce qui demande de l’attention.
8 fonctionnalités essentielles · 30 ajoutées depuis le fork
Voyez en un coup d’œil les utilisateurs, la fédération, la file et l’activité, avec une pastille pour tout ce qui demande de l’attention.
Ouvrez, fermez ou limitez aux invitations les inscriptions, avec validations, âge minimum et protection contre les bots comme ALTCHA.
Laissez les gens se connecter avec le fournisseur OpenID Connect de l’organisation.
Publiez des avis à l’intention de tous les utilisateurs, avec un envoi par e-mail en option.
Définissez pour tout le monde le thème, la langue, les flux, les forums et le CSS personnalisé par défaut de l’instance.
Ajoutez des widgets personnalisés que l’instance dessine pour tous ses visiteurs.
Supprimez automatiquement les anciennes publications d’autres instances dont rien ne se sert ici, pour éviter que la base de données ne grossisse.
Rédigez les conditions de l’instance dans l’interface, avec conservation des versions datées.
Une tâche nocturne facultative supprime les publications d’autres instances une fois leur durée de conservation dépassée et lorsque plus rien sur cette instance n’y renvoie, pour que la base de données cesse de grossir sans limite. Elle est désactivée par défaut et démarre en simulation, sans rien supprimer ; Administration → Performance en contient les réglages. Une publication avec laquelle quelqu’un d’ici a interagi est conservée, ainsi que toute sa conversation.
Les administrateur·rices définissent l’emplacement Accueil et les onglets que reçoivent les nouveaux comptes, ainsi que les comptes existants tant qu’ils n’ont pas organisé les leurs. Une option écrase les flux de tout le monde.
Les administrateur·rices peuvent laisser les liens entrer en tendance dès que leur score le permet, sans attendre l’approbation d’un·e modérateur·rice. C’est désactivé par défaut, et lorsque c’est activé, refuser un lien ou son éditeur le retire quand même des tendances.
ALTCHA, une protection contre les robots qui s’exécute sur votre propre serveur et respecte la vie privée, peut désormais être utilisée, et mCaptcha devient une option de captcha prise en charge.
Les administrateur·ices peuvent ajouter leurs propres widgets à la colonne des widgets : une petite page HTML, avec du CSS et éventuellement du JavaScript, ou une intégration comme un bouton de don ou un widget Discord. Chacun s’exécute isolé de l’application, sans pouvoir savoir qui vous êtes ni agir à votre place, et celui qui charge du contenu d’autres sites demande avant de récupérer quoi que ce soit, puisque ces sites verraient votre adresse IP.
Plusieurs protections sont désormais actives par défaut : un avertissement avant l’ouverture d’un lien externe, un envoi depuis une adresse web plus strict, des contrôles de visibilité lors de la distribution des publications aux flux et par WebSocket, et des réglages plus sûrs pour les adresses sur lesquelles le serveur écoute.
Les administrateur·rices peuvent définir le thème et la langue par défaut de l’instance, ainsi que des forums par défaut que les comptes locaux rejoignent automatiquement.
Les bannières communautaires peuvent prendre leur image dans le Stockage, et une bannière peut être épinglée dans la barre latérale.
Chaque processus surveille désormais ses bassins PostgreSQL et prévient quand des requêtes ont attendu une connexion libre, puis journalise une fois par heure les pics de chaque bassin. La taille du bassin peut être réglée sur preuve plutôt que devinée.
Catodon gère ses propres fichiers temporaires et supprime ceux qui sont périmés au démarrage, puis toutes les heures.
Les inscriptions, ainsi que les inscriptions en attente de finalisation, sont désormais limitées en débit par adresse IP.
Les administrateur·rices peuvent ajouter du CSS personnalisé pour toute l’instance, servi comme une véritable feuille de style.
Les administrateur·rices peuvent choisir la période sur laquelle les hashtags en tendance sont comptés.
Un réglage Page d’accueil décide de ce que voit à la racine du site une personne non connectée : l’écran d’accueil, les flux publics, Découvrir ou la page À propos. Seules les pages qui fonctionnent sans compte sont proposées, et la valeur enregistrée par défaut est ce que l’instance servait déjà.
La couleur de badge de l’instance est ce qu’Android peint sur la barre d’état une fois l’instance ajoutée à l’écran d’accueil, et une couleur claire ou saturée y rend cette barre illisible. Un interrupteur y sert du noir uni à la place, sans toucher au reste de la couleur.
À côté des domaines bannis, une seconde liste dont les inscriptions sont créées et attendent la modération dans la file d’approbation existante, là où un domaine banni les refuse d’emblée. Un domaine listé couvre ses sous-domaines.
Désactivé par défaut. Un compte auquel s’applique cette règle ne peut plus désactiver son authentification à deux facteurs ni ses clés d’accès une fois configurées. Elle ne refuse pas la connexion d’un compte qui n’en a pas encore, ce qui le laisserait dehors sans moyen d’y revenir.
Des adresses seules, des plages CIDR et les noms loopback, link-local et unique-local. La connexion, la connexion par clé d’accès et l’inscription leur sont refusées ; la lecture n’est pas concernée et une session déjà ouverte n’est pas fermée, ce qui ferme la porte d’entrée plutôt que de mettre quiconque dehors.
Administration > Performance s’ouvre désormais sur des réglages suggérés pour la machine sur laquelle l’instance tourne, déduits de sa mémoire, de ses cœurs de processeur, des comptes actifs, de la taille de la base de données et de l’espace disque libre, chacun avec sa raison et un bouton Appliquer. Rien ne change tant que vous n’en appliquez pas un, et un disque presque plein pour les fichiers distants en cache allume la pastille de l’Administration. La liste est aussi disponible par admin/performance-suggestions.
Un interrupteur dans l’éditeur d’annonces l’envoie par e-mail aux comptes locaux qui ont laissé activées les annonces par e-mail et disposent d’une adresse vérifiée. L’envoi se fait en arrière-plan par lots, reprend où il s’était arrêté, et n’a lieu qu’une fois pour toute la vie d’une annonce.
Chaque samedi, la branche par défaut est construite et publiée sous une étiquette dev mobile et une étiquette datée, si bien qu’une instance peut faire tourner ce qui s’écrit sans le construire elle-même. Les trois images datées les plus récentes sont conservées, pour pouvoir revenir en arrière après une mauvaise semaine, et les canaux de version restent intacts.
Une instance sous n’importe quelle version de Misskey jusqu’à la 2026.10.0 peut désormais migrer vers Catodon sur place, sans SQL manuel, là où seule la version 2025.4.1 de Misskey ou une plus ancienne le pouvait. Le nettoyage des publications d’autres instances arrive désactivé et en simulation, même s’il était activé sous Misskey.
Administration → Image de marque permet aux administrateur·rices de choisir les couleurs des blocs de code dans les publications, un thème pour le mode sombre et un pour le mode clair, avec un aperçu. Le choix s’applique à tous les comptes dont le thème de couleurs ne définit pas ses propres couleurs de code, et la valeur par défaut conserve les couleurs utilisées jusqu’ici.
Administration → Fédération → Politique gagne une section Instances modérées : chaque instance bloquée ou mise en sourdine peut porter un commentaire public et voir son nom masqué, et les administrateur·ices choisissent qui peut voir la liste et les commentaires, personne par défaut. La liste apparaît alors sur la page Informations et dans les applications Mastodon, et s’importe ou s’exporte au format domain_blocks.csv de Mastodon, avec un aperçu avant l’enregistrement.
Chaque règle de l’instance peut désormais porter une explication plus longue et des traductions dans toutes les langues que parle Catodon, comme le permet Mastodon 4.4. Chacun·e lit les règles dans la langue de son interface quand une traduction existe, sur la page Informations, à l’inscription et lors d’un signalement, et les applications Mastodon reçoivent les deux par les routes de l’instance.
Une fois par jour, l’instance demande à la forge de Catodon la dernière version stable, et quand celle-ci est plus récente, le Tableau de bord de l’Administration affiche un avis aux administrateur·ices avec un lien vers ses notes de version. Contrairement à la vérification de Mastodon, la requête n’envoie pas la version en service, et elle peut être désactivée dans Sécurité réseau.
La vérification quotidienne des mises à jour lit désormais quelles versions sont critiques et quand chaque branche de versions cesse d’être maintenue. Une version critique plus récente entraîne un avertissement impossible à fermer dans le Tableau de bord, ainsi qu’une annonce et un e-mail à chaque administrateur·ice, et la fin du support est annoncée trois mois et deux semaines avant, puis une fois passée. Comme pour l’avis de nouvelle version, la requête n’envoie ni le nom de l’instance ni sa version.
La pastille à côté d’Administration dans la navigation ne s’allumait que pour les signalements non résolus et les demandes d’abonnement aux forums. Elle s’allume désormais pour chaque carte de Tableau de bord > À traiter, des comptes en attente d’approbation et des tendances à examiner jusqu’aux appels et, pour les administrateur·ices, une mise à jour critique, désormais une carte à cet endroit plutôt qu’un bandeau. La pastille, le compteur du menu et les cartes concordent désormais.
Les administrateur·ices peuvent désormais publier des conditions d’utilisation datées, rédigées en Markdown et accompagnées d’un résumé des changements, depuis Administration → Conditions d’utilisation, au lieu de renvoyer vers une page ailleurs. Chaque version est conservée et lisible sur l’instance, les versions publiées ne peuvent pas être modifiées, et les comptes sont prévenus à l’avance quand une version prend effet plus tard.
Comme dans Mastodon 4.4, un·e administrateur·ice peut fixer un âge minimum dans Administration > Inscription. Le formulaire d’inscription demande alors une date de naissance et refuse toute personne plus jeune, avec ou sans invitation, et se contente de vérifier la date sans la conserver. Rien n’est demandé aux comptes existants, et l’âge est transmis aux applications Mastodon comme registrations.min_age de /api/v2/instance.