Formulaires Baserow : créer des lignes, modifier des enregistrements ou partager des vues

Un lien d’inscription ne devrait pas donner à un participant les mêmes accès qu’à un organisateur.

Prenons une équipe produit fictive qui organise un événement dans Baserow. Les nouvelles inscriptions nécessitent un formulaire public. Les corrections nécessitent un lien vers la ligne existante. Une liste de statuts nécessite un partage en lecture seule.

Les exemples utilisent des champs fictifs Nom, E-mail, Session et Statut. Le statut relève de la décision de l’organisateur. Ce guide s’appuie sur la documentation de Baserow : aucune instance n’a été configurée et aucun envoi de formulaire n’a été testé. Les vérifications proposées restent à effectuer.

Choisir le lien selon l’action : créer, mettre à jour ou consulter

Baserow indique que les envois de formulaires ordinaires créent de nouvelles lignes. Sa fonction de lien de modification de ligne, distincte, relie une ligne existante précise à un formulaire prérempli. Pour permettre la consultation plutôt que la modification, utilisez une vue partagée publiquement.

Les destinataires peuvent utiliser ces modes de partage sans invitation à l’espace de travail. Cette facilité ne signifie pas que vous savez qui utilise le lien.

Le guide du partage public décrit les formulaires comme acceptant de nouveaux envois plutôt que la modification de données existantes. Cela correspond au formulaire public ordinaire. Baserow documente séparément les mises à jour de lignes existantes dans la fonction de lien de modification de ligne.

Utiliser un formulaire public Baserow pour les nouvelles inscriptions

Exposer uniquement les champs que la personne doit renseigner

Commencez par une table de test distincte. Dans le menu déroulant des vues de la table, sélectionnez Formulaire, choisissez le type d’autorisation disponible et donnez un nom à la vue. Le guide des formulaires décrit la configuration et indique que les champs compatibles de la table apparaissent automatiquement.

Pour cet événement fictif, les participants renseignent Nom et E-mail, puis choisissent une Session. Masquez Statut dans les paramètres de la vue Formulaire. Vérifiez les libellés, les réponses obligatoires et les options de Session avant de partager le lien.

Un envoi ordinaire crée une ligne même si l’adresse e-mail correspond à une inscription existante. Baserow n’empêche pas automatiquement les doublons. Décidez qui examinera les doublons présumés et quel traitement leur sera appliqué.

L’aperçu mérite une attention particulière. Il ouvre la véritable URL publique, et un envoi depuis cet aperçu écrit des données réelles. Limitez ces essais à la table de test fictive.

Traiter les valeurs préremplies et les messages de confirmation comme des éléments de présentation, pas comme des preuves

Le même guide documente des paramètres de requête tels que ?prefill_Name=Example et ?hide_Field. Ce sont des aides à la présentation. Les destinataires contrôlent leur URL : une valeur préremplie ne peut donc pas établir leur identité. Une valeur d’approbation masquée par un paramètre de requête ne permet pas non plus de justifier l’acceptation d’une inscription. Si l’attribution à une campagne doit être fiable, un simple préremplissage ne suffit pas. Le masquage des champs dans la vue Formulaire est un paramètre distinct.

Une confirmation contenant {row_id} identifie l’enregistrement créé. Elle ne prouve pas que la personne possède l’adresse e-mail renseignée et ne dit rien sur l’achèvement des tâches en aval. De même, la validation des champs obligatoires et des types de champs peut vérifier des contraintes de saisie sans établir la véracité d’une réponse.

Utiliser un lien de modification de ligne pour corriger une inscription existante

Configurer un formulaire de mise à jour dédié et le champ de lien de modification de ligne

Créez une vue Formulaire réservée aux corrections. Exposez uniquement Session si c’est le seul élément que le participant doit corriger. Gardez Statut masqué dans les paramètres de la vue Formulaire.

Passez ensuite à la vue Grille, ajoutez un champ de type Lien de modification de ligne et sélectionnez cette vue Formulaire de mise à jour dans ses paramètres. Les instructions de configuration de Baserow indiquent que cela génère une URL unique pour chaque ligne. L’ouverture d’un lien affiche les valeurs actuelles de cette ligne ; l’envoi met à jour la ligne existante sans en créer une autre.

Ajouter un préremplissage à l’URL d’un formulaire ordinaire n’en fait pas un lien de mise à jour. Le champ de lien de modification de ligne établit la connexion documentée avec l’enregistrement existant.

