Un prompt peut-il remplacer Quickbase ?

Construis une application de fiches dont la fonctionnalité déterminante est des permissions au niveau du champ appliquées à la couche de données.

Schéma : des tables avec des champs typés en texte, texte long, nombre, devise, date, booléen, liste déroulante simple, liste déroulante multiple, pièce jointe, référence utilisateur, et relation vers une autre table. Les relations exposent un champ de correspondance et un agrégat (compte, somme, min, max) côté parent.

Rôles et permissions, qui sont le cœur de ce projet. Un rôle contient, par table, une règle au niveau de l’enregistrement (tous les enregistrements, les enregistrements où un champ utilisateur est égal à l’utilisateur actuel, les enregistrements correspondant à une expression de filtre) et, par champ, l’une de : caché, lecture, ou écriture. Les permissions ne sont pas une préoccupation d’affichage :

- Chaque lecture passe par un constructeur de requêtes qui ne sélectionne que les champs que le rôle peut lire. Un champ caché ne doit jamais apparaître dans une réponse pour être ensuite filtré dans le navigateur.
- Chaque écriture valide que le rôle peut écrire chaque champ modifié, en rejetant toute l’écriture sinon, plutôt que d’abandonner silencieusement des champs.
- L’API retourne exactement ce que le rôle peut voir, avec les mêmes règles que l’interface.
- L’export produit exactement les champs lisibles, avec le rôle et la liste de champs enregistrés dans le journal d’export.
- La recherche ne correspond jamais au contenu d’un champ que le rôle ne peut pas lire, parce qu’un résultat de recherche est une fuite d’information même quand le champ n’est pas affiché.

Écris des tests pour chacun de ces cinq chemins spécifiquement. Des permissions de champ correctes dans l’interface et qui fuient dans l’export ou l’API sont l’échec normal de cette fonctionnalité, et les tests sont ce qui l’arrête.

Vues : grille, kanban regroupé par un champ liste déroulante, et calendrier sur un champ date. Les vues sont par rôle et ne peuvent référencer que des champs que ce rôle peut lire.

Formulaires : un formulaire par table exposant un sous-ensemble choisi de champs modifiables, publiable pour les utilisateurs authentifiés ou, optionnellement, publiquement pour un rôle création seule.

Audit : chaque création, modification et suppression enregistrée avec l’acteur, le rôle, les champs modifiés, et leurs valeurs avant et après — avec le journal d’audit lui-même soumis aux permissions de champ, pour qu’un rôle qui ne peut pas lire un champ ne puisse pas lire son historique non plus.

Administration : éditeur de rôles avec une matrice de permissions, et un mode aperçu qui rend n’importe quelle table exactement comme un rôle choisi la verrait. Personne ne configure les permissions correctement sans pouvoir regarder à travers les yeux de quelqu’un d’autre.

Hors périmètre : le SSO et le provisionnement d’annuaire, les pipelines d’automatisation inter-applications, un langage de formules au-delà des agrégats et de l’arithmétique simple, et tout déploiement multi-locataire hébergé.