🌍
Français
Eric a écrit:
.... je n'exclue pas de l'extraire vers un nouveau plugin dédié.
+1
ok je sors je deviens lourd :-D
Je résous ce topic car je suis arrivé à mes fins grâce à l'aide de ddtddt (merci encore à lui ! ^^).
Pour info, j'ai opté pour une redirection systématique vers la page de personnalisation avec affichage d'un message d'avertissement tant que l'utilisateur n'a pas changé son mot de passe. Finalement, je trouve çà moins intrusif que de fermer purement et simplement l'accès à la galerie et suffisamment pénible pour, qu'à terme, les utilisateurs concernés fassent ce qu'on attend d'eux.
Pour la partie admin > Utilisateurs > Gérer, il y aura ajout d'une nouvelle colonne présentant l'état des mots de passe pour chaque user (mot de passe à changer, changé ou d'origine) et une fonction pour initier le renouvellement de mot de passe pour x users sélectionnés.
Dans un premier temps, cette fonction apparaitra dans la prochaine version de UserAdvManager mais, après une période de rodage, je n'exclue pas de l'extraire vers un nouveau plugin dédié.
ddtddt a écrit:
pour le préfiltre sur la page user list un truc du genre ->
Ok, j'ai pigé le truc ! C'est "loc_begin_admin" qui me manquait pour faire fonctionner mon pré-filtre !
En combinant l'ajout d'une colonne pour afficher les états et l'ajout d'un pré-filtre pour permettre l'action, ce sera parfait. Merci beaucoup pour le coup de main ! :-))
Nos posts se sont croisés. Je vais regarder ce que tu proposes comme code ;-)
Si, si, tu as raison d'insister car je ne dois pas m'y prendre (savoir m'y prendre) correctement pour cette histoire de pré-filtre. Comme je l'ai dit, j'ai déjà utilisé un pré-filtre pour le plugin NBM Subscriber qui ajoute des options dans la page profile de l'utilisateur inscrit.
Mais je ne parviens pas à reproduire le fonctionnement dans user_list... Quelque chose m'échappe encore :-/
Parallèlement, j'ai essayé une autre approche en ajoutant une colonne et une action dans user_list grâce au trigger loc_visible_user_list comme ceci :
add_event_handler('loc_visible_user_list', 'UAM_loc_visible_user_list');
function UAM_loc_visible_user_list($visible_user_list)
{
global $template;
$template->append('plugin_user_list_column_titles', l10n('UAM_pwdreset'));
$user_ids = array();
foreach ($visible_user_list as $i => $user)
{
$user_ids[$i] = $user['id'];
}
$user_nums = array_flip($user_ids);
$pwdreset_url = get_root_url().'admin.php?page=user_perm&user_id=';
// Query to get informations in database
if (!empty($user_ids))
{
$query = '
SELECT DISTINCT id, UAM_pwdreset
FROM '.USERS_TABLE.'
WHERE id IN ('.implode(',', $user_ids).')
;';
$result = pwg_query($query);
while ($row = mysql_fetch_array($result))
{
if ($row['UAM_pwdreset'] == 'false')
{
$pwdreset = l10n('UAM_PwdReset_Done');
}
else if ($row['UAM_pwdreset'] == 'true')
{
$pwdreset = l10n('UAM_PwdReset_Todo');
}
else $pwdreset = l10n('UAM_PwdReset_NA');
$UAM_PwdReset_Action = UAM_Set_PwdReset($row['id']);
$visible_user_list[$user_nums[$row['id']]]['plugin_columns'][] = $pwdreset; // Shows users password state in user_list
$visible_user_list[$user_nums[$row['id']]]['plugin_actions'][] = $UAM_PwdReset_Action; // Add action for each user to reset password
}
}
return $visible_user_list;
}Pour l'ajout de la colonne et des infos pour chaque user listé, pas de problème, çà fonctionne bien. Mais pour l'action qui permettra de programmer la demande de changement du mot de passe, çà ne fonctionne pas. Il faudrait que je remplace "$UAM_PwdReset_Action" par un lien qui serait lié à la fonction UAM_Set_PwdReset($row['id']) pour initier l'action mais là, je sèche un peu...
Sans parler du fait que, dans ce cas, le traitement par lot ne sera pas possible. Je préfèrerai vraiment parvenir à mettre en place un pré-filtre comme tu le suggères. Ce serait bien mieux et plus facile à gérer.
Pour NBM subscriber, j'avais fait ceci:
/* Adding NBMS in profile page */
add_event_handler('load_profile_in_template', 'NBMS_Load_Profile');
function NBMS_Load_Profile()
{
global $conf, $user, $template, $lang;
$query = '
SELECT enabled
FROM '.USER_MAIL_NOTIFICATION_TABLE.'
WHERE user_id = \''.$user['id'].'\'
;';
$data = pwg_db_fetch_assoc(pwg_query($query));
$values = $data['enabled'];
$template->assign('radio_options',
array(
'true' => l10n('Yes'),
'false'=> l10n('No')));
$template->assign(
array(
'NBMS'=>$values
));
$template->set_prefilter('profile_content', 'NBMS_prefilter');
}
/* Original template modification */
function NBMS_prefilter($content, &$smarty)
{
global $template, $lang;
load_language('plugin.lang', NBMS_PATH);
$search = '<p class="bottomButtons">';
$addon = '{if $ALLOW_USER_CUSTOMIZATION}
<fieldset>
<legend>{\'NBMS_Section\'|@translate}</legend>
<ul>
<li>
<span class="property">{\'NBMS_Text\'|@translate}</span>
{html_radios name=\'NBM_Subscription\' options=$radio_options selected=$NBMS}
</li>
</ul>
</fieldset>
{/if}';
$replacement = $addon.$search;
return str_replace($search, $replacement, $content);
}
?>Je m'étais basé sur le trigger "load_profile_in_template" pour initier mon pré-filtre dans profile.php mais je ne trouve pas de point d'entrée similaire pour user_list. Si tu as la solution... ;-)
le truc que j'oublie régulièrement quand je fais des pré filtre c'est de forcer la recompilation ;-)
pour le préfiltre sur la page user list un truc du genre ->
//add prefiltre user_list
add_event_handler('loc_begin_admin', 'userlistericf',60);
function userlistericf()
{
global $template;
$template->set_prefilter('user_list', 'userlistericT');
}
function userlistericT($content, &$smarty)
{
$search = '#<table class="table2" width="97%">#';
$replacement = '
<div>
<form method="post" >
<fieldset>
eric
</fieldset>
</form>
</div>
<table class="table2" width="97%">';
return preg_replace($search, $replacement, $content);
}
je ne veux pas insister mais si tu fait un préfiltre sur la page user_list.tpl quest ce qui t'empêche de gérer ton lot ?
Eric a écrit:
ddtddt a écrit:
je n'ai pas regarder ce que tu as fait.
Les pré filtres sur l'admin sont possible, j'en ai sur plusieurs plugins (meta, andinffo, title, addinfouser ...)J'ai regardé comment fonctionnent tes plugins mais aucun d'eux n'interagit avec des pages de l'administration de Piwigo. addinfouser, par exemple, ajoute un fieldset et des champs dans profile.tpl côté utilisateur. C'est ce que je fais aussi avec mon autre plugin NBM Subscriber car les mécanismes de "pré filtrage" sont bien présents dans profile.php.
Mais il ne le sont pas dans user_list.php !
quand tu edit une photo avec meta / title ou addinfo tu as des éléments en plus sur la page d'édition provenant du plugin
La page profile de l'admin n'est pas la même que celle du publique et quand tu edite un profil user à partir de l'admin tu as bien les infos du plugin
ddtddt a écrit:
je n'ai pas regarder ce que tu as fait.
Les pré filtres sur l'admin sont possible, j'en ai sur plusieurs plugins (meta, andinffo, title, addinfouser ...)
J'ai regardé comment fonctionnent tes plugins mais aucun d'eux n'interagit avec des pages de l'administration de Piwigo. addinfouser, par exemple, ajoute un fieldset et des champs dans profile.tpl côté utilisateur. C'est ce que je fais aussi avec mon autre plugin NBM Subscriber car les mécanismes de "pré filtrage" sont bien présents dans profile.php.
Mais il ne le sont pas dans user_list.php !
ddtddt a écrit:
je vais peux être dire une bêtise mais si tu ajoutes ta colonne avec un bout de javascript qui agit directement dans ta table quand tu coches ou décoches les utilisateurs dont tu souhaites forcer à changer de mot de passe ?
cela ne résoudrait pas ton problème ?
Ajouter une colonne où ? Dans le tableau des utilisateurs de user_list.tpl ? Cà, je sais faire mais je n'y connais pas grand chose en javascript. Ce n'est pas vraiment ma tasse de thé... ;-)
Mais si on fait comme tu le proposes, on ne pourra pas faire de traitements par lot.
Je pense à ajouter un bouton d'action dans la colonne "Actions" du tableau d'utilisateurs de user_list. En plus des boutons existants comme "profile" et "permissions". L'inconvénient c'est que, là aussi, on ne pourra pas faire de traitements par lot.
je n'ai pas regarder ce que tu as fait.
Les pré filtres sur l'admin sont possible, j'en ai sur plusieurs plugins (meta, andinffo, title, addinfouser ...)
--------------------
je vais peux être dire une bêtise mais si tu ajoutes ta colonne avec un bout de javascript qui agit directement dans ta table quand tu coches ou décoches les utilisateurs dont tu souhaites forcer à changer de mot de passe ?
cela ne résoudrait pas ton problème ?
Oui, j'ai déjà eu à utiliser les pré filtres pour un autre de mes plugins mais cela n'impactait pas la partie admin de Piwigo. Je n'arrive pas à faire fonctionner un pré filtre sur user_list.
Faut que je creuse encore... J'ai l'impression de passer à côté de quelque chose.
Eric a écrit:
Un template-extension saurait arriver à ce résultat, je pense. Mais est-il seulement possible d'arriver à cela via un plugin ?
Via un thème on peut le faire avec l'aide d'un pré filtre...
J'ai pas mal avancé sur le sujet. Finalement, je vais faire au plus simple : Un utilisateur que l'admin aura marqué comme "mot de passe à changer" sera systématiquement redirigé vers sa page de personnalisation à chacun de ses connexions et un message explicite s'affichera pour l'inciter à faire ce qu'on attend de lui.
Cette partie est déjà codée et fonctionnelle ainsi que la gestion du changement du mot de passe (lorsque l'utilisateur en question a changé son mot de passe comme souhaité, il n'est plus redirigé et il n'a plus le message).
Maintenant, je bloque sur la partie admin de la fonction.
Comme je l'ai annoncé dans mon premier post, je ne souhaite pas générer à nouveau un tableau des utilisateurs d'une galerie pour permettre à l'admin de sélectionner ceux qui devront changer leur mot de passe. Autant utiliser celui qui existe déjà.
Dans user_list.php, il y a le trigger loc_visible_user_list qui permet d'ajouter des colonnes et des fonctions au tableau existant mais ne permet pas d'ajouter une action dans les sections en dessous du tableau. Idéalement, dans le user_list.tpl, il faudrait que je puisse avoir ceci (ligne 102):
{* delete the selected users ? *}
<fieldset>
<legend>{'Deletions'|@translate}</legend>
<label><input type="checkbox" name="confirm_deletion" value="1"> {'confirm'|@translate}</label>
<input class="submit" type="submit" value="{'Delete selected users'|@translate}" name="delete">
</fieldset>
{* Reset password of the selected users ? *}
<fieldset>
<legend>{'PasswordReset'|@translate}</legend>
<label><input type="checkbox" name="confirm_pwdreset" value="1"> {'confirm'|@translate}</label>
<input class="submit" type="submit" value="{'Reset Pwd selected users'|@translate}" name="PwdReset">
</fieldset>Un template-extension saurait arriver à ce résultat, je pense. Mais est-il seulement possible d'arriver à cela via un plugin ?
Eric a écrit:
Mais çà devient un peu HS, là. Gotcha va sévir ;-)
Il y a "hors sujet" et "hors sujet" ;-)