Principe
L’historique d’un composant est composé d’un ensemble de fait. Chaque fait historise une action effectuée par un utilisateur sur un composant et conserve les informations suivantes :
Nom | Automatique | Description |
---|---|---|
id |
oui | Identifiant unique |
creationDate |
oui | Date d’exécution |
user |
oui | Identifiant de l’utilisateur ayant exécuté l’opération |
requestId |
oui | Identifiant de la requête à l’origine de l’action |
technical |
oui | Détermine si le fait est technique ou métier |
action |
non | Action effectuée |
objectId |
non | Identifiant de l’objet concerné |
objectType |
non | Type de l’objet concerné |
Les faits techniques
Les faits techniques sont générés, automatiquement par FlowerDocs Core, lors de l’exécution d’une opération historisée. Pour chaque catégorie de composants, l’enregistrement de faits pour une action donnée peut être activé ou désactivé.
Action | Par défaut | Description |
---|---|---|
create |
oui | Création |
read |
non | Accès |
get_content |
non | Accès à un contenu |
update |
oui | Mise à jour |
add_content |
non | Ajout de contenu |
delete_content |
non | Suppression de contenu |
revert |
oui | Restauration d’une version |
delete |
oui | Suppression physique |
Action | Par défaut | Description |
---|---|---|
create |
oui | Création |
read |
non | Accès |
update |
oui | Mise à jour |
assign |
oui | Assignation |
add_content |
oui | Ajout de pièce(s) jointe(s) |
delete_content |
oui | Suppression de pièce(s) jointe(s) |
answer |
oui | Application d’une réponse |
delete |
oui | Suppression physique |
Action | Par défaut | Description |
---|---|---|
create |
oui | Création |
read |
non | Accès |
update |
oui | Mise à jour |
add_content |
oui | Ajout de componsant(s) |
delete_content |
oui | Suppression de componsant(s) |
delete |
oui | Suppression physique |
Action | Par défaut | Description |
---|---|---|
create |
oui | Création |
read |
non | Accès |
update |
oui | Mise à jour |
delete |
oui | Suppression physique |
Afin de modifier les actions historisées, le fichier core.properties
doit être modifié en s’appuyant sur la configuration par défaut :
fact.registrations.document=create,update,delete,version,revert
fact.registrations.folder=create,update,add_content,delete_content,delete
fact.registrations.virtual.folder=create,update,delete
fact.registrations.task=create,update,delete,answer,assign,add_content,delete_content
Les faits métiers
Un fait métier est généré de manière programmatique afin d’historiser, pour un composant, un état ou une action particulière. Cette génération doit être configurée ou développée spécifiquement pour les situations concernées grâce :
- aux APIs exposées pour chaque catégorie de composant
- l’objet ContextUtil
L’utilisateur à l’origine de la génération d’un fait métier doit disposer du rôle ADMIN
.
Dans l’interface graphique, un fait technique est lié à un fait métier s’ils possèdent le même identifiant de requête (requestId
).
Les faits techniques générés avant et liés à un fait métier sont affichés dans ses détails.
POST {core}/rest/documents/{id}/facts HTTP/1.1
token: {token}
Content-Type: application/json
{
"action": "custom",
"description": "Generated by REST API.",
"updatedFields": [
{
"name": "tag",
"value": "text"
}
]
}
//ScriptOperationHandler
var builder = com.flower.docs.common.fact.FactBuilder.objectId(component.getId()).type('DOCUMENT');
builder.action('custom').description('Generated by script operation handler.').field('tag', 'text');
util.createFact(builder.build());
La configuration de l’historique
FlowerDocs met à disposition une classe de document FactFieldsConfiguration
permettant de définir en simple paramétrage les tags à historiser sur les faits générés.
Ce document permet de définir :
- le type d’objet :
DOCUMENT
,TASK
,VIRTUAL_FOLDER
,FOLDER
- les identifiants de classes de composant
- les identifiants de tag
Ce document de configuration est accessible dans l’interface d’administration de FlowerDocs : Configuration > Faits d’historique.