Il est aujourd’hui possible d’ajouter manuellement les champs techniques created_dt/updated_dt dans le modèle de l’objet métier puis d’appliquer un filtre min;max. Cette solution implique de polluer le modèle de l’objet concerné avec des informations techniques.
Est-il possible - dans la configuration / ts évoquée ci-dessus - que le dispositif de des API mappées prenne en charge le routage du filtre min;max positionné dans la requête API (ex. /api/MyExternalMappedAPIV1/myresource?myresfield=abdc&updated_dt=2000-01-01;2999-12-31) sans qu’il soit nécessaire d’ajouter les champs techniques dans le modèle ?
→ dans l’exemple cité, “myresfield” est un champ mappé via addField(“myresource”, “myresfield”, …) mais updated_dt ne l’est pas.
→ ce comportement des API mappées serait aligné avec le comportement de la UI qui permet de filtrer sur les metadonnées created_dt/updated_dt si les options sont activées et sans surcharger le modèle de l’objet.
Oui c’est surement envisageable de mapper de manière transparente les attributs techniques updated/create_dt/by, je regarde les impacts et je te tiens au courant.
Vos normes définissent elles un nommage par défaut pour ce type d’attributs ?
OK c’est fait, il sera désormais possible d’utiliser les filtres techniques suivants (non visibles dans les réponses):
_createdDate
_createdBy
_updatedDate
_updatedBy
Il sera aussi possible d’explicitement les mapper via la nouvelle méthode addTimestampFields(mappedObjectName), ils sont alors visibles dans les réponses.