Protéger le lien et prévoir les modifications contradictoires

La documentation du lien de modification de ligne précise que toute personne disposant du lien peut voir les données préremplies exposées et envoyer des modifications pour cette ligne. Traitez l’URL comme un mot de passe. Envoyez-la en privé. Excluez ce champ des listes publiques et vérifiez les captures d’écran avant de les partager. Évitez également d’inclure des liens actifs dans des exemples copiables ou dans les outils d’analyse des URL.

La possession du lien ne vérifie pas l’identité. Le processus ne devrait pas non plus dépendre d’un usage unique ou d’une expiration automatique sans preuve que ces contrôles existent.

La documentation indique que l’envoi le plus récent est enregistré ; elle ne promet ni fusion des réponses ni avertissement de conflit. Décidez qui résoudra les modifications contestées.

Vérifiez séparément la révocation. La documentation mentionne la suppression du formulaire, le retrait d’un champ de la vue Formulaire ou la régénération du jeton lorsque cette option est disponible. La portée du retrait d’un champ est incertaine : ne confondez pas le masquage d’une saisie avec la révocation de tout le lien de la ligne. Confirmez le contrôle applicable, puis vérifiez l’accès par l’ancien lien avec des données jetables ; aucun bouton universel de réinitialisation des jetons n’est établi.

Utiliser les vues partagées pour informer en lecture seule, sans permettre aux participants de modifier les données

Configurer les champs visibles, les filtres et les exportations avant le partage

Réservez une vue Grille ou Galerie à la liste de statuts. Affichez uniquement des valeurs fictives de Session et de Statut ; excluez E-mail, les valeurs de Nom inutiles et tous les liens de modification de ligne.

La documentation du partage public de Baserow décrit les vues Grille et Galerie partagées comme accessibles en lecture seule et précise que les champs masqués le restent lors de l’ouverture détaillée des enregistrements. Configurez les champs et les filtres avant de diffuser l’URL. Examinez la liste initiale et les enregistrements détaillés depuis une session déconnectée.

Pour une grille partagée, l’option Autoriser l’exportation de la vue partagée est désactivée par défaut selon la documentation. Lorsqu’elle est activée, les exportations respectent les filtres et les champs masqués configurés. Vérifiez le périmètre d’exportation avec des enregistrements inventés ; demander de ne pas télécharger les données ne remplace pas ce paramètre.

Distinguer un mot de passe partagé d’une autorisation individuelle

Un mot de passe associé à un lien de partage public reste un secret partagé. Il ne permet ni d’identifier chaque lecteur ni d’établir des autorisations d’accès aux lignes fondées sur l’identité. Intégrer la vue dans une iframe ne change pas les personnes qui peuvent y accéder.

Selon le guide du partage, la génération d’une nouvelle URL de partage public invalide l’URL précédente. Ne supposez pas que cela révoque également tous les jetons de modification de ligne.

Lorsque les liens circulent par e-mail, vérifiez le public destinataire séparément des autorisations accordées à destination. Le guide Optijara sur la distinction entre publication, accès en lecture et destinataires des e-mails explore cette distinction dans Ghost, sans traiter de la configuration de Baserow.

Effectuer une vérification préalable Créer-Mettre à jour-Consulter avant d’envoyer un lien

Préparer un jeu de données de test sans risque

La vérification préalable Créer-Mettre à jour-Consulter d’Optijara est la liste de contrôle proposée par ce guide. Ce n’est ni une fonctionnalité de Baserow ni un cadre de sécurité validé. Vérifiez l’action prévue, les données visibles et la désactivation du lien.

Préparez des inscriptions inventées dans une table distincte. N’utilisez aucune adresse e-mail réelle. Les identifiants de production et les jetons actifs des destinataires restent également en dehors du jeu de test. Désignez une personne responsable de la diffusion et de la désactivation de chaque lien, et notez les champs que le destinataire peut modifier.

Ce diagramme résume la décision, pas le fonctionnement interne de Baserow. Son équivalent textuel correspond aux trois modes de partage du tableau d’ouverture.

Vérifier l’action prévue et l’exposition involontaire

Utilisez les comportements documentés des formulaires, de la modification de ligne et du partage comme résultats attendus, puis examinez les données enregistrées. Aucune des vérifications suivantes n’a été effectuée pour ce guide.

