5. Arranque aplicación (1) (ADMINISTRADOR) Introducción a la creación de la estructura de la entidad(1). Propuesta de creación de contenedores para usuarios y delegaciones

0. Introducción

David Herrero recomienda que se creen estructuras significativas. Por ejemplo, plantea una estructura de este tipo:

• Intervención
• AD
• Usuarios
• RC
• Usuarios
• Facturas
• Usuarios
• Interventor
• Usuarios

Así, se puede enviar tareas a un grupo y no a un uuario

1. Entrada

En la aplación de administración (sufijo "/admin" tras la url de la sede)  entramos y tras identificarnos, y seleccionamos "Estructura organizativa y de personal".

2. Vemos una estructura parecida a la que sigue. Hay que darle al signo "+" para que se abran los subnodos de un nodo.

Como se puede ver, el nodo "SISTEMAS" está tanto dentro de "INFORMÀTICA I MODERNITZACIÓ" como de "URBANISME (I). No es una estructura de árbol. 

2. Edición de nodos

Marcamos con el botón izquierdo del ratón un nodo que queramos hacer algo con él. En la parte derecha hay un boton con el texto "Editar" junto con un trialgulito que muestra un menú emergente

PRECAUCIÓN-1: Si utilizamos la opció "Eliminar", entonces borra completamente ese nodo, independientemente de donde se encuentre. Por ejemplo si selectionamos el nodo "SISTEMES" que cuelga de "URBANISME (1)", y lo borramos, también se elinará de "INFORMÀTICA I MODERNITZACIÓ". Y si este nodo tuviera hijos, también los borraría. Así que CUIDADO! Para eliminar la relaciónde un adre con su hijo hay que ir a la pestaña de Relaciones

Si editamos, podemos cambiar el nombre etc.

Veamos las opciones disponibles:

• Nuevo Contenedor: Para añadir un nuevo nodo contenedor (por ejemplo un subdepartamento dentro de otro departamento). Hay que tener en cuenta que se CREA con esta opción.
• Nuevo Usuario: Crea un usuario nuevo y lo asigna a este nodo
• Insertar en otro contenedor existente: A nuestro nodo, se le asigan otro nuevo padre. Ahora nuestro nodo va a tener 2 padres. Pero si nos hemos equivocado, parece ser que SOLO se puede quitar las referencias de un nodo a uno de sus padres en la pestaña de Relaciones que se ve en el punto 4 . Si lo insertamos en un padre que ya lo contenía, aparecerá dos veces dentro de ese padre. Pero esto es un "espejismo". si le damos a "Desplegar" solo aparecerá una vez
• Agregar nodo existente: Copia la referencia de un nodo y le asigna el nodo actual como padre, es decir ahora el nodo va a tener 2 padres. Pero si nos hemos equivocado, hay que recurrir a la perstaña de Relaciones.
• Desplegar: Parece ser que sirve para actualizar las referencias y ver como se queda (desplear jerarquía)

3. Pantalla de información del nodo. Gestión de Avisos

Contiene 4 "Tabs" o pestañas.

• Datos Generales donde se le aporta descripciones y parte del comportamiento. La pantalla es distinta para un usuario que para su contenedor. Hay varioas opciones muy importantes en la pantalla de contenedor que son: 
• Admite documentos (por defecto) para poder envíar documentos a este contendor, 
• Admite asientos de registro (Si NO se activa, entonces, desde SEGEX NO se le puede enviar registros a este contenedor). OJO más vale ponerlo en activo, sinó a veces puede no recibir peticiones de formas de documentos. 
• Admite facturas (para que se le envíen desde SEFACE) En el nivel 1 las facturas se descargan en Sedipualba, para que las firmen. SEFACE permite incluir la factura directamente al expediente
• Es oficina de registro.: Solamente se pueden crear oficinas de registro desde la central de Sedipualba. Una vez creadas las oficinas pertinentes, se pueden asignar a este nodo

• Datos de Contacto para indicar teléfonos, email y direcciones postales. Esta opción tiene además la gestión de procedencia de avisos. En principio los avisos se envían por email

•  
  
  
  
  
  
  
  

• Relaciones donde se muestran los nodos PADRES. Es el único lugar para poder eliminar las relaciones padre-hijo sin borrar los nodos. Veamos las pantallas: Como vemos, una persona puede estar en varios departamentos o contenedores, y le damos a modificar la relación de pertenencia:

• 
  
  
  
  
• 
  

  

  
   
• y vemos que permite:
• Jerarquia (?)
• Propagar el envío de avisos. Cosa importante pues podemos envíar un aviso a una subsección para que alguien nos mire por ejemplo una factura. Si no se activa, los avisos no se pasan a los miembros del contenedor!.
• Propagar roles: Ya sea por actor( afecta solamente a los hijos) o por ámbito ( afecta recursivamente a sus hijos, nietos, bisnietos...) David plantea dar un rol al contenedor y después propagar por ámbito para el caso de Secretario y Alcalde (cuando se ausentan ya sea por vacaciones u otras causas.) Los roles por ámbito solopueden ser propagados en caso que sea un contenedor.

