...
Campo | Descripción | Propiedades |
---|---|---|
id | Identificador único del comunicado. | Autogenerado Obligatorio Primary Key |
codigo | Código del comunicado. Será un código único dentro de la gestión que lo genera. | Obligatorio |
fechaLimite | Fecha límite para la realización de las acciones que se indiquen en el comunicado. | Opcional |
vigencia | Días de vigencia del comunicado a contar desde su fecha de creación (fecha comunicado). | Obligatorio |
destinatarios | Lista de destinatarios (personasRef) del comunicado. | Formato JSON (varchar (5000)) {destinatariosdestinatariosListaDistribucion: [ "personaRef1",personaRef2, ...], destinatariosPersonas:["personaRef1",personaRef2, ...], aniadirIPsProyecto: "true", aniadirIPsSolicitud: "false"} Opcional a nivel de modelo de datos / Obligatorio a nivel funcional que para un registro esté informado bien este campo o bien el campo permisos (Pendiente de concretar caso de comunicados Generales) |
permisos | Lista de permisos que han de tener los destinatarios del comunicado. Se enviará el comunicado a todos los usuarios que tengan asociado al menos uno de esos permisos. Si se ha informado el campo destinatarios, se hará la combinación de ambos campos, enviando el comunicado tanto a los destinatarios de la lista como a los que además tengan alguno de los permisos indicados (eliminando los duplicados, claro). El módulo/gestión llamante es la que gestionará el catálogo de permisos que tiene que enviar para cada comunicado que genera. Desde el módulo de comunicados se llamará al módulo de usuarios para obtener la lista de usuarios asociados a la lista de permisos indicados. | Formato JSON (varchar (5000)) {permisos: [AES-MER-VAL, ...] } Opcional a nivel de modelo de datos / Obligatorio a nivel funcional que para un registro esté informado bien este campo o bien el campo permisos. (Pendiente de concretar caso de comunicados Generales) |
parametros | Lista de parametros a reemplazar en el campo descripcion de un comunicado tras recuperar su texto "plantilla" del fichero de recursos del módulo de comunicados. El catálogo de claves o identificadores de cada parámetro (ej: divulgacion, fecha, ...) las ha de tener el módulo llamante para informarnos qué valor se quiere dar a cada uno. En una primera aproximación, se supondrá que los comunicados no informan este dato hasta confirmar su necesidad. | Formato JSON (varchar (5000)) { parametros: [{divulgacion: "texto a poner"}, {fecha: "fecha a poner"}, ...] } Opcional |
modulo | Dato de texto que representará el identificador de un módulo y se utilizará para componer la url de acceso a la gestión que generó el comunicado o que requiere que se realice alguna acción en base al mismo. Ej: "3" que podría corresponder al módulo de CSP. | Opcional en el modelo de datos / Obligatorio funcionalmente si se informa el tipoEntidad |
tipoEntidad | Dato de texto que representará al tipo de entidad, siendo un valor de una enumeración y se utilizará para componer la url de acceso a la gestión que generó el comunicado o que requiere que se realice alguna acción en base al mismo. Ej: "33" que podría corresponder a la entidad "Proyecto" | Opcional en el modelo de datos / Obligatorio funcionalmente si se informa el idEntidad |
idEntidad | Dato de texto que representará el identificador concreto de una entidad y se utilizará para componer la url de acceso a la gestión que generó el comunicado o que requiere que se realice alguna acción en base al mismo. Ej: "333", identificador del proyecto que requiere revisar algún dato. | Opcional |
fechaCreacion | Campo que está ya contemplado para todas las tablas del modelo y que en este caso se utilizará para utilizarla como dato de fecha de comunicado. | Obligatorio |
...