Si les corrections simultanées ont une importance pour le processus, ajoutez un test de concurrence sur une ligne jetable et notez quel envoi est conservé. Examinez la ligne enregistrée ou le résultat d’accès pour chaque vérification ; un message de remerciement ne constitue pas une preuve suffisante.

Consigner les attentes avant un futur test

Consignez les attentes, les observations ultérieures et les questions non résolues. Le JSON ci-dessous est une note de préparation comportant des identifiants en minuscules, pas une charge utile d’API ni un résultat de test. Dans la table Baserow fictive, le champ réservé à l’organisateur porte toujours le nom Statut.

{
  "playbook": "create-update-view-preflight",
  "fixture": "fictional-event-registrations",
  "actions": ["create", "update", "view"],
  "organizerOnlyField": "status",
  "retirement": "verify-per-link-type",
  "executionStatus": "not-run"
}

Vérifiez également que les personnes peuvent utiliser le formulaire. Lisez ses libellés et essayez la navigation au clavier, y compris le parcours des erreurs de validation. Le guide Playwright d’Optijara sur les tests des états affichés des formulaires propose une approche de test distincte. Son jeu de test local ne teste pas Baserow, et les vérifications automatisées d’accessibilité ne permettent pas d’établir une conformité complète.

Erreurs courantes : attribuer les mêmes autorisations à tous les liens Baserow

Une adresse e-mail qui semble familière n’est pas une instruction de mise à jour d’une ligne existante. Les envois ordinaires et les corrections propres à une ligne suivent des chemins différents. Publier une colonne de liens de modification est une autre erreur : cela diffuse des identifiants d’accès, même si la colonne ressemble à un simple champ de référence.

Les contrôles des champs demandent aussi une lecture attentive. La visibilité dans la vue Formulaire diffère du masquage par URL que l’utilisateur contrôle. Les autorisations de modification au niveau des champs répondent à un autre besoin. Le guide des autorisations de champ de Baserow précise qu’elles limitent la modification, sans masquer les valeurs existantes aux membres disposant d’un accès à la table. Les lectures par API renvoient toujours les données des champs lorsqu’un accès à la table existe.

N’invitez pas un participant comme Membre de l’espace de travail simplement pour recueillir une correction. La présentation des autorisations décrit un accès étendu à l’espace de travail pour les Membres des offres Free et Premium. Le contrôle d’accès granulaire fondé sur les rôles (RBAC) au niveau des bases de données et des tables est associé aux offres Advanced et Enterprise, avec des distinctions de licence entre le cloud et l’auto-hébergement. Vérifiez votre déploiement au lieu de supposer qu’une invitation à l’espace de travail donne un accès limité.

Limites, vérification de l’offre et suivi après le lancement

Ce guide fondé sur la documentation n’est ni une implémentation exécutable, ni un test de déploiement, ni un audit de sécurité. Vérifiez votre version déployée et votre offre actuelle, puis confirmez les contrôles dont dépend votre processus.

Le mode sondage est une option de présentation payante ; les formulaires standard sont disponibles avec l’offre gratuite. Cette présentation n’est pas nécessaire pour choisir entre créer, mettre à jour ou consulter, et ce guide ne prédit aucune amélioration du taux de complétion.

La transmission de liens à d’autres personnes peut compromettre un plan de diffusion pourtant soigneusement préparé. Une divulgation accidentelle nécessite également une réponse, tandis que les inscriptions en double et les corrections contradictoires imposent un travail de rapprochement. Prévoyez les ressources nécessaires à ce travail au lieu de supposer que le formulaire le supprime.

Les informations sensibles ou les exigences de vérification des utilisateurs nécessitent une conception distincte des accès. Si des comptes nominatifs deviennent nécessaires, le guide Optijara de préparation de la connexion et de la récupération des comptes apporte des éléments de contexte. Ce n’est pas un mode d’emploi pour une intégration à Baserow. La connexion d’une personne ne résout pas à elle seule la question des autorisations au niveau des enregistrements.

Après l’implémentation, tenez un bref journal de suivi. Utilisez-le pour évaluer le processus au lieu de supposer qu’il fait gagner du temps. Aucune mesure n’a été recueillie pour ce guide.

Utilisez le journal pour améliorer les instructions ou changer de mode de partage. Confiez les questions d’accès non résolues à un responsable.