rvelices a écrit:
rub,
merci d'avoir repondu ...
Je commence à émerger de mes congès... lol
rvelices a écrit:
- pour #forbidden_images, calculate $userdata['forbidden_images'] et compute_cat_branch - ok pour un plugin (facile/pas de souci)
- pour get_sql_condition_FandF - justement je fais le test sur forbidden_images seulement si le champs n'est pas id, auquel cas je teste directement la colonne#images.level (plus performant) et ca arrive dans 95% des cas. c'est plutot rare d'appeler get_sql_condition_FandF avec la colonne 'image_id'. on pourrait effectivement faire une bidouille ici de sorte que les plugins indiquent soit unre requete sql, soit le comportement par defaut - mais ca va etre lourd
Pas si lourd que ca!
rvelices a écrit:
pour l'admin j'ai vraiment pas de solution miracle, si ce n'est parsemer le code avec trigger_event ou tout simplement dupliquer les pages pour le plugin ... pour etre honnete aucune des solutions ne me convient - tout ca pour pouvoir editer un pauvre champ pour l'image et l'autre pour les users ...
Par contre, la, c'est vrai que c'est lourd.
Ce sera sans doute plus facile par la suite quand l'admin aura vécu des ajouts de triggers.
rvelices a écrit:
c'est marrant pour authorized_..., j'avais pense deja a la meme chose (notamment pour une gallerie comme celle de vimages ou le guest a 2000 categories non autorises et les utilisateurs normaux ont 2000 autorises)
Alors pourquoi ne pas le faire?
rvelices a écrit:
rub, pour etre honete je prefererais de mettre tout ca en standard pour 2 raisons: j'avais pratiquement fini le code debut aout (notre derniere echange) et 2ement les triggers qu'on devrait mettre seront bien plus comliques que de mettre directement le code directement dans le noyau ...
Coupons la poire en 2.
Intégration en standard avec si possible l'utilisation des deux en même temps.
+ intégration de triggers, authorized, activation/désactivation des 2 systèmes de permissions pour que les développeurs de plugin puissent faire leur gestion de permissions.
Non?
Hors ligne
rub a écrit:
rvelices a écrit:
c'est marrant pour authorized_..., j'avais pense deja a la meme chose (notamment pour une gallerie comme celle de vimages ou le guest a 2000 categories non autorises et les utilisateurs normaux ont 2000 autorises)
Alors pourquoi ne pas le faire?
Personnes ne l'avais demande jusqua maintenant ... Mais vu un post recent sur 366000 photos ... j'ai l'impression qu'il n'y a pas que ca a changer ...
rub a écrit:
rCoupons la poire en 2.
Intégration en standard avec si possible l'utilisation des deux en même temps.
+ intégration de triggers, authorized, activation/désactivation des 2 systèmes de permissions pour que les développeurs de plugin puissent faire leur gestion de permissions.
Non?
oui mais on le fera en plusieurs steps. de toute maniere je pars mercredi prochain pour 10 jours, donc je commiterai apres, ensuite j'attends tes commentaires et on continue ...
Hors ligne
rvelices a écrit:
Mais vu un post recent sur 366000 photos ... j'ai l'impression qu'il n'y a pas que ca a changer ...
rub a écrit:
Coupons la poire en 2.
Intégration en standard avec si possible l'utilisation des deux en même temps.
+ intégration de triggers, authorized, activation/désactivation des 2 systèmes de permissions pour que les développeurs de plugin puissent faire leur gestion de permissions.
Non?oui mais on le fera en plusieurs steps. de toute maniere je pars mercredi prochain pour 10 jours, donc je commiterai apres, ensuite j'attends tes commentaires et on continue ...
+1
8-)
Hors ligne
rvelices a écrit:
oui mais on le fera en plusieurs steps. de toute maniere je pars mercredi prochain pour 10 jours, donc je commiterai apres, ensuite j'attends tes commentaires et on continue ...
Parfait! +1
On pourrait donner par défaut un plugin de permissions de test.
Hors ligne
Salut
je voulais savoir si vous pensez que je pourrai faire mes modifs de la gestion de la securité sous forme de plugin ou non finalement ?
car moi j ai rajouté la notion de categorie REFUSEE ... c est a dire que meme si tu y as droit par un groupe mais qu elle t est refusee par un autre
tu ne la verras pas ... j avais modifié la fonction de calcul des permissions donc est ce que ca pourra marché ?
a+
Hors ligne
Nicco a écrit:
je voulais savoir si vous pensez que je pourrai faire mes modifs de la gestion de la securité sous forme de plugin ou non finalement ?
Surement.
Donne nous ce que tu as fait! Comme ca, ca nous permettra de faire un plugin de test.
Hors ligne
merci rub c est bien sympa !!!
je vais te faire ca pour ce lundi je pense
car avant ca va etre chaud
Hors ligne
Bonjour tout le monde.
Tout d'abord félicitations pour votre implication, je suis nouvel utilisateur de PWG et je dois dire que je ne suis pas du tout déçu !
Si je me permets de me mêler à cette discussion (et de faire une apartée vis à vis des posts précédents), c'est pour vous demander pourquoi vous n'avez pas prévu (sauf erreur de ma part malgré moult recherches), en mode admin, une option dans la page synchroniser pour rendre les répertoires (categories) nouveaux privés par défaut ?
La seule voie que j'ai trouvé, c'est de modifier une ligne de php dans config_default.inc.php, mais je dois dire que ce n'est peut etre pas forcément évident pour un utilisateur ne maitrisant pas beaucoup le php (même si ce n'est pas très compliqué, avec les infos que j'ai trouvé au début de ce sujet)...
Dans la même idée, ces nouveaux répertoires (categories) pourraient etre par défaut autorisés ou non pour certains groupes (chose que je ne sais pas comment modifier pour le moment - mais je n'ai pas encore beaucoup recherché)...
[Contexte : Ma galerie a un fonctionnement privé, je souhaite rendre chaque categorie privée et ne l'autoriser qu'à un groupe famille...]
J''espère que je ne suis pas passé à côté d'une info déjà signalée sur un autre forum, mais qui ne semble en tous cas pas dispo sur le wiki.
N'hésitez pas à me resolliciter si toutefois je n'étais pas très clair lol
En vous remerciant pour votre implication !! Bon courage !
Hors ligne
Oui oui, c'est bien un des paramètres à mettre dans un fichier config_local.inc.php!
$conf['newcat_default_status'] = 'private';
Il est déconseillé de modifier le fichier config_default.inc.php directement (car lors d'une mise à jour, le fichier default sera écrasé, contrairement au fichier local)
Pour en savoir plus sur le fichier config_local.inc.php -> cf ici
Tous les paramètres modifiables via le fichier config_local.inc.php ne sont pas listés dans le wiki, il suffit d'ouvrir le config_default.inc.php pour avoir toutes les explications (certe, en anglais, et c'est bien dommage!)
Pour une utilisation simplifiée de ces fichiers, utilise le plugin Local File Editor, qui te permet d'éditer facilement dans le panneau d'admin ton fichier config_local.inc.php (et d'afficher dans une fenetre séparée le fichier config_default.inc.php)
Dernière modification par P@t (2007-09-01 16:09:11)
Hors ligne
P@t a écrit:
Oui oui, c'est bien un des paramètres à mettre dans un fichier config_local.inc.php!
$conf['newcat_default_status'] = 'private';
Il est déconseillé de modifier le fichier config_default.inc.php directement (car lors d'une mise à jour, le fichier default sera écrasé, contrairement au fichier local)
Pour en savoir plus sur le fichier config_local.inc.php -> cf ici
Tous les paramètres modifiables via le fichier config_local.inc.php ne sont pas listés dans le wiki, il suffit d'ouvrir le config_default.inc.php pour avoir toutes les explications (certe, en anglais, et c'est bien dommage!)
Pour une utilisation simplifiée de ces fichiers, utilise le plugin Local File Editor, qui te permet d'éditer facilement dans le panneau d'admin ton fichier config_local.inc.php (et d'afficher dans une fenetre séparée le fichier config_default.inc.php)
Merci beaucoup !!
Je viens de faire la modification suite à ton post (modification qui fonctionne parfaitement), et j'en ai déduit que PWG est bien concue <pour les màj par exemple...>.
Je n'avais pas encore vue cette page du wiki !! Mais c'est vrai que sans ce topic, il ne me serais jamais venu à l'idée d'ouvrir ce fichier là (et l'anglais ne me pose aucun soucis :o) lol Heureusement que vous êtes là !!
Concernant le 2nd point de mon post, as-tu une idée de comment procéder ? Est-ce quelque chose de paramétrable ?
Je rappelle ci dessous ce que je souhaiterais faire :
-> lors de l'ajout d'une nouvelle catégorie par synchronisation, je voudrais qu'un de mes groupes soit automatiquement autorisé à voir cette catégorie (qui est créée privée grâce à la modif $conf['newcat_default_status'] = 'private'; ).
Ou à défaut, que le groupe ait pour cette nouvelle catégorie les mêmes droits que la catégorie parente.
Est-ce possible ?
Encore merci pour le support, et pour les tuyaux.
Bon courage !
Dernière modification par zener (2007-09-01 16:50:16)
Hors ligne
je me souviens qu'il y avait un souci avec la propagation des permissions lors de la création des catégories filles.
De mémoire, résolu pour la 1.7.1; fais une recherche sur le forum ou sur mantis (outil des bugs)
Hors ligne
mathiasm a écrit:
je me souviens qu'il y avait un souci avec la propagation des permissions lors de la création des catégories filles.
De mémoire, résolu pour la 1.7.1; fais une recherche sur le forum ou sur mantis (outil des bugs)
Alors j'ai suivi tes conseils, et parcouru le forum.
Effectivement, d'autres utilisateurs ont évoqué le même désir de voir un (des) groupe(s) obtenir le même niveau d'autorisation que la catégorie parente. On peut voir cela sur deux topics là ou celui là.
Suite à cela, le problème semble avoir été tracé dans mantis ici, et la modification implémentée (cf là).
La modification semble donc avoir été effectuée le 26/07/2007, en local par flop25, mais la 1.7.0 date de May dernier, et sauf erreur de ma part, il s'agit de la seule version estampillée 1.7 que je puisse trouver en download (cf là).
J'en ai fini avec mais ici ou là lol.
Donc pour conclure, je suppose que je dois attendre la future version 1.7.1. Avez-vous une date prévue pour la sortie ?
Si la date est reculée, pensez-vous que je puisse modifier le code trouvé là ? Dans ce cas de figure, il est possible que je sollicite votre aide pour faire les modifs aux bons endroits.
Merci chaleureusement pour votre support.
Bon courage !
Hors ligne
zener a écrit:
J'en ai fini avec mais ici ou là lol.
Donc pour conclure, je suppose que je dois attendre la future version 1.7.1. Avez-vous une date prévue pour la sortie ?
Si la date est reculée, pensez-vous que je puisse modifier le code trouvé là ? Dans ce cas de figure, il est possible que je sollicite votre aide pour faire les modifs aux bons endroits.
Merci chaleureusement pour votre support.
Bon courage !
Pas de date.
Tu peux tenter la modif en direct. Tu fais une sauvegarde avant, et tout devrait rouler
Hors ligne
Suite au commit 2084 / issue 731 sur l'intégration de la confidentialité:
o au niveau de la liste des utilisateurs, le terme "Public" (etc.) n'est pas forcément clair.
Ne pourrait-on pas trouver une formule reprenant le terme confidentialité?
Ou afficher cette propriété en premier?
Ou passer une ligne après cette propriété?
o au niveau de cette même liste, je pense qu'il serait nécessaire de pouvoir faire un filtre sur le niveau de confidentialité, non?
PS: Sans aucun doute la confidentialité va faire un carton!
Hors ligne
T'es vraiment rapide toi... :-)
rub a écrit:
o au niveau de la liste des utilisateurs, le terme "Public" (etc.) n'est pas forcément clair.
Ne pourrait-on pas trouver une formule reprenant le terme confidentialité?
Ou afficher cette propriété en premier?
Ou passer une ligne après cette propriété?
J'ai pas bien compris le 2eme point (afficher en premier). J'ai laisse Public car je n'ai pas trouve un autre terme, mais si tu trouves un - c'est avec plaisir ...
rub a écrit:
o au niveau de cette même liste, je pense qu'il serait nécessaire de pouvoir faire un filtre sur le niveau de confidentialité, non?
Yes.
Hors ligne