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());
Faits personnalisés
Un fait personnalisé est créé en dehors des historiques natifs du produit. Il peut être :
- Un fait métier : trace une action métier (ex. création d’un courrier).
- Un fait technique : trace une opération technique (ex. intégration avec un CRM).
La distinction se fait via un booléen, mais l’objet Java est identique. Lors de la création de faits personnalisés via un OperationHandler
, l’utilisateur enregistré dans le fait sera, par défaut, l’utilisateur administrateur exécutant l’OH. Ceci est du aux privilèges administratifs qui garantissent la sécurité et évitent des manipulations non autorisées.
Si vous souhaitez tracer l’utilisateur réel ayant initié l’action, vous pouvez personnaliser la description.
Exemple avec le FactBuilder :
var builder = FactBuilder.objectId(component.getId()).type('DOCUMENT');
var userDisplayName = util.getUserService().get(...).getDisplayName();
builder.action('CREATE').description(userDisplayName + ' created the document.');
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.