Los usuarios pueden interactuar con los objetos del metamodelo de Anjana para efectuar cambios en ellos, solicitar acceso a sus datos o producir objetos nuevos. Estas acciones están disponibles tanto desde el Portal de Anjana como desde la vista de los objetos en particular.
A continuación se exponen las distintas posibilidades que Anjana ofrece:
Editar
Editar un objeto es alterar su metadato, cambiando valor en sus atributos o añadiendo dataset_fields si se trata de un dataset.
El objeto debe tener estado importado, borrador, rechazado, aprobado (si no tiene versión borrador o pendiente), deprecado (si no tiene versión aprobada, borrador, pendiente o deprecadas más actualizadas) o expirado (si no tiene versión aprobada, borrador, pendiente, deprecadas o expiradas más actualizadas) para poder ser editado y, cuando la edición ocurre, se activa el botón Guardar para poder persistir los cambios.
Esta acción sólo está disponible desde la vista del objeto y, para poder llevarla a cabo, el usuario debe clicar directamente sobre el atributo a modificar y, de esta forma, se activa su modo edición.
Guardar
La acción de guardar permite persistir los cambios efectuados en el formulario del objeto y sólo está disponible desde él. El guardado se audita y guarda el snapshot correspondiente al objeto.
La modificación de cualquiera de los atributos del objeto en estado importado, aprobado, rechazado, deprecado o expirado y su posterior guardado, implica la creación de un nuevo objeto en estado borrador que es una copia del original y que contiene los cambios introducidos. Si el usuario edita un objeto con estado borrador, los cambios se aplican sobre ese mismo objeto.
Si el usuario no tiene permiso para editar un objeto o éste no se encuentra en un estado adecuado para ser editado, el botón Guardar no aparece en la cabecera.
Por el contrario, en caso de que el objeto sea editable, el botón de Guardar permanece desactivado hasta que haya algún cambio en la plantilla.
Una vez activado, permite guardar la plantilla actual.
Al guardar el objeto, Anjana comprueba si cumple las validaciones. Si no es así, y, por ejemplo, no todos los campos requeridos están rellenos o hay algún valor incorrecto en algún atributo, un mensaje avisa de ello al usuario. El error debe ser corregido para poder guardar el objeto correctamente y que se active la opción de Enviar.
Al cambiar de pestaña o salir de la vista del objeto, en caso de no haber guardado los cambios del formulario, se muestra un mensaje para poder guardar en ese momento los cambios. En caso contrario, los cambios se pierden.
En el caso de un dataset aprobado con un gran número de dataset fields es posible que tarde en modificarse. Para evitar esperas innecesarias, Anjana redirige al usuario al portal avisando de que la acción tardará en finalizar.
Enviar
La acción de Enviar implica el lanzamiento de un workflow de validación (dejando el objeto en estado pendiente) o la aprobación automática del cambio si procede (dejando el objeto en estado aprobado). Se explica más adelante con detalle la diferencia entre ambas opciones.
El lanzamiento, las aprobaciones o rechazos y el final del workflow de un objeto o su validación automática se auditan y guardan los snapshots correspondientes al objeto.
Esta acción sólo está disponible desde la vista del objeto, de forma que, una vez que el usuario guarda los cambios en el formulario, se activa el botón de Enviar para que pueda ser seleccionado. En el caso de que el objeto ya tenga todos los campos requeridos rellenos al ser creado, el botón está activo al acceder al objeto por primera vez.
En función de la configuración del entorno, puede ocurrir que se modifique o se versione el objeto, que se lance workflow de validación o no.
Modificación o versionado
En Anjana es posible configurar ciertos atributos de las plantillas de las entidades nativas que, al ser editados, generan un nueva versión o, por el contrario, implican una modificación en el objeto original.
Así, en función de los cambios introducidos por el usuario en el objeto y las reglas de versionado configuradas, al finalizar la validación se habrá generado una nueva versión aprobada, deprecando la original, o bien quedará modificado el objeto original.
El versionado solo es posible en entidades nativas. El resto de objetos (entidades no nativas y relaciones) no se versionan nunca si no que solo se modifican con la edición.
Si el objeto original estaba aprobado y se han modificado campos versionables (que son configurables), tras pulsar el botón se reflejan estos cambios en una ventana donde se avisa al usuario de que se va a proceder a crear una nueva versión del objeto.
Al confirmar, se debe elegir la fecha de expiración de la versión anterior del objeto (si no la tenía rellena), que pasará a deprecada al versionar.
En caso de que el objeto original estuviera deprecado o expirado, la edición de cualquier atributo en él genera una nueva versión y se indica al usuario que el motivo del versionado es el cambio de estado del objeto.
Si el objeto a validar es un dataset con un gran número de dataset fields, es posible que tarde en enviarse a validar. Para evitar esperas innecesarias, Anjana redirige al usuario al portal avisando de que la acción tardará en finalizar.
Lanzamiento de workflow o validación automática
También es posible configurar atributos que, al ser editados por ciertos roles en la aplicación, se validan automáticamente sin necesidad de lanzar un workflow de aprobación en el que otros roles deban aprobar o rechazar.
De esta forma, si el usuario con un rol para el que hay una regla de lanzamiento de workflow edita sólo los atributos de la regla, al enviar el objeto a validar obtendrá la aprobación automática.
Sin embargo, si el usuario edita otros atributos o bien no hay una regla de lanzamiento para los roles que tiene asignados, cuando envíe el objeto a validar siempre se lanzará un workflow de aprobación.
Desplegable de acciones
Pulsando sobre el botón de Acciones de la cabecera del objeto o desde el Portal, se abre un desplegable con diferentes opciones. Sin embargo, no todas aparecen a la vez, depende del tipo de objeto, estado del mismo y del rol que el usuario tenga en la unidad organizativa de ese objeto.
Éstas son todas las opciones posibles que pueden aparecer y los objetos a los que aplica cada una de ellas.
Acción |
Dataset |
Dsa |
Proceso |
Instancia |
Solución |
Entidad no nativa |
Relación no nativa |
---|---|---|---|---|---|---|---|
Activar |
|
|
|
|
|
X |
X |
Adherencia directa |
|
X |
|
|
|
|
|
Añadir al carrito |
X |
X |
|
|
|
X |
|
Añadir al workspace |
X |
X |
X |
X |
X |
X |
X |
Añadir dataset_field |
X |
|
|
|
|
|
|
Borrar el objeto |
X |
X |
X |
X |
X |
X |
X |
Cambiar de unidad organizativa |
X |
X |
X |
|
X |
X |
|
Clonar |
X |
X |
X |
X |
X |
X |
X |
Copiar ARI al portapapeles |
X |
X |
X |
X |
X |
X |
X |
Copiar snapshot al portapapeles |
X |
X |
X |
X |
X |
X |
X |
Crear nueva relación |
X |
X |
X |
X |
X |
X |
|
Deprecar |
X |
X |
X |
X |
X |
|
|
Desactivar |
|
|
|
|
|
X |
X |
Desadherir |
|
X |
|
|
|
|
|
Desadherir usuarios de forma masiva |
|
X |
|
|
|
|
|
Descargar metadato |
X |
X |
X |
X |
X |
X |
X |
Descargar snapshot |
X |
X |
X |
X |
X |
X |
X |
Renombrar |
X |
X |
X |
X |
X |
X |
X |
Algunas de las acciones del listado necesitan la validación por parte de los responsables de los objetos. Por ello, cuando el usuario confirma la acción, Anjana comprueba los roles con los que éste puede ejecutarla ya que, en función del rol elegido, es posible que el workflow necesite de unas validaciones o de otras.
En caso de no tener rol con el permiso adecuado, Anjana avisa al usuario de que no puede llevar a cabo la acción deseada.
Si el usuario tiene un solo rol, automáticamente Anjana lanza el workflow correspondiente a la acción elegida para ese rol.
Y, en caso de que el usuario tenga más de un rol con el que pueda ejecutar la acción, Anjana le muestra los roles de los que dispone para que elija con cuál de ellos desea lanzar el workflow.
Activar
La activación de una entidad o relación no nativa supone un cambio de estado de deshabilitado a aprobado en el objeto que debe ser validado.
Cuando el usuario elige la opción de Activar el objeto (entidad o relación), se pide su confirmación y, tras ella, se lanza un workflow de validación para que se apruebe o rechace la activación.
Una vez aprobado por los responsables, el objeto pasa a estado aprobado. La activación de una entidad no nativa gobernada, implica la regeneración de los permisos otorgados por los DSAs en los que está contenida.
El lanzamiento, las aprobaciones o rechazo y el final del workflow de activación se auditan y guardan el snapshot correspondiente al objeto.
Adherencia directa
La adherencia directa a un DSA facilita la solicitud de acceso a los datos que contiene sin necesidad de pasar por el carrito.
En caso de ser un DSA aprobado se permitirá solicitar una adherencia directamente.
Tanto el checkbox como el cuadro de texto del motivo se mantendrán deshabilitados y no se habilitarán hasta que se descargue el contrato o el usuario acceda a la url del mismo para leerlo.
Una vez descargado, se podrá rellenar el formulario y se activará el botón de confirmar.
Al confirmar, se lanzará un workflow de validación para que se apruebe o rechace la adherencia.
Una vez aprobado por los responsables, el usuario pasará a estar adherido al DSA.
El lanzamiento, las aprobaciones o rechazo y el final del workflow de adherencia se auditan y guardan el snapshot correspondiente al objeto.
Añadir al carrito
Para solicitar acceso a los datos de las estructuras o la creación de nuevos DSAs que permitan la adherencia a los mismos, el usuario debe incluir los objetos correspondientes en su carrito.
Se pueden agregar al carrito datasets, DSAs y cualquier entidad no nativa de Anjana en estado aprobado. En el apartado Carrito de la compra de esta Guía se puede ver más detalle de la funcionalidad.
Cuando el usuario añade un objeto al carrito, aparece una confirmación de operación correcta y se incluye en el panel del carrito:
Añadir al workspace
Por medio de esta acción el usuario puede añadir el objeto a su workspace para, posteriormente, trabajar con él desde ahí.
En caso de que el usuario agregue un gran número de objetos al workspace, se mostrará el avance del proceso de esta forma:
En el apartado Workspace se puede ver más detalle de la funcionalidad.
Añadir dataset field
Esta acción facilita la inclusión de nuevos dataset_fields en un dataset en estado importado, borrador, aprobado, rechazado o deprecado (si no tiene otras versiones más actualizadas).
Al elegir esta acción, Anjana redirige al usuario a la pestaña de Estructura del dataset y abre directamente la ventana para introducir los datos del nuevo field a crear:
La creación del nuevo dataset_field se audita y se guarda el snapshot correspondiente al dataset y al field.
Borrar el objeto
El borrado del objeto implica su eliminación del repositorio de Anjana y la eliminación de permisos de acceso a sus estructuras en caso de que se trate de un DSA, quedando auditada la acción. La auditoría y los snapshots que tuviera se mantienen aunque no permiten la navegación al objeto por no existir.
Cuando el usuario elige la opción de Borrar el objeto (entidad o relación), se pide su confirmación y, tras ella, el aviso de que se ha efectuado con éxito el borrado.
En caso de que el objeto a eliminar sea una entidad:
-
Sólo es posible el borrado de una entidad si ésta no tiene ninguna relación con otra entidad. En caso contrario, es necesario eliminar esas relaciones para poder, posteriormente, eliminar la entidad.
-
En caso de que la entidad esté incluida en algún atributo de tipo entidad de otro objeto (entidad, entidades contenidas o array de entidades) también será eliminada del atributo.
Cambiar de unidad organizativa
El cambio de unidad organizativa de una entidad supone el cambio de responsables implicados en la propiedad y custodia del mismo. Sólo es posible cambiar de unidad las entidades aprobadas.
Para ello, el usuario selecciona la nueva unidad organizativa a la que quiera transferir el objeto. Las unidades entre las que puede elegir son aquellas en las que puede dar de alta objetos del subtipo.
Si el usuario elige la misma unidad que tiene la entidad, Anjana le avisa para que seleccione otra para el cambio.
En caso contrario, al confirmar, se lanza un workflow de validación para que se apruebe o rechace la transferencia.
Una vez aprobado por los responsables, la entidad pasará a pertenecer a la nueva Unidad Organizativa. Si se trata de un DSA, además se eliminarán los antiguos responsables de los grupos creados por el DSA en sistemas integrados y se añadirán los nuevos responsables.
El lanzamiento, las aprobaciones o rechazo y el final del workflow de transferencia se auditan y guardan el snapshot correspondiente al objeto.
Clonar
Clonar un objeto (entidad o relación) es crearlo, con estado borrador, como una copia del original independientemente de su estado, cambiando solo su PK.
Esta acción está disponible para cualquier objeto sea cual sea su estado y siempre que el usuario tenga permisos de creación de ese subtipo de objeto.
Por ejemplo, si se clona un dataset se abre un modal para elegir un nuevo nombre, infraestructura, zona… y el nuevo dataset creado tiene los mismos dataset_fields que el original puesto que también se han clonado.
Si el clonado ha sido correcto, automáticamente Anjana dirige al usuario al nuevo objeto creado.
En este caso se auditan el clonado del original y la creación del nuevo objeto. Además, se guarda el snapshot del objeto recién creado.
Copiar ARI al portapapeles
Esta acción permite al usuario copiar la ARI del objeto para, por ejemplo, incluirla en un atributo de tipo entidad de un excel de creación o edición de objetos.
El usuario queda avisado con este mensaje:
Copiar o descargar al portapapeles snapshot
Con ambas acciones el usuario obtiene el .json correspondiente al snapshot (o foto) actual del objeto (entidad o relación) que incluye todo su metadato. Esto permite conocer el valor de sus atributos y las relaciones nativas con otros objetos de Anjana.
Para la copia, se avisa al usuario con este mensaje:
Esta acción está disponible para cualquier objeto sea cual sea su estado.
Además del metadato propio de la plantilla de una entidad, en caso de que la entidad sea origen o destino de una relación, el snapshot también contiene las ARIs de las entidades relacionadas si las relaciones están aprobadas. (La ARI es el identificador interno del objeto en Anjana).
Crear nueva relación
Esta acción facilita la creación de una relación partiendo desde la entidad origen o destino de la misma.
Cuando el usuario elige esta opción, se abre una ventana que permite seleccionar el tipo de relación y su nombre. Los tipos de relación que se muestran en esta ventana son aquellos que admiten el subtipo de la entidad de la que se parte como origen o como destino y para los que el usuario tiene permiso de creación.En esta ventana aparece el campo origen predeterminado con la entidad de la que se parte en caso de que su subtipo sea compatible con las validaciones del campo origen de la relación. Si no es compatible, aparece en el destino de la relación. En ambos casos, el campo contrario está vacío para que lo complete el usuario pudiendo utilizar los filtros de Entidad.
En esta ventana y siempre que las validaciones lo permitan, es posible intercambiar el origen y destino de la relación a crear.
Al elegir el tipo de relación es posible que aparezca algún aviso en el origen o en el destino indicando que solo permite ciertos subtipos de entidad.
Una vez completada la ventana con los datos de la nueva relación y confirmar su creación, aparece un enlace para poder navegar a ella.
Al marcar la opción de “Mantener los valores al crear objeto” y “Confirmar”, no se limpiarán los datos de la ventana para poder crear otra relación similar a la anterior.
La creación de la relación se audita y la inclusión de las entidades origen y destino en ella también. Además, se guarda un snapshot de la nueva relación.
Deprecar
La deprecación de una entidad nativa supone un cambio de estado de aprobado a deprecado en el objeto que debe ser validado.
El lanzamiento, las aprobaciones o rechazo y el final del workflow de deprecación se auditan y guardan el snapshot correspondiente al objeto.
Al seleccionar la acción aparece una ventana para definir o confirmar (si el objeto ya la tuviera rellena) la fecha de expiración del objeto cuando pase a deprecado.
Al confirmar, se lanza un workflow de validación para que se apruebe o rechace la deprecación.
Una vez aprobado por los responsables, la entidad pasa a estar deprecada.
Desactivar
La desactivación de una entidad o relación no nativos supone un cambio de estado de aprobado a deshabilitado en el objeto que debe ser validado.
Cuando el usuario elige la opción de Desactivar el objeto (entidad o relación), se pide su confirmación y, tras ella, se lanza un workflow de validación para que se apruebe o rechace la desactivación.
Al confirmar, se lanza un workflow de validación para que se apruebe o rechace la desactivación.
Una vez aprobado por los responsables, el objeto pasa a estado desactivado. La desactivación de una entidad no nativa gobernada, implica la eliminación de los permisos otorgados por los DSAs en los que está contenida.
El lanzamiento, las aprobaciones o rechazo y el final del workflow de desactivación se auditan y guardan el snapshot correspondiente al objeto.
Desadherir
Esta acción permite al usuario romper la adherencia que tuviera con un DSA para revocar el acceso a los datos de las estructuras que contenga.
La desadherencia no necesita de workflow de validación, es auditada y guarda un snapshot del DSA para actualizar sus usuarios adheridos.
Para poder efectuar esta acción, el usuario debe estar adherido previamente al DSA. Una vez elegida la acción, se pide confirmación de la misma:
Una vez confirmado se ejecuta la desadherencia, mostrando un aviso de éxito y eliminado la adherencia al DSA.
Desadherir usuarios de forma masiva
La desadherencia masiva permite al propietario de un DSA desadherir a varios usuarios a la vez del mismo revocando sus permisos de acceso a sus estructuras.
La desadherencia no necesita de workflow de validación, es auditada y guarda un snapshot del DSA para actualizar sus usuarios adheridos.
La acción redirige a la pestaña Intervinientes del objeto mostrando solo los usuarios adheridos con opción para seleccionar cada uno de los que no son también propietarios del DSA:
Una vez elegidos, al hacer click en el botón “Desadherir” se abre una ventana para poder verificar la lista de usuarios previamente elegidos y confirmar que es correcto:
Si confirma la acción, el propietario recibe un aviso cuando finalice el proceso de la desadherencia:
Descarga de metadato
La descarga de metadato genera y descarga un excel con todo el metadato del objeto seleccionado, incluyendo sus atributos personalizados.
Este excel es similar al generado por Anjana para la creación o edición de objetos.
Contiene:
-
una hoja con la información para saber interpretar el excel y los códigos de colores usados en los atributos que contiene
-
una hoja con el metadato del objeto incluyendo:
-
el id interno en Anjana
-
atributos de plantilla (con su tipo y agrupados por secciones y éstas por menús)
-
unidad organizativa del objeto
-
ARI
-
estado
-
versión
-
usuario creador
-
fecha de creación
-
fecha de última modificación
-
-
una hoja con el metadato de los dataset fields en caso de que el excel descargado sea de un dataset
-
una hoja con los atributos personalizados del objeto que contiene:
-
información del objeto al que pertenece
-
nombre del atributo
-
tipo del atributo
-
valor (o valores, si es un atributo internacional)
-
Renombrar
El renombrado de un objeto permite al usuario cambiar el nombre lógico de un objeto en ciertas circunstancias:
-
si el objeto tiene estado importado, rechazado o borrador y no tiene ninguna otra versión del mismo
-
en este caso no se lanza workflow de validación
-
-
si el objeto tiene estado aprobado, deprecado o expirado y no tiene ninguna otra versión del mismo
-
en este caso el renombrado lanzará el workflow de validación correspondiente a la edición del objeto
-
-
si el usuario es administrador (haciendo uso de API admin)
-
sin lanzamiento de workflow por ser API admin
-
Cuando el usuario elige la opción de Renombrar, Anjana abre una ventana donde éste debe indicar el nuevo nombre y confirmar el cambio.
En caso de que el usuario tenga permiso para renombrar con distintos roles, siendo uno de ellos de administrador, Anjana pregunta el tipo de renombrado a realizar para lanzar workflow de validación o no siguiendo lo comentado anteriormente.
Si se lanza workflow, una vez aprobado por los responsables, el objeto cambia:
-
El nombre (valor del atributo ‘name’) del objeto
-
La ARI del objeto
-
Todos los registros de histórico del objeto
-
Todos los workflows del objeto
-
Todas las notificaciones del objeto (tanto el objeto como el texto)
-
El nodo o la relación en el linaje
-
En caso de ser entidad:
-
Todas las apariciones como origen o destino de una relación
-
El nombre de las relaciones internas en las que la entidad es origen o destino
-
Las ARIs de las relaciones que lo contengan
-
Todas las apariciones como atributo Entidad de otro objeto
-
Todas las apariciones como parte de un atributo de tipo array de entidades de otro objeto
-
El lanzamiento, las aprobaciones o rechazo y el final del workflow de edición para el renombrado se auditan y guardan el snapshot correspondiente al objeto.
Acciones sobre datasets grandes
Debido al elevado número de interacciones efectuadas en acciones sobre datasets con muchos dataset_fields, la aplicación redirigirá automáticamente al Portal cuando el usuario realice alguna que implique cambios importantes, como un cambio de estado o la creación de una nueva versión del dataset.
Algunas de estas acciones son:
-
guardar cambios en la plantilla, añadir field o eliminar field en un dataset aprobado
-
enviar a validar un dataset
-
clonar un dataset
-
borrar un dataset
En estos casos, Anjana mostrará un aviso con mensajes como los siguientes:
NOTA: El número de dataset_fields a partir del que se considera grande el dataset es configurable.