Ce ne semble plus être le cas - sur mon site, seuls les administrateurs semblent pouvoir le faire (découvert après avoir tenté de former l’un de mes modérateurs à convertir un sujet en public). Je ne trouve aucun réglage qui régit cela.
Je ne suis pas sûr s’il s’agit d’une régression ou si c’est intentionnel.
Hmmm, je viens de tester ceci et pour moi, cela fonctionne toujours comme prévu et permet aux modérateurs de créer un sujet à partir d’un message privé :
Panneau d’administration de l’utilisateur test montrant les permissions :
Connecté en tant qu’utilisateur test avec un message privé à soi-même :
Avez-vous essayé avec un compte de modérateur test ?
D’accord - je comprends maintenant le problème. Il est lié à l’interaction entre la suppression et les modifications du menu d’administration des sujets, qui ne sont pas rafraîchies tant que la page n’est pas rechargée. C’est un bug (bien qu’il soit très mineur).
Pour reproduire :
Rendre sujet public / Rendre message personnel reste visibleRendre sujet public / Rendre message personnel n’est plus présenteRendre sujet public / Rendre message personnel reste absente jusqu’à ce que la page soit rafraîchieIl semble qu’un rafraîchissement de page soit nécessaire après la suppression / restauration d’un sujet. Peut-être cela devrait-il être inclus dans l’action de suppression/restauration du sujet ?
C’est très clair.
Il y a une coche verte contre TL0 pour la mise en sourdine d’un utilisateur. Après avoir rapidement parcouru ce sujet Which roles are allowed to mute other users? - #4 by JammyDodger, il semble que ce soit une capacité TL1. Quelqu’un pourrait-il mettre à jour le document. 
De plus, « avis du personnel » a également changé de nom.
Merci Jammy - J’ai mis à jour le message initial. 
Je ne vois pas ici de liste indiquant le niveau de confiance requis pour autoriser l’accès à l’API utilisateur (comme mentionné ici : "Sorry, you do not have the required trust level to access the user API" when on iOS). D’après cela, il semble que 0 soit le niveau minimum, mais il peut également être configuré. Cela peut-il être documenté ici ? Ou n’ai-je pas lu assez attentivement ?
Bienvenue chez Meta 
Je pense que vous avez raison ; l’autorisation et le paramètre associé ne sont pas inclus dans le tableau.
Le paramètre user_API_key_allowed_groups est défini par défaut au niveau de confiance 0. Les groupes d’administrateurs et de modérateurs ne peuvent pas être supprimés de ce paramètre. Cependant, pour limiter les autorisations, les administrateurs peuvent supprimer le groupe de niveau de confiance 0, qui inclut tous les utilisateurs inscrits. Ensuite, seuls les membres du personnel sont autorisés à utiliser l’API utilisateur. Ils peuvent également ajouter d’autres groupes pour restreindre l’accès à des groupes spécifiques.
Je n’étais pas au courant de ce lien brut, j’apprends tous les jours 
Existe-t-il un moyen de restreindre certains niveaux d’utilisateurs de pouvoir télécharger certains éléments ou tous les autres que l’approche de base tout vs personnel trouvée dans ADMIN > FILES > Authorized extension ou > Authorized extension for staff ?
Le paramètre du site Embedded media post allowed groups aide-t-il ?
Merci. Je pense que ce composant fera l’affaire.
