Actualmente tenemos varios proyectos que comparten instancias de JIRA. Queremos que los usuarios solo vean los proyectos que están haciendo pruebas.Cómo filtrar el proyecto JIRA que solo ciertos usuarios pueden ver y acceder?
Pero, sin embargo, actualmente estamos agrupando a estos usuarios en la agrupación estándar jira-users.
Cuál es la mejor manera de filtrar proyecto de JIRA que sólo determinados usuarios puedan ver y acceder
Debe crear grupos especiales de usuarios para cada proyecto que tiene ... usted puede tener más de un grupo, algo como "project1_developers", "project2_observers" para una mejor organización.
También es posible combinar estos grupos con las Funciones del proyecto para definir en cada proyecto qué tipo de acceso debe tener cada grupo.
Realice un Esquema de permisos para establecer los permisos de un proyecto. Algo como esto:
Explorar proyectos -> Grupo (project1_admins, project1_developers, project1_users, project1_observers)
crear problemas -> Grupo (project1_admins, project1_developers, project1_users)
Problemas movimiento -> Grupo (project1_admins)
Se puede utilizar sus roles de proyecto aquí también ... pero prefiero configurar todo con grupos.
Finalmente, puede usar los esquemas de seguridad de Issue para definir quién puede y quién no puede ver los problemas. Los esquemas de seguridad de implementación implementan varios niveles de seguridad que pueden tener usuarios/grupos asignados a ellos.
Espero que pueda ayudar.
Personalmente, soy todo para roles de proyecto. Tengo un esquema general de permisos que permite que todos los usuarios/grupos definidos en las funciones del proyecto examinen el proyecto, lo que deja al administrador/administrador del proyecto para definir qué grupos pueden ver su proyecto. Así que al eliminar o agregar usuarios de jira (grupo predeterminado del que un usuario debería formar parte incluso para iniciar sesión en JIRA) a la función de proyecto de "usuarios" de su proyecto, el administrador de proyectos puede controlar si todos los usuarios pueden ver su proyecto o no .
La mejor y más dinámica forma de resolver este problema es con la ayuda de niveles de seguridad y estableciendo los niveles de seguridad basados en el problema en tiempo de ejecución mediante una función de publicación.
Totalmente de acuerdo con Brian: los roles de proyecto son el camino a seguir, de lo contrario terminas con demasiados grupos. La membresía de roles es local para un proyecto. Los grupos son globales.
Totalmente en desacuerdo con Balarami: los niveles de seguridad deben usarse con moderación y en un pequeño porcentaje de los problemas (a excepción).
Escribí un tutorial sobre cómo hacer esto. Implica crear un esquema de permisos, agrupar y desenganchar el grupo de usuarios del esquema de permisos predeterminado. No sé si esta es la única forma de hacerlo, pero una vez que se domina, solo toma 10 minutos para configurar un nuevo cliente con permisos SOLO para sus propios proyectos.
Ésta es la guía más fácil que usted encontrará en la forma de hacer esto:
Tenga en cuenta que los enlaces desnudos a su propio sitio web/producto no son alentados aquí por dos razones; En primer lugar, una respuesta debe publicarse como una respuesta independiente, no como un simple enlace a un sitio externo. En segundo lugar, la autopromoción tiende a ser mal vista aquí, y a menudo se señala como correo no deseado (especialmente si no hay información que indique que está enlazando a su propio sitio/producto). –
Esta es una excelente respuesta, gracias! Mucho más rápido y menos tedioso que crear un esquema de permisos personalizado para cada proyecto. –
¡Woosh! Por encima de mi cabeza ... – Adamantus