• Roles para definir todo el complejo tema de asignación (actor y ámbito) y propagación (actor y ámbito)

4. Propuesta de creación de contenedores de usuarios y delegaciones.

Dada la flexibilidad de la configuración de nodos, propongo crear estos nodos contenedores que son hijos directos del nodo principal (Ayuntamiento). Todos estos nodos serán nodos OCULTOS, pues no van a afectar para nada a la tramitación de expedientes, pero serán de gran ayuda para los administradores

  1. Usuarios activos: Donde se definirán cada uno de los usuarios activos

  2. Usuarios de baja: Los usuarios actios que han causado baja, se les creará una relación a este nodo contenedor padre y se les eliminará de las telaciones anteriores existentes al nodo de usuarios activos y los demás contenedores, también se tomará precaución de eliminar tdos los roles existentes.

  3. Concejales activos: El mismo tratamiento que los usuarios activos.

  4. Concejales de baja: El mismo tratamiento que los usuarios de baja

De esta manera es muy fácil controlar los usuarios existentes sin tner que recorrer cada uno de los contenedores

OJO: A los usuarios y concejales de baja hay que desmarcar la opción de activo, ya que en caso contrario, Sedipualb@ nos cobrará por este usuario.

Otro tema importante que se puede escapar de las manos es el tema de delegaciones, por ello planteo que se creen en la estructura organizativa unos nodos para tener controladas todas las delegaciones vigentes para ello se plantea tener estas carpetas:

1. Delegación de funcionarios de alta: Para los cargos actuales  de secretario, tesorero, interventor..
2. Delegación de funcionarios de baja: Para los cargos NO ACTIVOS anteriores.
3. Delegación de concejales de alta: Para los cargos activos de alcaldes y alcaldes delegados 
4. Delegación de concejales de baja: Para los cargos NO ACTIVOS de alcaldes y alcaldes delegados. 

Dentro de cada carpeta de delegación, se incluirán los usuarios. Este planteamiento puede resultar problemático, pues un mismo usuario puede estar a la vez ene el contenedor de ALTA y de BAJA, pudiendo dar problemas de control. Poe ejemplo un concejal puede estar de alta en su concejalía y de baja como alcalde delegado de todo el ayuntamiento. 

Hay que ser muy disciplinados, y cuando se le da de baja una delegación a un usuario, hay que comprobar si le queda alguna otra delegación antes de quitarle del contenedor de delegaciones de alta.

También hay que controlar las delegaciones programadas. Por tanto, cada cierto tiempo hay que revisar los usuarios del contenedor de delegaciones activas para ver si ya ha caducado su sol programado. 

5. Estructura departamental

Mucho se ha escrito al respecto, en principio JJ no quiere que se haga una estructura muy compleja, ya que cualquer cambio puede ser traumático. En principio se recomienda una estructura cuanto más simple mejor. Por ejemplo, comenzar con las oficinas de registro, urbanismo, y alguna más como secretaría.

Ver la introducción de esta entrada, pues inidcamos la propuesta de David Herrero que considero muy acertada.

Una vez creados los departamentos como hijos directos o indirectos del nodo principal del Ayuntamiento, para asignar los usuarios a cada departamento (observar que un usuario puede ser asignado a varios departamentos) se hará:

1. Abrir la estructura jerárquica del árbol de la entidad (apretando sobre los signos "+") hasta que aparezca el departamento que nos interesa asignar usuarios.
2. Apretar en el triangulito al lado del botón "editar" y seleccionar "Agregar nodo existente"
   
   
   
3. Seleccionar del nodo "usuarios de alta", el usuario que nos interesa y lo asignaremos. Si vamos al usuario, podemos ver que en "relaciones", tiene una al nodo contenedor (departamento) especificado. Se puede modificar, borrar.. 

   

   
   
4. Ahora hay que asignar roles. Este tema requiere un apartado especial. 

6. Asignación de roles a usuarios

Los roles tienen 2 propiedades muy importantes:

1. Capadidad de poder realizar ciertas tareas o capacidades
2. Ámbito de actuación (Todo el Ayuntamiento, un departamento...)

Hay que tener en cuenta que David Herrero propone crear roles a un contenedor y propagarlo a los miembros de este contenedor.

Para asignar un rol a un usuario, se pincha sobre el usuario, y el la pestaña de "Roles" se le da a "Nuevo".

Y ahora se selecciona la aplicación, rol y departamento.

Hay roles que se pueden TRANSMITIR o TRANSFERIR como el de Alcalde. En ese tipo de roles que permite la transmisión aparece un botón extra

Que si lo accionamos aparece esta pantallita, donde nos indica la persona y rol de procedencia y la persona-rol de destino de la transmisión. 

Esto sirve para transferirle todos los SEGRAS (u otras tareas?)  que tenía pendientes de firmar a este nuevo alcalde o rol. Si no se transfiere el rol, hay que volver atrás a borrador un documento y volverlo a enviar para su firma. 

