---
# System prepended metadata

title: Permisos Etapa 1

---

Según este EPIC https://lemontech.atlassian.net/browse/TF-3004 

Los permisos de bajo nivel que tenemos definidos en API Auth se agruparán en un conjunto de permisos de Alto nivel, los cuales serán seleccionables a la hora de crear un rol. 

El listado completo de permisos de un usuario no cambia salvo que se agregan o quitan algunos. Esto quiere decir que casi toda la aplicación sigue funcionando en base a los permisos de bajo nivel descritos en API AUTH.

El listado completo de permisos de un usuario será la Union de los permisos de bajo nivel de todos los permisos de alto nivel que tenga su Rol.


Permisos Etapa 1
================


A continuación una propuesta de separación de historias de esta etapa

### 0. Permisos en el Backend `blocker`
- Simplificar API Auth
    - Recurso - Acción
        -> [funciones]

- Complementarlo con Policies
    - Capa policies por recurso
    - Capa policies scope ofrecer Scope al API
    
    * Trabajos
        * time_entries.review
        * users.update_others
    * Users 
        * Usuarios revisores de otros usuarios

- API Auth funciones para atributos
    - Modelo de trabajos edit_with_params new_with_params 
        - Duración
        - Duración Cobrable / Cobrable

    * Usuarios
        - Revisar Permisos de acceso a la ruta de Usuarios según role Admin
        - Edición de Categoría de usuario solo para role = Admin
        - Edición de días de restricción atado a role = Admin
        - Edición de settings del usuario atado a role = Admin
        - Edición de  Meta Diaria

##### Otros

- Cambiar página de setup para no preguntar por role Admin

### 1. Permisos de acceso en el Front
Depende de E1-0

- Permisos de acceso a módulos condicionado a ciertos permisos de bajo nivel

* Usuarios (depende de función)
* Dashboard
    - Elección de mostrar el dashboard del admin según rol, ahora debe respetar otro permiso
* Reportes
    - Cambiar permisos de reportes que hacen referencia al role Admin por el permiso `reports.read`

    > El módulo de reporte no tiene lógica de permisos, muestra toda la información.

* El resto de los módulos será `recurso.create` como funciona hoy en la mayoría.


### 2. Cambios en el módulo de trabajos
Depende de E1-0

- Permitir editar un trabajo si usuario tiene role Admin `components/TimeEntry.js`
- Creación de proyectos desde el Popover de trabajos atado a Role Admin y/o setting `can_create_projects`
    - Se debe cambiar por el permiso de bajo nivel
- Permitir cambiar la duración de los trabajos, dado que es el dueño del trabajo o es un usuario con role Admin
    - Se debe cambiar por el permiso de bajo nivel
- Permitir eliminar un trabajo desde el popover dada la misma condición anterior
- Permitir crear un trabajo desde el día en el calendario a tadado a owner o Admin
- Clonación de trabajos => owner o Admin(misma condición anterior)

- El atajo **isReviewer** del usuario, en el front, hace referencia al permiso de bajo nivel `review`. Este se ocupa para:
    - Habilitar la invitación usuarios desde el calendario: no más, para invitar usuarios se necesitará acceso a `users.create`
    - Mostrar/ocultar/permitir-edición de campos en el Popover
- Esconder la tarifa en el listado de trabajos y excel de trabajos. Si usuario tiene role=Normal


### 3. Cambios en el módulo de Gastos
Depende de E1-0
    - Modificar lógica de quien revisa un gasto


Permisos Etapa 2
================

Depende de E1-0

### 1. Backend y PAN `blocker`
- Desacoplar Role y PAN
    - API Auth a una estructura que no dependa del código del Rol conectado
- Creación de nuevos roles por defecto (seeds)
    - Migrar relación de roles vs HLP (seeds)
    - Asignar a usuarios existentes a nuevos Roles

- Cambiar listado de permisos por usuario conectado que envía el back al front (en ApplicationHelper)
    para alimentarlo de la nueva estructura en base a los permisos guardados del rol.
 
### 2. Notificaciones

- Notificación de Hitos
    - Se envía completa el reporte si el usuario tiene role Admin, se debe cambiar por PAN Reportes

- Reporte semanal de Trabajos
    - Se envía completa el reporte si el usuario tiene role Admin, se debe cambiar por PAN Reportes

### 3. Creación de cuentas
- Creación del usuario admin y sus roles especiales o rol con código quizá


### 4. Migración

#### 4.1 Roles
- creación de roles según mapa de TTB-TBX
- Migración de Roles 

#### 4.2 Migración de usuarios
- Asignación de rol correcto (admin / normal )
- Creación/modificación del usuario admin del sistema con Rol especial como en la creación de cuentas

Tests
=====
- Modificar una tonelada de Tests que hacen referencia la usuario Admin
    - 39 archivos spec
    - 55 archivos test
- Modificar una tonelada de Tests que hacen referencia la usuario Normal
    - 13 archivos spec
    - 23 archivos test


Permisos Etapa 3
================

Depende de E2-1 

### 1. Vista de proyectos simplifcada 
- Permite modificar coas únicamente del proyecto definidas por el permiso `projects.create` 
- La vista completa con todos los campos corresponde a los permisos `projects.create/update/delete`+ `agreements.create/update/delete` 


### 2. Mantendor de Roles en Settings
- todo lo que venga acá 
- Consdierar en la historia las restricciones de Eliminación etc. (Eliminar mi propio rol, eliminar roles asociados a usuarios, etc-)

### 3. Permisos en la aplicación desktop 
- Homologar ingreso de horas con web 
- Homologar creación de proyectos 
- Homologar restricción de ingreso liberada

### 4. Permisos en la aplicación mobile
- Homologar ingreso de horas
- Homologar creación de proyectos 
- Homologar restricción de ingreso liberada

Permisos Etapa 4
================

Depende de E3-4 

- Eliminar Los permisos de bajo nivel sobrantes
- Eliminar estructura antigua de permisos
- quitar el feature flag de la administración de permisos
