Permisos granulares basados en grupos para usuarios anónimos y registrados

[martin (Martin Brennan)]

@merefield

así que ¿algunas personas se confundieron al pensar que «everyone» significaba solo los usuarios iniciados en la sesión?

¿quién?!

«everyone» es «everyone», seguro, es muy claro.

No, no era así, y hemos visto que surge una y otra vez, tanto internamente como externamente, y en toda la base de código.

@merefield

así que ahora una Categoría que es completamente pública debe tener un mínimo de dos grupos en lugar de uno: iniciados en la sesión y anónimos, ¿no? eso es absurdo y no es una mejora, ¿verdad?

Aún no he llegado a las categorías, no ha cambiado nada aquí.

@merefield

al cambiar solo TL0 a «usuarios iniciados en la sesión», ahora rompes la consistencia de que cada nivel de seguridad sea un umbral. TL1 también es un umbral y no es realmente un «grupo único». ¿así que eso significa que necesitamos un grupo llamado «usuarios iniciados en la sesión que tengan al menos nivel de confianza 1»?!

Las personas usaban abrumadoramente TL0 para significar «todos los usuarios iniciados en la sesión» porque no teníamos una mejor manera de representar esto. El grupo logged_in_users al menos es totalmente claro en lo que implica, y absolutamente nada te impide seguir usando TL0/TL1, etc. El único grupo que se está eliminando es everyone.

@merefield

cambio por el solo hecho de cambiar

Sí, claro, estoy haciendo todo esto solo por «el hecho de cambiar» Por favor, considera por un momento tu forma de expresarte, no es nuestra costumbre hacer cosas totalmente innecesarias sin razón aquí. Este trabajo ha estado en curso durante meses y no está cambiando de dirección.

[merefield (Robert)]

Vale, ¿quizás estoy malinterpretando este cambio?

Si la propuesta es introducir:

• anon
• logged in

como grupos automatizados

parece bien y son autoexplicativos.

(¡De hecho, me gusta bastante! )

Sin embargo, si la propuesta es eventualmente eliminar:

• everyone

eso no tiene sentido para mí, ya que everyone forma parte de un conjunto de grupos automatizados que representan umbrales de acceso, los cuales también incluyen:

• trust_level_0
• trust_leve_1

etc.

todos ellos representan umbrales de acceso, incluido everyone.

el grupo everyone es también conocido como “trust_level_none”

es una forma concisa de indicar acceso público.

Aprecio que no estés proponiendo eliminarlo por ahora para los permisos de Categoría (), pero personalmente me gustaría ver un compromiso para mantener este grupo automatizado, ya que al menos para mí tiene sentido.

y entonces, ¿por qué no permitir que se utilice en otras partes, igual que cualquier otro grupo automatizado de nivel de confianza?

de lo contrario, en todas las partes donde necesites expresar que algo tiene “acceso público”, vas a necesitar agregar dos grupos, lo cual parece una complejidad innecesaria.

¿para qué molestarse en agregar lógica para “ocultar” a “everyone”?

quizás otro enfoque alternativo sea reconsiderar el nombre “everyone” si existe un nombre mejor, pero mantener su significado, funcionalidad y disponibilidad en toda la plataforma, y entonces todos (tos) estarán contentos?

[martin (Martin Brennan)]

Creo que la distinción aquí radica entre mantener una forma conveniente de seleccionar «acceso público» y mantener el grupo everyone existente. Estoy de acuerdo con que tener que seleccionar dos grupos cada vez que se desea acceso público resulta más engorroso, y podemos mejorarlo con la interfaz de usuario.

Por ejemplo, podríamos añadir un acceso directo «Público» al selector de grupos que seleccione tanto anonymous_users como logged_in_users en una sola acción. Entonces verías ambos grupos seleccionados y podrías eliminar cualquiera de ellos. Esto te daría la comodidad que describes, manteniendo al mismo tiempo los permisos subyacentes explícitos. Solo ofreceríamos ese acceso directo donde se permitan ambos grupos.

El problema con mantener el grupo everyone existente es que no ha significado consistentemente «acceso público». Para la visibilidad de categorías sí lo hace, pero para la mayoría de los ajustes del sitio basados en grupos ha significado efectivamente «todos los usuarios iniciados en sesión». También hay temas y plugins que lo interpretan de manera diferente, como ha demostrado la discusión anterior.

Por lo tanto, no podemos simplemente mantenerlo y decir que incluye a los usuarios anónimos en todas partes, sin el riesgo de otorgar un acceso que antes no existía. Mantener su comportamiento actual preservaría la inconsistencia, y renombrarlo tampoco la resolvería.