En principio, se pueden asignar los roles pricipales de entidad a los usuarios:

1. Administrador: Permite acceder a todos los elementos de la entidad, pero sobre todo al "Panel de Administrador". 
2. Presidente/Alcalde (según sea diputación o ayuntamiento): Puede ser tanto el Alcalde como el teniente alcalde. En principio, el Alcalde, tiene de ámbito (a efectos de SEFYCU y SEGRA) todo el Ayuntamiento, mientras que el teniente alcalde tiene un ámbito menor (uno o varios departamentos). Para seleccionar que sea "delegado", hay que modificar el Rol una vez se ha creado, y marcar "delegado".
   
   3. Responsable de Registro: Este rol tiene de ámbito todo el Ayuntamiento.

7. Observaciones sobre roles

Hay una FAQ sobre los roles de usuario.

Veamos algunas notas sobre los roles :

• El rol de Secretario e Interventor deberían tienen acceso de lectura a SEFYCUs y SEGRAs. Por tanto se les debería de asignar en la aplicación SEGEX de Permiso de lectura en expedientes, SEFYCU y SEGRA
  
  
  
• El rol de Alcalde, responsable, concejal, pueden renombrarse y tener un texto personalizado.
• Si queremos que algunas personas de varios departamentos puedan registrar de entrada, entonces basta con asignarles el rol (modificar registros generales) de registro. OJO un becario no puede registrar.
• Para el caso de recoger firma biométrica existe este rol también. Para gente sin certificado y presenta un trámite y va a la OAC a firmar. Para firmar contratos va bien, se hace el contrato en el expediente y cuando va la persona, lo firma biométricamente y se queda firmada sin salir del sistema, sin tener que escanear nada. Las actas de recepción, se puede meter las empresas en el SEFYCU, y se pone que se admite la recepción por firmas biometrica.
• Rol responsable del área: Sin este rol, no se puede hacer ningún decreto (SEGRA), pues requiere la firma del responsable de área para tener la propuesta de decreto. 
• Rol revisión secretaría: Revisa el decreto antes de la firma del alcalde (solo si se ha activado este paso en SEGRA!) Sin este rol (y si se activado este paso de revision) no se puede hacer ningún decreto (SEGRA) Administrador->Parámetros de Entidad -> SEGRA
  
  
  
• Rol revisión alcaldía: (Para ayuntamientos grandes) Revisa el decreto antes de la firma del alcalde (solo si se ha activado este paso en SEGRA!) Sin este rol (y si se activado este paso de revision) no se puede hacer ningún decreto (SEGRA). Esto se activa en Administrador->Parámetros de Entidad -> SEGRA igual que antes.
• Impresión de libro: De decretos, resúmenes y por página
• Fiscalización. Se trata más en SECOIN, y hace falta para informes de fiscalización.
• No puede publicar edictos. Para publicar en el tablón de anuncis hay que hacer una notificación al tablón de anuncios. Con este rol se prohibe que esta persona plublique.
• Poder listar todos los pagos de la entidad. Aunque tengas tu propia pasarela virtual, sin atacar los WS no se puede saber los cobros que se han hecho por Sedipualba.(Lo ideal es descargarlos en formato C60).
• Puede obtener certificado de empadronamiento.
• Puede crear firmantes ocultos. (Policías, servicios sociales) En SEFYCU se puede firmar con seudónimo (definiendo roles personalizados)Respecto al tema de roles existentes en exclusividad para el registro, se hablará en mas detalle en la entrada relacionada de registro. Si se ve quien ha firmado en el expediente pero no en el documento.
• Administrador de registros de tratamientos. (NO de LOPD!!!) permite entrar en administración de SERES, y dar 2 direcciones de email:
• La de quien recibe los correos devueltos
• La de quien recibe todos los correos que entran

• Modificar ciudadanos: Permite unificar ciudadanos y dar de alta terceros.

8. Programación de los roles

Si tenemos un secretario sustituto activo a una fecha, los decretos anteriores a esa fecha (y hora) no se prodrán firmar por dicho secretario sustituto!

Se puede programar dichos roles entre fechas: Indicando que hasta una fecha está inactivo y a partir de esta fecha hasta otra está activo, quedando otra vez inactivo a partir de la última fecha.

9. Paradojas de los roles

Existe alguna paradoja en estos temas:

1. Hay cierta independencia en el ámbito de las relaciones y los roles: Por ejemplo, un usuario puede tener una relación de inclusión dentro de un departamento y tener un rol cuyo ámbito sea otro departamento. Por ejemplo (no sé si será legal o práctico) tener un usuario que está incluido en la oficina de registro (relación de pertenencia) y puede ser teniente de alcalde del departamento de sanidad, al cual no tiene ninguna relación de pertenencia.
2. Un departamento puede tener roles y estos se propagan a los usuarios que pertenezcan a este departamento (mediante la relación de pertenencia).