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

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.

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

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.

Sí, claro, estoy haciendo todo esto solo por «el hecho de cambiar» :+1: 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.

3 Me gusta

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! :+1:)

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 (:+1:), 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?

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:

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.

2 Me gusta