Al agregar grupos a una categoría, se pueden seleccionar las opciones anonymous_users y logged_in_users, pero no funcionan.
2 Me gusta
¿No requiere que la función beta “Permisos granulares para grupos anónimos y conectados” esté habilitada?
1 me gusta
@martin ¿alguna idea sobre esto?
1 me gusta
Gracias por el reporte, echaré un vistazo 
Según tu respuesta en el otro tema
Cuanto más pienso en esto, más me preocupa.
¿Qué pasa si solo añado anonymous_users a una categoría y no añado logged_in_users?
¿Qué pasa si añado anonymous_users mientras mi foro tiene login_required?
Además, la implementación técnica actual es que cuando los permisos de categoría están configurados como everyone, simplemente no hay ninguna entrada en category_groups y read_restricted está configurado como false.
Esto es muy simple y directo: si no hay permisos configurados, los permisos se determinan por los permisos globales del foro (la configuración login_required) y no se aplican restricciones adicionales.
Así que hacer este cambio añadiría una enorme cantidad de complejidad y serían posibles combinaciones extrañas (podrías tener anonymous users y staff 
)
Mi sugerencia sería:
- eliminar
anonymous_userscomo opción para los permisos de categoría por completo - mantener
everyoneylogged_in_users - eliminar
trust_level_0como opción ya que equivale alogged_in_users
o alternativamente, pero quizás menos claro para administradores con menos experiencia
- eliminar
anonymous_usersylogged_in_userscomo opción para los permisos de categoría - mantener
everyone(y TL0)
En todos los casos, mantener everyone. Y tampoco necesitarás una migración 
4 Me gusta
Gracias por tus comentarios, esa es la razón por la que no quería profundizar demasiado en los permisos de categorías al principio con ese cambio de “todos” 
Creo que gran parte de lo que dices aquí podría simplemente hacerse imposible; ya he estado trabajando en algunos sistemas preliminares aquí con ACLs y una interfaz de permisos más amigable en nuestro plugin de kanban que estamos desarrollando. Aquí hay un ejemplo; nuestra intención es cambiar los permisos de categorías para usar esto eventualmente:
Hay varias reglas involucradas aquí, como que es imposible otorgar permisos de Administrador a usuarios anónimos para un tablero kanban, etc., e incluso admite permisos obligatorios, como que los Administradores siempre pueden gestionar un tablero.
Haremos que no puedas añadir usuarios anónimos cuando el foro requiera inicio de sesión.
De nuevo, otra validación/restricción que podemos añadir.
También podríamos añadir validaciones/advertencias para este tipo de situaciones.
Esto es lo que quiero evitar: este tipo de permisos implícitos que están por todas partes en Discourse, en lugar de tener siempre configurados explícitamente usuarios conectados + usuarios anónimos para una categoría si es pública/no tiene restricciones de lectura.
En cualquier caso, por ahora no quiero profundizar demasiado en esto; queda un trecho por recorrer antes de ocuparme de las categorías. Pero sí estoy de acuerdo en que el problema original es un error que necesita ser corregido a corto plazo, así que seguiré adelante con esto.
1 me gusta
Teniendo en cuenta ese otro problema, yo personalmente recomendaría no implementar ese tipo de lógica. ¿Qué ocurre si cambio un foro para que requiera inicio de sesión cuando ya hay usuarios anónimos en la lista de permisos? ¿Y al revés? Esto se convertirá en una pesadilla y no será transparente para los administradores.
Me preocupa mucho este tipo de complejidad.
2 Me gusta
Nuevamente, más buenos puntos. Hay mucho que analizar y este tema es delicado. Sin duda, tendré en cuenta la experiencia de los administradores al realizar cambios relacionados con las categorías; hay mucha historia detrás de esto y no quiero que nadie se sorprenda. Nada de esto se hará rápidamente; llevará mucho tiempo analizar cuidadosamente los diferentes escenarios cuando llegue el momento de abordar este proyecto.
1 me gusta
Me pregunto por qué el hecho de que puedas configurar cosas para usuarios anónimos, pero no para usuarios registrados, sea un problema en el contexto de los permisos de categoría, pero no en el contexto de los permisos configurados a través de los ajustes del sitio/plugin/tema. Un ejemplo simple: ahora es posible hacer que el guía de estilos esté disponible para usuarios_anónimos sin añadir usuarios_registrados. ¿Tiene más sentido que mostrar una categoría a usuarios anónimos, pero no a usuarios registrados?
1 me gusta
No, no tiene sentido, es simplemente otro caso extremo que cubrir… añadiré anonymous_users a disallowed_groups para ese plugin. Además, dudo mucho que haya muchos sitios en producción con este plugin habilitado, así que no me preocupa demasiado que esto esté mal configurado por el momento.
Creo que esa es la forma en que generalmente manejaría esto con este tipo de configuraciones. También podemos hacer uso de mandatory_values para asegurarnos de que ciertos grupos estén siempre seleccionados, de modo que no termines con solo anonymous_users en algunos lugares. O hacer uso de validaciones de configuración para decir “no puedes elegir anonymous_users sin al menos un grupo de usuarios autenticados”, y así sucesivamente.
No entiendo por qué es necesario. ¿Qué hay de malo en que sea una opción?
¿Esto funciona solo para la configuración del sitio, o también para los componentes del tema?
Por ahora no funciona aún para los componentes del tema, pero podría. Otra vez, nos estamos adelantando demasiado.