¡Sin problema! Me alegra que disallowed_groups sea de ayuda. Ya he fusionado esa PR.
Ahora que tenemos disponibles disallowed_groups y resolve_group_memberships, necesito revisar todos nuestros temas y componentes oficiales. Sugiero que tú y @moin hagáis lo mismo con vuestros propios temas y componentes cuando podáis, ya que, una vez que haya realizado los cambios en nuestros repositorios oficiales, me gustaría mucho avanzar con la estabilización del cambio mencionado en la publicación original.
Hay mucho trabajo central que ahora depende de o utiliza anonymous_users y logged_in_users, y me gustaría mucho eliminar el grupo everyone.
acabo de hacer una actualización completa de mi instancia y ahora estoy añadiendo la configuración de objeto disallowed_groups a mi componente para everyone y anonymous_users basándome en los IDs de grupo automáticos aquí:
¿qué estoy haciendo mal en la configuración del objeto? noto que incluso sin disallowed_groups en los objetos, tampoco aparece el grupo anonymous_users (por lo que, por el momento, no hay diferencia en la lista de mi componente entre establecer disallowed_groups o no). probé con otros IDs de grupo y debo estar haciendo algo mal con el uso de disallowed_groups (o la sintaxis) porque parece no tener ningún efecto independientemente de cuáles use.
Oh, hubo algunos problemas en GitHub earlier en el día, así que solo ahora ha llegado el cambio de disallowed_groups a la última versión de Commits · discourse/discourse · GitHub
No estoy completamente seguro de que ese sea el problema, pero ¿podrías intentar actualizar de nuevo y ver si persiste? Si no es así, avísame e indícame tu componente de tema (¿o es solo el de la barra lateral de tu grupo?) para que pueda depurar
He abierto un PR rápido para añadir esas dos clases (anonymous_users y logged_in_users).
No lo he probado realmente (jaja), pero creo que es bastante sencillo. El código simplemente comprueba si el usuario actual existe, y si es así, entonces es miembro de logged_in_users, y si no, entonces es anonymous_users.
Nota: Estoy bastante seguro de que Discourse añade .anon automáticamente de todos modos, por lo que el CSS para usuarios anónimos frente a usuarios conectados se puede lograr sin el componente, pero esto simplemente utiliza las nuevas convenciones de grupo.
Por cierto, para todos, aún no había publicado aquí, pero he fusionado estos PRs para que los componentes oficiales utilicen resolve_group_membership y disallowed_groups:
Ahora estoy trabajando en un plan para los siguientes pasos de este cambio próximo. Creo que aún hay algunos lugares en los códigos base del núcleo/de los plugins que miran directamente a everyone o no usan user.in_any_groups? en el lado del servidor.
¿Hay alguna razón por la que aún no se haya fusionado?
La razón por la que abrí este tema es que finalmente actualicé mi componente.
[quote=“martin, post:14, topic:402273”]
Cambiaría el valor predeterminado de default_favorite_filters_groups a 4|5 en tu componente de tema, que corresponde a usuarios conectados y anónimos, en lugar de 0 (everyone), que desaparecerá pronto.
[/quote]\nLo hice. Pero sigo teniendo la impresión de que solo ayuda en los foros que añaden el componente después de que hice este cambio. En aquellos que ya lo estaban usando, no se aplica el nuevo valor predeterminado (lo cual suele ser bueno). Así que sigo viendo el problema de que hay un cambio inesperado de comportamiento para quienes ya usaban el componente.
Además, ¿sabes qué pasa si un administrador configuró una opción con un grupo que añado como grupo no permitido en mi actualización?
Dado que no creo que el componente se use en muchos foros, no me preocupé demasiado y fusioné de todos modos, pero tanto la migración como la configuración de grupos no permitidos también podrían ser relevantes para otros desarrolladores de temas.
No, supongo que por alguna razón mi cerebro pensó que esto no era un PR en la organización de Discourse . Lo fusionaré poco después de que se ejecuten las verificaciones de CI.
Para casos como este y otros futuros, creo que la mejor opción probablemente sea escribir una migración por tema/componente Migrate Discourse theme settings
En mi mensaje anterior pregunté cuándo tendría que ocurrir esto. Migrar sin estar seguros de que los nuevos grupos funcionen en todos los foros también podría causar problemas, y los administradores pueden activar o desactivar el cambio. Así que parece imposible migrar en el momento adecuado.
Disculpas si esto ya fue mencionado y yo lo pasé por alto…
Me di cuenta de que, si resolve_group_membership está incluido en la configuración, solo puedo acceder al valor booleano mediante el prefijo user_in_, pero ya no puedo acceder al valor crudo del campo de configuración.
aabbccdd_allowed_groups:
refresh: true
default: "1|2"
type: list
list_type: group
resolve_group_membership: true
console.log(settings.aabbccdd_allowed_groups); // undefined
console.log(settings.user_in_aabbccdd_allowed_groups); // true o false
Creo que sí. De lo contrario, la solución a este error podría haber sido diferente.
También tiene sentido para mí. user_in_x también verifica grupos que el frontend no conoce, porque el grupo solo es visible para los administradores o su visibilidad está limitada por defecto, como en el caso de everyone. Por lo tanto, obtienes resultados diferentes dependiendo de lo que uses, por lo que combinar los dos podría tener consecuencias inesperadas.
Gracias, Moin, eso es exactamente correcto. @gormus el único lugar donde aún se transmiten los IDs de grupo reales es en la interfaz de administración para la configuración del tema.
No estoy seguro de si esto queda claro según lo que he publicado antes, pero anonymous_users y logged_in_users son utilizables en cualquier momento sin que esté habilitado este cambio próximo, los agregué de forma independiente hace meses. Esta es la principal función del cambio próximo:
Así que, de cualquier manera, estarás a salvo si eliminas everyone en todos los lugares donde se usa y solo utilizas anonymous_users y logged_in_users de ahora en adelante.
Hoy planeo definir un plan del trabajo restante que necesito hacer para eliminar realmente everyone de la configuración del sitio (dejando la configuración de categorías de lado por el momento), y lo publicaré aquí, con la esperanza de que eso ayude a mantenernos en la misma página de aquí en adelante, y podré seguir actualizando este plan a medida que avance.
Pero los grupos no son visibles en la interfaz si el cambio está desactivado. Los administradores no pueden modificar la configuración de esos grupos. Así que, cuando añado “todos” como grupo no permitido, ya no ven ningún grupo que les permita configurar un componente para que sea visible para los visitantes. Para mí, “utilizable” implica no solo que funcione, sino que también sea visible. Dado que aún es posible desactivar el cambio, no llamaría “seguro” depender únicamente de los nuevos grupos.
Hmm, tienes razón. Hay un par de cosas más que necesito corregir para que el problema de disallowed_group desaparezca cuando se desactive el próximo cambio:
anonymous_users y logged_in_users no aparecen en el selector de grupos. Creo que ahora es seguro permitirlos aquí, así que no importará si has añadido everyone a disallowed_groups cuando el próximo cambio esté desactivado.
Corregir Guardian::AnonymousUser#in_any_groups? para que respete anonymous_users cuando el próximo cambio esté desactivado.
Añadir el mismo alias de tiempo de lectura de 0 (everyone) → 5 (logged_in_users) para la configuración de temas, que ya hacemos para la configuración del sitio.
Creo que también podría marcar everyone con (legacy) en los selectores de grupos mientras el próximo cambio siga siendo opcional y esté desactivado.
Priorizaré estos puntos y los añadiré a mi plan general en el que estoy trabajando.
He creado un tema dedicado aquí @moinThe road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . La publicación original está incompleta; aún estoy revisando todos los casos localmente y seguiré actualizándola. No me importa que sigáis publicando en este tema, pero preferiría que lleváramos las discusiones posteriores al nuevo, para poder citar partes de la publicación original o añadir contenido según corresponda.
¿así que a algunas personas les confundió que “everyone” (todos) significara solo usuarios iniciados en la sesión?
¿quién?!
“everyone” es “everyone”, ¿verdad? Muy claro.
“everyone” es cualquiera que esté visitando el sitio, ya sea que haya iniciado sesión o no, ¿no es eso simple?
así que ahora una Categoría que es totalmente pública tiene que tener un mínimo de dos grupos en lugar de uno: iniciados y anónimos. ¿Eso es ridículo y no es una mejora?
y si no, y solo tienes que poner “anon” porque es un sinónimo de “everyone”, eso ya no es correcto, ya que los usuarios iniciados no son anónimos.
donde hubo algo de “aprendizaje” en torno a discourse fue que TL0 en algunos casos significaba “todos aquellos que tienen una cuenta e iniciaron sesión”, pero también podía significar “aquellos que aún no han alcanzado TL1 pero tienen una cuenta e iniciaron sesión”.
la clave aquí es que no representaba un solo grupo de personas, representaba un umbral y eso era lo fundamental.
al cambiar solo TL0 a “usuarios iniciados”, ahora rompes la consistencia de que cada nivel de seguridad sea un umbral. TL1 también es un umbral y no es realmente un “solo grupo”. ¿así que eso significa que necesitamos un grupo llamado “usuarios iniciados que están al menos en nivel de confianza 1”?!
no estoy en absoluto convencido de que algo de esto necesitara cambiar. ¿cambiar por el mero hecho de cambiar?
¡gracias, Moin! En realidad se me olvidó que la nueva configuración granular de grupos ya estaba prevista en los cambios futuros de todos modos.
. Lo fusionaré poco después de que se ejecuten las verificaciones de CI.