[test retour] Composant privacy Joomla 3.9

Réduire
X
 
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • miledda
    a répondu
    Cela semble être effectivement un problème de case à cocher : sur mon formulaire de création d'usager, la case "j'accepte" semble être automatiquement cochée, pas d'autre case visible si ce n'est le terme "non" sur la droite. Impossible d'envoyer le formulaire avec cette configuration, il revient toujours avec la mention "veuillez accepter ..." et se bloque avec impossibilité de changer de page. En décochant la case "j'accepte", je suis arrivé à valider une fois mon formulaire.
    Cela dit, je ne suis pas plus avancé pour autant, j'ai donc désactivé le plugin "privacy" en attendant des jours meilleurs.

    Laisser un commentaire:


  • miledda
    a répondu
    Même problème chez moi, j'ai désactivé le plug-in

    Laisser un commentaire:


  • chalet
    a répondu
    AIDEZ MOI SVP

    je gere 3 sites sur joomla 3.9.5

    sur 2 sites le plug in confidentialité fonctionne correctement c a d après identification on a bien le profil , on coche acceptation des règles de confidentialité et ensuite sans problème on navigue sur le site
    le 3me site , je reste bloquer sur l'écran du profil et on a beau accepter la politique de confidentialité on reste bloquer sur cet écran
    comment peut on débloquer la situation
    merci pour vptre aid

    Laisser un commentaire:


  • chalet
    a répondu
    A priori que j'accepte ou non cela fait le m^me PB

    Laisser un commentaire:


  • RobertG
    a répondu
    Bonjour,

    N'aurais-tu pas un problème de télescopage des coches d'acceptation et de refus, sur ton formulaire ? ça arrive avec certains templates.

    Laisser un commentaire:


  • chalet
    a répondu
    bonjour

    je gère 3 sites sur Joomla.
    sur 2 sites le plug in Confidentialité fonctionne correctement , sur le 3 eme site , impossible de valider la politique de confidentialité ..le systeme reste bloquer sur l'écran d'accepation et pour m'en sortir je suis obligé de desactiver le plug in sur le poste administrateur pour pouvoir continuer à utiliser le site
    y a t il une manoeuvre que j'ai omis de faire

    Laisser un commentaire:


  • Erix
    a répondu
    Salut,

    Merci Pascal pour les remontés d'info, à mon tour : Nouvelle RC de J!3.9 le 23/10 (jour de la sortie officielle qui était prévue), du coup J!3.9 sortira le 30/10
    On l'aura un jour, on l'aura....
    Bonne journée à tous

    Laisser un commentaire:


  • pmleconte
    a répondu
    Bonsoir,

    Eric vient de nous prévenir que la 3.9 beta 3 est disponible pour test : https://www.joomla.fr/actualites/joo...blie-pour-test

    La bonne nouvelle est que les dates officielles de mise à disposition se précisent : version RC : 9 octobre, version stable : 23 octobre.

    A vos tests, vite.......

    Pascal

    Laisser un commentaire:


  • pmleconte
    a répondu
    Bonjour,

    Pour info, la version 3.9 Beta est disponible depuis hier POUR TEST : https://developer.joomla.org/news/74...r-testing.html

    Bons tests,

    Pascal

    Laisser un commentaire:


  • sandra97
    a répondu
    Bonjour à tous,

    Pour simplifier les choses et limiter les problèmes de langue et d'incompréhension, je vais vous traduire les réponses de Michael au dernier message de Yannick sur GitHub (traduction libre par moi)


    Il n'y a pas de préférence sur les notifications reçues par les super utilisateurs, donc on ne comprend pas vraiment où vous voyez un bogue. Et je ne crois pas que com_messages utilise cette bascule dans le profil de l'utilisateur au sujet de la réception de courriels du système.

    Les demandes urgentes sont un simple élément de backend pour dire à un administrateur de prêter attentions aux requêtes. Il n'y a pas de raisons d'ajouter du texte au frontend pour décrire ce détail du système. Le texte personnalisé peut être créé grâce à une substitution de mise en page. Je ne suis pas sûr que l'ajout de champs de texte libre ou d'une description trop générique forcée profite au plus grand nombre.

    Les consentements par courriel ne sont pas stockés puisque pour envoyer ce courriel vous devez donner votre consentement, lorsque le plugin est activé, et le fait que vous ayez reçu un courriel est une preuve de consentement. Les consentements stockés en backend ne sont pas pour des actions simples comme l'envoi d'un email. Aussi, c'est au développeur d'extensions d'y logger le nécessaire, nous ne tenterons pas de détourner d'autres extensions pour pousser des choses dans nos outils de base.

    Et comme le système est déjà verrouillé aux super-utilisateurs, l'ajout d'une capacité DPO est excessif par rapport à l'ingénierie, car au départ il faudrait envoyer des notifications à des utilisateurs sélectionnés, puis ensuite il faudrait des ACL à appliquer à ce rôle, et c'est impossible puisque les super-utilisateurs ont 'tout pouvoir'.

    Si vous souhaitez répondre sur GitHub, vous pouvez le faire en français, ce sera plus simple, et soit Michael traduira avec Google soit je lui traduirai vos réponses.

    Merci et bonne soirée !
    Dernière édition par cavo789 à 03/09/2018, 20h15

    Laisser un commentaire:


  • sandra97
    a répondu
    "Tout est ok sauf qu'il me semblait qu'il devrait y avoir une case à coché pour le consentement dans un formulaire de contact."
    Il y a une case à cocher pour consentir à la politique de confidentialité pour com_contact, mais il faut que tu actives le plugin de consentement.

    Laisser un commentaire:


  • schott0200
    a répondu
    Bonjour à tous, je test Joomla! 3.9 alpha et j'essai d'écrire un tuto simple.
    Tout est ok sauf qu'il me semblait qu'il devrait y avoir une case à coché pour le consentement dans un formulaire de contact.
    Je l'ai bien pour les inscriptions des internautes, mais pas dans le formulaire de contact est-ce normal ?

    Merci à vous

    Cyrille

    Laisser un commentaire:


  • daneel
    a répondu
    Merci Yannick,

    On continue les tests...
    The Privacy Tool Suite by Joomla - The Joomla Project is pleased to announce the release of Joomla 3.9 Alpha 1

    Laisser un commentaire:


  • y.berges
    a répondu
    aller j'ai posté ici ... avec mon petit niveau https://github.com/joomla-projects/p...ork/issues/241

    Laisser un commentaire:


  • y.berges
    a répondu
    A notre avis il manque
    Au niveau backend :
    - dans le module : pouvoir cliquer sur le active request (c'est con mais c'est tellement plus simple)
    - une alerte dit bien que la requête a été traitée sur le moment mais AUCUNE info ne dit que la demande a bien été traitée. Les requêtes traitées restent affichées comme confirmées si bien qu'on peut les traiter et les retraiter indéfiniment ...
    Il est prévu visiblement un statut "completed" mais la requête reste bien en "confirmed" => le passage en statut "completed" se fait manuellement en cliquant sur la requête puis en appuyant sur un bouton.. ce qui n'est absolument pas pratique.
    Si ça ne se fait pas automatiquement lorsqu'on clique sur la croix ou l'enveloppe, il faudrait au minimum que ça puisse se faire depuis la liste des requête avec des cases à cocher + un bouton "marquer comme complété" par exemple
    - Probème sur les requettes faite depuis le backend : Une seule l'adresse renseignée dans ce champ est notifiée. Un administrateur peut donc faire une requête pour un user sans que ce dernier ne soit au courant. La RGPD impose que les personnes en charge du traitement des données soient formées mais ne serait-il pas tout de même mieux d'envoyer 2 emails : 1 à l'adresse renseignée et 1 à l'adresse liée au compte ?
    - Besoin de stocké l'information consentie en bdd
    - Corriger le bug sur l'envoi d'email à tous les super admin
    - Ajouter une fonction DPO, c'est à dire désigner qui recevra les emails de demande (un champ select qui permet de selectionner 1 ou plusieurs utilisateur)

    Au niveau front :
    - view "create request :
    pouvoir afficher un texte explicaif (c'est quoi chaque requette) gérer par un string de langue et qui reprend les delai de parametre "day to consider request urgnet" + les informations sur le profil
    une partie texte libre
    => l'objectif est de rendre plus explicite cette vue car là c'est super abrut pour le enduser

    Villi pour le retours des utilisateur FR


    Laisser un commentaire:

Annonce

Réduire
Aucune annonce pour le moment.

Partenaire de l'association

Réduire

Hébergeur Web PlanetHoster
Travaille ...
X