Un grupo universal definido de forma consistente sería posible, pero aún requeriría la migración y la auditoría que estamos realizando ahora. También tendría que estar prohibido en cualquier lugar donde no se admita el acceso anónimo, de lo contrario estaríamos de vuelta a que «everyone» signifique «solo usuarios iniciados en sesión» en esos lugares. Hay un montón de ajustes a los que he tenido que añadir anonymous_users como valor de disallowed_groups donde antes no lo estaba, y antes everyone estaba permitido en esos ajustes. Por ejemplo:

@martin

Lo que complica aún más las cosas es el hecho de que este grupo @everyone se puede utilizar en ajustes del sitio donde no tiene sentido que «todos los usuarios anónimos e iniciados en sesión» tengan acceso a la función, como pm_tags_allowed_for_groups.

Preferiría proporcionar esa comodidad en la interfaz de usuario, utilizando los dos grupos explícitos subyacentes, de modo que tengamos consistencia en todas partes para administradores y desarrolladores.

[merefield (Robert)]

@martin

Por ejemplo, podríamos añadir un acceso directo «Público» al selector de grupos que seleccione tanto anonymous_users como logged_in_users en una sola acción. Entonces verías ambos grupos seleccionados y podrías eliminar cualquiera de ellos. Eso te daría la comodidad que describes, manteniendo al mismo tiempo los permisos subyacentes explícitos. Solo ofreceríamos ese acceso directo donde se permitan ambos grupos.

Todos son muy explícitos; esto me parece una innecesaria torpeza, pero aprecio la comodidad conservada.

@martin

pero para la mayoría de los ajustes del sitio basados en grupos, ha significado efectivamente «todos los usuarios iniciados sesión». También hay temas y plugins que lo interpretan de manera diferente, como ha mostrado la discusión anterior.

En mi opinión, ahí es donde estaba/está el problema y no con el concepto original de la categoría «everyone» (todos).

El grupo «everyone» y su uso en el sistema fundamental de Categorías lleva existiendo desde… ¿2013?

work in progress, add fidelity to category group permissions (full, create posts, readonly)

Si el sistema de ajustes se desvió y rompió este contrato, ¿no es un problema con el trabajo realizado en el sistema de ajustes?

En mi opinión, habría sido bueno tener un RFC para que la comunidad aportara ideas al respecto antes de lo que parece encaminarse directamente a la implementación.

Disculpen si me perdí algo…

[martin (Martin Brennan)]

Sí, estoy de acuerdo con que la inconsistencia en la configuración del sitio es parte del problema. Pero corregir eso no significa necesariamente que debamos seguir utilizando el grupo everyone existente para la configuración del sitio.

No creo que el argumento de 2013 nos diga mucho más allá de cuánto tiempo ha existido everyone para los permisos de categoría. Ha cambiado muchísimo en Discourse desde 2013; por ejemplo, muchas configuraciones del sitio solían basarse en el nivel de confianza, ahora se basan en grupos. Nadie discute que tenga sentido en ese contexto, y los permisos de categoría no cambian con este trabajo (al menos, por ahora). Su antigüedad no establece que tenga un significado consistente en el resto de Discourse, ni que debamos mantenerlo indefinidamente.

Incluso si estamos de acuerdo en que cada desviación del significado original fue un error, todavía tenemos que lidiar con cómo funcionan realmente esas configuraciones en los sitios existentes. No podemos cambiar con seguridad su interpretación para incluir a los usuarios anónimos solo porque eso coincidiría mejor con el comportamiento original de las categorías. Como expliqué arriba, mantener un grupo universal con un significado consistente aún requeriría auditar y migrar esos usos. Es un diseño alternativo, pero no evita la parte difícil de este trabajo.

En cuanto al punto del RFC, tener un RFC de la comunidad antes de hacer cambios como este sería lento y prohibitivo, aunque se agradece la retroalimentación, para eso está el sistema de cambios que está por venir. Este tema ya ha llevado a varias mejoras a partir de los ejemplos de Moin, y he reconocido los casos de tema/componente que se me pasaron por alto inicialmente y también los he corregido.

Estoy dispuesto a seguir trabajando en los problemas concretos con el cambio, pero sigo adelante con los dos grupos explícitos. Hacer que el acceso público sea fácil de seleccionar en la interfaz parece una forma razonable de abordar los clics extra, pero no creo que sea necesario implementarlo justo ahora.

De todos modos, todavía tengo mucho trabajo registrado en The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions para esto, así que esto está a un buen tiempo, al igual que cualquier cambio relacionado con el sistema de categorías, que retiene everyone por el momento. Es probable que las categorías pasen a un sistema al que llamamos ACL, que kanban ya utiliza: