ypicot

Membres
  • Compteur de contenus

    939
  • Inscription

  • Dernière visite

  • Jours gagnés

    13

ypicot a gagné pour la dernière fois le 9 décembre 2016

ypicot a eu le contenu le plus aimé !

À propos de ypicot

  • Rang
    800
  • Date de naissance 01/10/1963

Contacts

  • Website URL
    http://www.ypicot.fr

Profil général

  • Genre
    Homme
  • Lieu
    banlieue sud de Paris

Profil FileMaker

  • FM Conférence
    Paris 2009
  • FM
    FMP8 - 9
  • OS
    WinXP-Linux
  • Certification
  • FBA
    --Non membre--

Visiteurs récents du profil

15 185 visualisations du profil
  1. J'en suis sûr, vous adorez les réglementations qui vous expliquent comment faire votre métier... Bon, ok... Cela concerne notamment ceux qui développent dans et pour leur entreprise, mais aussi les clubs et tout organisme qui stocke des données personnelles. Pour les professionnels (c'est à dire ceux qui bouffent grâce à FM), je pense nécessaire de suivre la chose pour en informer vos clients, ou au moins ne pas tomber des nues si on vous en parle. Je vous fais grâce de la version originale, le wikipedia présente l'essentiel : https://fr.wikipedia.org/wiki/Règlement_général_sur_la_protection_des_données Un lien un peu plus complet tout en restant lisible : https://www.brainwavegrc.com/fr/besoins-brainwave/besoins-techniques-en-securite-informatique-brainwave-grc/gdpr-reglement-general-sur-la-protection-des-donnees-rgpd/ Yvan
  2. Si tu as trouvé un généreux donateur pour une version à peu près récente (on va dire >=12), très bien. Sinon, tu peux te plonger dans le monde de l'open source, et notamment Dolibarr qui est un produit utilisé par de nombreuses sociétés. Yvan
  3. Un site sympa et actuel (responsive et tout) sur lequel les produits ne sont même pas chinois... pfff... aucun intérêt, je ne peux même pas balancer mon fiel... Yvan
  4. Bonjour Hypothèse de départ : tu connais aussi bien FM qu'APEX (ou tu es prêt à te mettre à niveau). Si tu ne connais pas APEX, attention, le produit est un gros poil plus complexe à appréhender que FM, et l'admin Oracle est plus péchue que l'admin FMS. Je dirais que les points centraux sont la complexité de l'application et le design des écrans / états. - appli simple (principalement du CRUD), avec des formulaires (et surtout des états) complexes / chargés : avantage à FM, avec lequel tu gagneras beaucoup de temps sur le design des modèles. - appli complexe, nécessitant par exemple une analyse poussée de flux des données, et des formulaires simples : APEX. Un des soucis d'APEX sont les technos annexes à maitriser si tu veux une interface un peu travaillée : CSS, mais aussi javascript et souvent jquery / bootstrap / ... (heureusement pour moi, je suis toujours resté dans les templates de base). Le temps que tu vas passer à fignoler tes écrans / pdf peut largement bouffer le prix des licences. Dans une appli complexe, le temps de développement sera plus ou moins le même dans les deux environnements (à compétence égale), et la différence de prix des licences devient sensible. Autre point (mineur) : si tu penses à maxapex pour ton hébergement, je te déconseille celui à $14 : jasper report est très utile. Plusieurs autres arguments sont à prendre en considération : - le fait que l'existant est en FM : les utilisateurs ne seront pas dépaysés (gains sur la formation, et le coût invisible du temps d'adaptation est diminué) - comme cité plus haut, APEX est plus difficile à maitriser - les compétences APEX sont assez rares en France (le produit a beaucoup moins bien pris qu'en Allemagne / Benelux / Angleterre, pour ne citer que l'Europe) - les deux points précédents posent le pb de la pérénité pour APEX. Détail important : je n'ai pas fait d'APEX 5 (j'ai bossé avec la v2 et la v4), je ne connais donc pas la dernière version, et le gap de version est souvent sensible chez Oracle (ça, c'est pour les "évolutions" de FM14 à FM15). Il est donc possible que certains arguments soient moins pertinents avec la v5. Yvan
  5. Réaction suite à mes premiers essais : mais c'est GENIAL ! En plus, le truc semble assez modulaire, donc facilement adaptable. Par contre, un chouilla plus complexe que 2 tables liées et 5 lignes de script. Il va falloir que je fasse tourner en pas à pas pour regarder comment ça marche, et surtout comprendre (et progresser). Un peu mis en forme, cela pourrait tout à fait figurer dans une bibliothèque de script. Je n'hésiterai pas à revenir ici s'il y a un point que je ne comprends pas (pour l'instant, la table list_ est un peu mystérieuse, mais je vais m'appliquer à décortiquer son utilisation dans les scripts. Il me semble que c'est le coeur de la Virtual List évoquée dans ce fil). Grand merci à Eric et Philippe pour ce travail remarquable ! Yvan
  6. Autant que je me souvienne, l'usage des robots (et donc de toute api) pour la lecture est même interdit par les CGU du boncoin (à vérifier cependant). Je ne serai pas surpris que l'interface de vente fasse appel à des routines javascript ou autre, ce qui rend l'interface plus agréable mais son automatisation plus délicate. C'est la raison pour laquelle j'ai tendance à utiliser des services tiers : ils assurent la compatibilité entre tes besoins et l'interface web. Si l'interface web change (ce qui arrive assez régulièrement, même si ce n'est pas visible à l'oeil nu), c'est à eux de se dém... pour adapter leurs routines de transfert. Yvan
  7. Oula... ca chauffe dur... J'ai complètement la tête dans le guidon (sur une problématique toute autre), et je constate sans aucun plaisir que je fais parti des moins actifs sur ce fil . Même pas de neurone dispo ne serait-ce que pour lancer FM. La situation devrait grandement s'améliorer dès ce week-end, et je regarderai avec beaucoup d'attention vos différentes contributions. En tous cas, merci par avance. Yvan
  8. Je te suggère de jeter un oeil sur lbcposter.fr Yvan
  9. En gros, Alex veut créer un export. Il créé donc un modèle, dans lequel il choisit des champs, qu'il ajoute (ou enlève). Il peut partir d'un modèle existant (un "modèle modèle") comme tu le suggères (ce qui est une excellente idée). Par exemple, il va créer un export "adresse", contenant uniquement les données postales des clients. Béa peut également créer un export de son coté, différents de celui d'Alain (concernant le CA du mois de chaque client). Bien sûr, Alex, Béa et Chris (un troisième larron) peuvent, par la suite, utiliser l'un ou l'autre des modèles pour reproduire l'export sans redéfinir les champs à chaque fois. Yvan
  10. Désolé la réponse tardive, j'ai eu pas mal de lait sur le feu... En fait, chaque utilisateur peut créer un ou plusieurs modèles, auxquels tous les autres utilisateurs ont accès. Donc pas de problème de droits d'accès de ce coté-là. Pour info, j'utilise déjà le mode tableau (mais de façon beaucoup plus primaire que dans la vidéo) quand j'ai des utilisateurs qui sont hélas très marqués par excel et ne veulent pas trop de changement. Philippe, ta solution ne permet pas hélas d'enregistrer la structure de l'export (ce qui fait parti de mes besoins), mais je te remercie pour l'effort. Merci tcolles pour cette vidéo, mais as-tu l'autorisation de la personne qui présente les tableaux (un certain Tanguy je-sais-pas-quoi) pour diffuser la vidéo ? (ok, je sors...) Yvan
  11. FM peut être utilisé en arrière-plan (pour la partie admin du site), mais pour le site lui-même, ce n'est peut-être pas la solution idéale. Les solutions FM sont soit mal adaptées à ton cas (incompatibilité connue de WebDirect avec Firefox) soit demandent un temps de développement non négligeable, avec une courbe d'apprentissage assez raide (passage par PHP). Des solutions utilisant des formulaires pur web clé en main (genre typeform) ont été évoquées sur ce forum. Il te restera un certain nombres d'opérations à faire à la main (transfert des données du web vert FM via un fichier .csv, ...), mais qui dit "pas de prog" dit souvent "à faire à la mimine". Yvan
  12. Heuuu... Je n'ai pas trouvé comment dupliquer (et encore moins ouvrir en mode création) un modèle par script. D'après ce que j'ai compris, il faut passer par la gestion des modèles. Par contre, je crois que j'ai trouvé comment autoriser la modification d'un formulaire et pas d'un autre. Il faut passer par une gestion des menus assez fine (par défaut, les utilisateurs sont en "menu minimum", ce qui grise le bouton "modifier modèle"), mais cela doit être jouable. Merci pour cette piste intéressante. Yvan
  13. Bonjour à tous Mémoriser les champs d'un export (pour pouvoir refaire l'export plus tard, avec les mêmes champs dans le même ordre) est facile : il suffit de créer un script. Oui mais voilà : dans mon appli, l'éditeur de scripts n'est pas accessible à l'utilisateur. Or, mes utilisateurs souhaitent sortir régulièrement différents exports (typiquement 3-4 par mois, similaires mais pas forcément identiques d'un mois à l'autre). Le scénario souhaité est le suivant : - l'utilisateur filtre ses enregs à partir du joli modèle que j'ai fait rien que pour lui. - il clique sur un bouton, qui affiche le pop-up regroupant les exports pré-enregistrés qui ont déjà été réalisés - si l'export souhaité existe, il le lance - si l'export souhaité n'existe pas, il le créé (avec une petite description) Existe-t-il un plug-in (ou une solution à laquelle je n'ai pas pensé) qui permette d'enregistrer plusieurs exports ? Merci par avance Yvan
  14. Je ne suis pas certain de comprendre ton besoin, donc il est possible que je réponde à coté. L'idée est de ne pas stocker login (et encore moins le pw) dans l'url. L'uuid que tu décris (qui est bien souvent le résultat d'un hachage quelconque) est stocké en base, dans la même table que le login et le pw. Quand ton script reçoit un un uuid, il le recherche simplement dans la base, lit le login de l'utilisateur, et ouvre une session avec. Deux remarques cependant : - ne pas stocker le pw en clair est très-franchement-beaucoup conseillé (en cas de compromission de la base) - en principe, ce genre de système est à usage unique, et limité dans le temps (lien valable 24h par exemple). A utiliser, par exemple, en cas de perte du pw. N'oublie pas que la confidentialité d'un email est à peu près celle d'une carte postale : beaucoup de gens peuvent y accéder sans faire trop d'effort, sans compter les différents piratages de boite. Quand tu développes pour le web, il faut être paranoïaque. Yvan
  15. Cette directive interdit tout logiciel fait maison sans liaison externe, quel que soit l'environnement de développement. En effet, qui dit "c'est fait maison" dit "je suis admin", donc "je peux tripatouiller les données", et le texte cherche justement l'impossibilité de tripatouillage (tous ceux qui ont travaillé dans l'hôtellerie / restauration -mais pas seulement- comprendront parfaitement le sens de ce texte). D'après ce que j'ai compris (à vérifier, donc), le seul moyen de s'en sortir est de prévoir une liaison avec l'extérieur, liaison à travers laquelle le logiciel enverra à "un tiers de confiance" une copie de chaque transaction au moment ou celle-ci est réalisée. En d'autres termes, quand je créé une pièce comptable (ticket de caisse ou facture), j'envoie immédiatement une copie de ladite pièce à une société qui ne fait que la recevoir et l'archiver, mais qui en cas de contrôle peut garantir qu'elle ne sera jamais modifiée ou effacée. Et qui, accessoirement, n'oubliera pas de me facturer ce service. Yvan