Workflow : suppression permission DELETE pour rôle MODERATOR

user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:aaf9ed5fc09accaee3b593672355c136' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour, \nL\'implémentation d\'ORI-OAI est actuellement en cours à l\'INSA de Lyon.\n</div>\n', created = 1507746172, expire = 1507832572, headers = '', serialized = 0 WHERE cid = '4:aaf9ed5fc09accaee3b593672355c136' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:aaf9ed5fc09accaee3b593672355c136' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour, \nL\'implémentation d\'ORI-OAI est actuellement en cours à l\'INSA de Lyon.\n</div>\n', created = 1507746172, expire = 1507832572, headers = '', serialized = 0 WHERE cid = '4:aaf9ed5fc09accaee3b593672355c136' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:8ea5336a1661066edf2623b88adfd18b' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,\nJe souhaite enlever la permission DELETE pour le rôle MODERATOR dans le \nworkflow \"easy\" (version v1.1).\nSous la v1.0, j\'avais réussi en modifiant la transition \"Ask to Publish\" \ndans le workflow \"easy\" \n(ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml).\nJ\'ai appliqué la même recette pour la v1.1, à savoir :\n**************************** \n<step id=\"1\" name=\"Private\"> \n... \n<action id=\"1\" name=\"Ask to Publish\">\n<post-functions>\n... \n <function type=\"spring\"> \n <arg name=\"bean.name\">addPermission</arg>* \n* <arg name=\"mask\">128</arg> \n\n(au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine).\n*****************************\nJ\'ai fait un \"ant all\", puis un \"ant update-acls\".\nMais apparemment, le rôle MODERATOR peut toujours supprimer les fiches \nque lui demande de publier l\'auteur. \n(case à cocher toujours présente dans la première colonne). \nOr, sous la v1.0, la case à cocher n\'était plus visible après cette \nmodif !! (le modérateur ne pouvait alors plus \"Supprimer\" une fiche \nqu\'il avait à examiner)\nY aurait-t-il un pb de cache avec le module workflow ? (dois-je attendre \nun certain temps après la modif ?)\nSinon, comment désactiver cette fonctionnalité \"Supprimer\" pour MODERATOR ?\nMerci !\nJacques\n-- \nJacques Brassart \nUNR Nord-Pas de Calais \nUniversité de Valenciennes et du Hainaut-Cambrésis \nTél : 03 27 51 17 70\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746173, expire = 1507832573, headers = '', serialized = 0 WHERE cid = '4:8ea5336a1661066edf2623b88adfd18b' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:67b43f911b5bee63bba00af45dabf738' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour Jacques,\nDans la version 1.1, le role moderator part avec le masque de permission \nmoderate + delete, comme défini dans acegi-acl-root.xml :\n<bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\">\n<property name=\"mask\" value=\"48\"/>\n<property name=\"recipient\" value=\"4\"/>\n </bean> \nDonc le fait de NE PAS ajouter la permission DELETE ne suffit pas, il \nfaut lui ôter en ajoutant des les post-fonctions :\n<function type=\"spring\"> \n <arg name=\"bean.name\">deletePermission</arg> \n <arg name=\"mask\">16</arg>\n <arg name=\"recipient\">4</arg>\n </function>\nCordialement,\nFrançois\nJacques Brassart a écrit : \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour, \n> \n> Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans \n> le workflow \"easy\" (version v1.1). \n> \n> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n> Publish\" dans le workflow \"easy\" \n> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n> \n> \n> J\'ai appliqué la même recette pour la v1.1, à savoir : \n> \n> **************************** \n> <step id=\"1\" name=\"Private\"> \n> ... \n> <action id=\"1\" name=\"Ask to Publish\"> \n> \n<post-functions>\n> ... \n> <function type=\"spring\"> \n> <arg name=\"bean.name\">addPermission</arg>* \n> * <arg name=\"mask\">128</arg> \n> \n> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n> \n> ***************************** \n> \n> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n> \n> Mais apparemment, le rôle MODERATOR peut toujours supprimer les fiches \n> que lui demande de publier l\'auteur. \n> (case à cocher toujours présente dans la première colonne). \n> Or, sous la v1.0, la case à cocher n\'était plus visible après cette \n> modif !! (le modérateur ne pouvait alors plus \"Supprimer\" une fiche \n> qu\'il avait à examiner) \n> \n> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n> attendre un certain temps après la modif ?) \n> \n> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n> MODERATOR ? \n> \n> Merci ! \n> \n> Jacques \n> \n></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746174, expire = 1507832574, headers = '', serialized = 0 WHERE cid = '4:67b43f911b5bee63bba00af45dabf738' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:31e87b5fc3d6294650e5d9534d951870' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour François,\nCa ne fonctionne toujours pas ! \nLa case à cocher apparaît toujours pour le rôle MODERATOR, donc \nsuppression possible d\'une fiche à modérer.\nPour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \nj\'avais aussi modifié le fichier \"acegi-acl-root.xml\" :\n<property name=\"mask\" value=\"128\"/>\nau lieu de :\n<property name=\"mask\" value=\"48\"/>\n.\nApparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \nl\'affectation de \"permissions\" par défaut à certains rôles \nn\'a pour seul objectif que l\'affichage de ces permissions sur la page \n\"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \nauthentifié. Je ne vois aucun autre impact fonctionnel. \n(voir aussi mon mail du 17/09 : test sur la permission CREATE)\nDans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la même \nmanière, et cela fonctionnait :\n- suppression de la permission DELETE affectée par défaut dans \n\"acegi-acl-root.xml\" ; \n- suppression de la permission DELETE affectée par défaut dans \n\"workflow_easy.xml\" \n(dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n\"deletePermission\" !! \nj\'ai juste modifié la post-focntion \"addPermission\" : \n<arg name=\"bean.name\">addPermission</arg> \n<arg name=\"mask\">132</arg> \n)\nQu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \nAurais-tu une piste ?\nMerci !\nJacques\nFrançois Jannin a écrit : \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour Jacques, \n> \n> Dans la version 1.1, le role moderator part avec le masque de \n> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n> \n> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n> \n<property name=\"mask\" value=\"48\"/>\n> \n<property name=\"recipient\" value=\"4\"/>\n> </bean> \n> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, il \n> faut lui ôter en ajoutant des les post-fonctions : \n> \n> <function type=\"spring\"> \n> <arg name=\"bean.name\">deletePermission</arg> \n> <arg name=\"mask\">16</arg>\n> <arg name=\"recipient\">4</arg>\n> </function> \n> \n> Cordialement, \n> \n> François \n> \n> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour, \n>> \n>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans \n>> le workflow \"easy\" (version v1.1). \n>> \n>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>> Publish\" dans le workflow \"easy\" \n>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>> \n>> \n>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>> \n>> **************************** \n>> <step id=\"1\" name=\"Private\"> \n>> ... \n>> <action id=\"1\" name=\"Ask to Publish\"> \n>> \n<post-functions>\n>> ... \n>> <function type=\"spring\"> \n>> <arg name=\"bean.name\">addPermission</arg>* \n>> * <arg name=\"mask\">128</arg> \n>> \n>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>> \n>> ***************************** \n>> \n>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>> \n>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>> fiches que lui demande de publier l\'auteur. \n>> (case à cocher toujours présente dans la première colonne). \n>> Or, sous la v1.0, la case à cocher n\'était plus visible après cette \n>> modif !! (le modérateur ne pouvait alors plus \"Supprimer\" une fiche \n>> qu\'il avait à examiner) \n>> \n>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>> attendre un certain temps après la modif ?) \n>> \n>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>> MODERATOR ? \n>> \n>> Merci ! \n>> \n>> Jacques \n>> \n>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">> \n></div>\n</blockquote>\n-- \nJacques Brassart \nUNR Nord-Pas de Calais \nUniversité de Valenciennes et du Hainaut-Cambrésis \nTél : 03 27 51 17 70\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:31e87b5fc3d6294650e5d9534d951870' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:890438bb7715d4f366e7d89ae85f0752' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour,\nL\'algorithme de calcul des rôles et permissions a toujours été le même \nau travers des versions.\nEt voici comment cela fonctionne (selon vos retours à tous on peut bien \nsûr envisager de changer ce comportement, mais il me semble que c\'est le \nplus simple à appréhender et que l\'on arrivait ainsi à couvrir \nl\'ensemble des besoins).\n* Les permissions et rôles positionnés dans acegi-acls-root.xml sont \nglobaux à toute l\'application et appliquées ainsi à toutes les fiches, \ncela Indépendamment de toute autre chose. Il n\'est pas possible de \nsupprimer une permission ou un rôle sur une fiche alors que celui-ci a \nété positionné de manière globale dans toute l\'application (via \nacegi-acls-root.xml).\n* Des permissions et rôles locaux supplémentaires peuvent être \npositionnés sur une fiche via le Workflow lui-même. On peut alors \najouter ou supprimer ces permissions.\n=> pour une fiche donnée, les permissions et rôles effectifs sont l\'UNION \n* des permissions et rôles positionnées en local sur celle-ci \n* et des permissions et rôles positionnées en global.\nVincent.\nJacques Brassart wrote: \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour François, \n> \n> Ca ne fonctionne toujours pas ! \n> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n> suppression possible d\'une fiche à modérer. \n> \n> \n> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n> \n<property name=\"mask\" value=\"128\"/>\n> au lieu de : \n> \n<property name=\"mask\" value=\"48\"/>\n. \n> \n> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n> l\'affectation de \"permissions\" par défaut à certains rôles \n> n\'a pour seul objectif que l\'affichage de ces permissions sur la page \n> \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n> authentifié. Je ne vois aucun autre impact fonctionnel. \n> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n> \n> \n> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la même \n> manière, et cela fonctionnait : \n> \n> - suppression de la permission DELETE affectée par défaut dans \n> \"acegi-acl-root.xml\" ; \n> - suppression de la permission DELETE affectée par défaut dans \n> \"workflow_easy.xml\" \n> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n> \"deletePermission\" !! \n> j\'ai juste modifié la post-focntion \"addPermission\" : \n> <arg name=\"bean.name\">addPermission</arg> \n> <arg name=\"mask\">132</arg> \n) \n> \n> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n> Aurais-tu une piste ? \n> \n> Merci ! \n> \n> Jacques \n> \n> \n> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour Jacques, \n>> \n>> Dans la version 1.1, le role moderator part avec le masque de \n>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>> \n>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>> \n<property name=\"mask\" value=\"48\"/>\n>> \n<property name=\"recipient\" value=\"4\"/>\n>> </bean> \n>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, il \n>> faut lui ôter en ajoutant des les post-fonctions : \n>> \n>> <function type=\"spring\"> \n>> <arg name=\"bean.name\">deletePermission</arg> \n>> <arg name=\"mask\">16</arg>\n>> <arg name=\"recipient\">4</arg>\n>> </function> \n>> \n>> Cordialement, \n>> \n>> François \n>> \n>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour, \n>>> \n>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans \n>>> le workflow \"easy\" (version v1.1). \n>>> \n>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>> Publish\" dans le workflow \"easy\" \n>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>> \n>>> \n>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>> \n>>> **************************** \n>>> <step id=\"1\" name=\"Private\"> \n>>> ... \n>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>> \n<post-functions>\n>>> ... \n>>> <function type=\"spring\"> \n>>> <arg name=\"bean.name\">addPermission</arg>* \n>>> * <arg name=\"mask\">128</arg> \n>>> \n>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>> \n>>> ***************************** \n>>> \n>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>> \n>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>> fiches que lui demande de publier l\'auteur. \n>>> (case à cocher toujours présente dans la première colonne). \n>>> Or, sous la v1.0, la case à cocher n\'était plus visible après cette \n>>> modif !! (le modérateur ne pouvait alors plus \"Supprimer\" une fiche \n>>> qu\'il avait à examiner) \n>>> \n>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>> attendre un certain temps après la modif ?) \n>>> \n>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>> MODERATOR ? \n>>> \n>>> Merci ! \n>>> \n>>> Jacques \n>>> \n>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> \n>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:890438bb7715d4f366e7d89ae85f0752' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:16398bba865599ace0e156f258461b1f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Vincent,\nCela ne fonctionne toujours pas.\nJ\'ai refait un test (en respectant l\'algorithme dont tu parles), \net j\'ai configuré ORI-OAI v1.1 comme je l\'avais fait pour la v1.0 (où \ncela fonctionnait !!).\nJ\'ai fait un \"ant all\" puis un \"ant update-acls\" dans \n\"ori-oai-workflow-svn\\\".\nMais rien à faire, les cases à cocher restent toujours visibles.\nJe ne sais plus quoi faire. \nQuelle pourrait-être la source du pb ? \nAs-tu une idée ?\nPour info, je mets en attaché les messages que j\'obtiens quand je \ndéploie avec \"ant all\" et \"ant update-acls\". \nIl y a en effet qqs warnings (deprecation avec le ant all, ehcache avec \nle acls) que je ne sais pas interpréter : \nsont-ils liés à mon pb ?\nMerci,\nJacques\nVincent Bonamy a écrit : \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour, \n> \n> L\'algorithme de calcul des rôles et permissions a toujours été le même \n> au travers des versions. \n> \n> \n> Et voici comment cela fonctionne (selon vos retours à tous on peut \n> bien sûr envisager de changer ce comportement, mais il me semble que \n> c\'est le plus simple à appréhender et que l\'on arrivait ainsi à \n> couvrir l\'ensemble des besoins). \n> \n> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont \n> globaux à toute l\'application et appliquées ainsi à toutes les fiches, \n> cela Indépendamment de toute autre chose. Il n\'est pas possible de \n> supprimer une permission ou un rôle sur une fiche alors que celui-ci a \n> été positionné de manière globale dans toute l\'application (via \n> acegi-acls-root.xml). \n> \n> * Des permissions et rôles locaux supplémentaires peuvent être \n> positionnés sur une fiche via le Workflow lui-même. On peut alors \n> ajouter ou supprimer ces permissions. \n> \n> \n> => pour une fiche donnée, les permissions et rôles effectifs sont l\'UNION \n> * des permissions et rôles positionnées en local sur celle-ci \n> * et des permissions et rôles positionnées en global. \n> \n> \n> Vincent. \n> \n> \n> \n> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour François, \n>> \n>> Ca ne fonctionne toujours pas ! \n>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>> suppression possible d\'une fiche à modérer. \n>> \n>> \n>> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n>> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n>> \n<property name=\"mask\" value=\"128\"/>\n>> au lieu de : \n>> \n<property name=\"mask\" value=\"48\"/>\n. \n>> \n>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>> l\'affectation de \"permissions\" par défaut à certains rôles \n>> n\'a pour seul objectif que l\'affichage de ces permissions sur la page \n>> \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n>> authentifié. Je ne vois aucun autre impact fonctionnel. \n>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>> \n>> \n>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la même \n>> manière, et cela fonctionnait : \n>> \n>> - suppression de la permission DELETE affectée par défaut dans \n>> \"acegi-acl-root.xml\" ; \n>> - suppression de la permission DELETE affectée par défaut dans \n>> \"workflow_easy.xml\" \n>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>> \"deletePermission\" !! \n>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>> <arg name=\"bean.name\">addPermission</arg> \n>> <arg name=\"mask\">132</arg> \n) \n>> \n>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>> Aurais-tu une piste ? \n>> \n>> Merci ! \n>> \n>> Jacques \n>> \n>> \n>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour Jacques, \n>>> \n>>> Dans la version 1.1, le role moderator part avec le masque de \n>>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>>> \n>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>> \n<property name=\"mask\" value=\"48\"/>\n>>> \n<property name=\"recipient\" value=\"4\"/>\n>>> </bean> \n>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, \n>>> il faut lui ôter en ajoutant des les post-fonctions : \n>>> \n>>> <function type=\"spring\"> \n>>> <arg name=\"bean.name\">deletePermission</arg> \n>>> <arg name=\"mask\">16</arg>\n>>> <arg name=\"recipient\">4</arg>\n>>> </function> \n>>> \n>>> Cordialement, \n>>> \n>>> François \n>>> \n>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Bonjour, \n>>>> \n>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>> dans le workflow \"easy\" (version v1.1). \n>>>> \n>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>> Publish\" dans le workflow \"easy\" \n>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>> \n>>>> \n>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>> \n>>>> **************************** \n>>>> <step id=\"1\" name=\"Private\"> \n>>>> ... \n>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>> \n<post-functions>\n>>>> ... \n>>>> <function type=\"spring\"> \n>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>> * <arg name=\"mask\">128</arg> \n>>>> \n>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>> \n>>>> ***************************** \n>>>> \n>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>> \n>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>> fiches que lui demande de publier l\'auteur. \n>>>> (case à cocher toujours présente dans la première colonne). \n>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après cette \n>>>> modif !! (le modérateur ne pouvait alors plus \"Supprimer\" une fiche \n>>>> qu\'il avait à examiner) \n>>>> \n>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>> attendre un certain temps après la modif ?) \n>>>> \n>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>> MODERATOR ? \n>>>> \n>>>> Merci ! \n>>>> \n>>>> Jacques \n>>>> \n>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> \n>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">> \n></div>\n</blockquote>\n-- \nJacques Brassart \nUNR Nord-Pas de Calais \nUniversité de Valenciennes et du Hainaut-Cambrésis \nTél : 03 27 51 17 70\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:16398bba865599ace0e156f258461b1f' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:9fb6757ffb62bc6aed05918c57cea7a5' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Salut Vincent,\nDans Moodle, il existe un moyen de modifier contextuellement les \npermissions attribuées aux rôles, il s\'agit du concept de dérogation. \nDans le workflow, le principe des permissions globales=immuables et \nlocales=modifiables n\'est pas forcément plus simple à appréhender, sauf \nen ceci qu\'une base de permissions est posée globalement tel un roc \ninébranlable, sur laquelle viennent se superposer des permissions en \nfonction de l\'état du workflow. \nLe problème est de distinguer quelles permissions relèvent de la base \nimmuable, et quelles de l\'état. Rien ne permet de distinguer, en l\'état, \nlors de la configuration d\'un workflow, ces permissions \"removables\" des \n\"unremovables\", ce qui amène à l\'échec de la configuration tentée par \nJacques initialement.\nLa solution dans ce cas précis consiste à éroder la base du rôle \nMODERATOR et à remplacer ce qui était immuable (DELETE) par quelque \nchose dépendant de l\'état du workflow. Au fil de l\'eau, tous les rôles \nne risquent-ils pas de semblables érosions ? \nD\'où ma question : peut-être pourrait-on mettre à l\'étude un principe de \ndérogation dans le workflow, afin que ce gain de souplesse empêche \nl\'érosion des rôles ?\nFrançois\nVincent Bonamy a écrit : \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour, \n> \n> L\'algorithme de calcul des rôles et permissions a toujours été le même \n> au travers des versions. \n> \n> \n> Et voici comment cela fonctionne (selon vos retours à tous on peut \n> bien sûr envisager de changer ce comportement, mais il me semble que \n> c\'est le plus simple à appréhender et que l\'on arrivait ainsi à \n> couvrir l\'ensemble des besoins). \n> \n> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont \n> globaux à toute l\'application et appliquées ainsi à toutes les fiches, \n> cela Indépendamment de toute autre chose. Il n\'est pas possible de \n> supprimer une permission ou un rôle sur une fiche alors que celui-ci a \n> été positionné de manière globale dans toute l\'application (via \n> acegi-acls-root.xml). \n> \n> * Des permissions et rôles locaux supplémentaires peuvent être \n> positionnés sur une fiche via le Workflow lui-même. On peut alors \n> ajouter ou supprimer ces permissions. \n> \n> \n> => pour une fiche donnée, les permissions et rôles effectifs sont l\'UNION \n> * des permissions et rôles positionnées en local sur celle-ci \n> * et des permissions et rôles positionnées en global. \n> \n> \n> Vincent. \n> \n> \n> \n> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour François, \n>> \n>> Ca ne fonctionne toujours pas ! \n>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>> suppression possible d\'une fiche à modérer. \n>> \n>> \n>> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n>> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n>> \n<property name=\"mask\" value=\"128\"/>\n>> au lieu de : \n>> \n<property name=\"mask\" value=\"48\"/>\n. \n>> \n>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>> l\'affectation de \"permissions\" par défaut à certains rôles \n>> n\'a pour seul objectif que l\'affichage de ces permissions sur la page \n>> \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n>> authentifié. Je ne vois aucun autre impact fonctionnel. \n>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>> \n>> \n>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la même \n>> manière, et cela fonctionnait : \n>> \n>> - suppression de la permission DELETE affectée par défaut dans \n>> \"acegi-acl-root.xml\" ; \n>> - suppression de la permission DELETE affectée par défaut dans \n>> \"workflow_easy.xml\" \n>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>> \"deletePermission\" !! \n>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>> <arg name=\"bean.name\">addPermission</arg> \n>> <arg name=\"mask\">132</arg> \n) \n>> \n>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>> Aurais-tu une piste ? \n>> \n>> Merci ! \n>> \n>> Jacques \n>> \n>> \n>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour Jacques, \n>>> \n>>> Dans la version 1.1, le role moderator part avec le masque de \n>>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>>> \n>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>> \n<property name=\"mask\" value=\"48\"/>\n>>> \n<property name=\"recipient\" value=\"4\"/>\n>>> </bean> \n>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, \n>>> il faut lui ôter en ajoutant des les post-fonctions : \n>>> \n>>> <function type=\"spring\"> \n>>> <arg name=\"bean.name\">deletePermission</arg> \n>>> <arg name=\"mask\">16</arg>\n>>> <arg name=\"recipient\">4</arg>\n>>> </function> \n>>> \n>>> Cordialement, \n>>> \n>>> François \n>>> \n>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Bonjour, \n>>>> \n>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>> dans le workflow \"easy\" (version v1.1). \n>>>> \n>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>> Publish\" dans le workflow \"easy\" \n>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>> \n>>>> \n>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>> \n>>>> **************************** \n>>>> <step id=\"1\" name=\"Private\"> \n>>>> ... \n>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>> \n<post-functions>\n>>>> ... \n>>>> <function type=\"spring\"> \n>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>> * <arg name=\"mask\">128</arg> \n>>>> \n>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>> \n>>>> ***************************** \n>>>> \n>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>> \n>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>> fiches que lui demande de publier l\'auteur. \n>>>> (case à cocher toujours présente dans la première colonne). \n>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après cette \n>>>> modif !! (le modérateur ne pouvait alors plus \"Supprimer\" une fiche \n>>>> qu\'il avait à examiner) \n>>>> \n>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>> attendre un certain temps après la modif ?) \n>>>> \n>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>> MODERATOR ? \n>>>> \n>>>> Merci ! \n>>>> \n>>>> Jacques \n>>>> \n>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> \n>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:9fb6757ffb62bc6aed05918c57cea7a5' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:8ba2a3c78158d9ee33535542a4142ab1' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Les cases à cocher restent présentes (je pense que c\'est normal) par \ncontre le bouton \"Supprimer\" reste présent également ? \nVincent.\nJacques Brassart wrote: \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Vincent, \n> \n> Cela ne fonctionne toujours pas. \n> \n> J\'ai refait un test (en respectant l\'algorithme dont tu parles), \n> et j\'ai configuré ORI-OAI v1.1 comme je l\'avais fait pour la v1.0 (où \n> cela fonctionnait !!). \n> \n> J\'ai fait un \"ant all\" puis un \"ant update-acls\" dans \n> \"ori-oai-workflow-svn\\\". \n> \n> Mais rien à faire, les cases à cocher restent toujours visibles. \n> \n> Je ne sais plus quoi faire. \n> Quelle pourrait-être la source du pb ? \n> As-tu une idée ? \n> \n> Pour info, je mets en attaché les messages que j\'obtiens quand je \n> déploie avec \"ant all\" et \"ant update-acls\". \n> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache \n> avec le acls) que je ne sais pas interpréter : \n> sont-ils liés à mon pb ? \n> \n> Merci, \n> \n> Jacques \n> \n> \n> \n> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour, \n>> \n>> L\'algorithme de calcul des rôles et permissions a toujours été le \n>> même au travers des versions. \n>> \n>> \n>> Et voici comment cela fonctionne (selon vos retours à tous on peut \n>> bien sûr envisager de changer ce comportement, mais il me semble que \n>> c\'est le plus simple à appréhender et que l\'on arrivait ainsi à \n>> couvrir l\'ensemble des besoins). \n>> \n>> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont \n>> globaux à toute l\'application et appliquées ainsi à toutes les \n>> fiches, cela Indépendamment de toute autre chose. Il n\'est pas \n>> possible de supprimer une permission ou un rôle sur une fiche alors \n>> que celui-ci a été positionné de manière globale dans toute \n>> l\'application (via acegi-acls-root.xml). \n>> \n>> * Des permissions et rôles locaux supplémentaires peuvent être \n>> positionnés sur une fiche via le Workflow lui-même. On peut alors \n>> ajouter ou supprimer ces permissions. \n>> \n>> \n>> => pour une fiche donnée, les permissions et rôles effectifs sont \n>> l\'UNION \n>> * des permissions et rôles positionnées en local sur celle-ci \n>> * et des permissions et rôles positionnées en global. \n>> \n>> \n>> Vincent. \n>> \n>> \n>> \n>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour François, \n>>> \n>>> Ca ne fonctionne toujours pas ! \n>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>>> suppression possible d\'une fiche à modérer. \n>>> \n>>> \n>>> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n>>> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n>>> \n<property name=\"mask\" value=\"128\"/>\n>>> au lieu de : \n>>> \n<property name=\"mask\" value=\"48\"/>\n. \n>>> \n>>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>>> l\'affectation de \"permissions\" par défaut à certains rôles \n>>> n\'a pour seul objectif que l\'affichage de ces permissions sur la \n>>> page \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n>>> authentifié. Je ne vois aucun autre impact fonctionnel. \n>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>>> \n>>> \n>>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la \n>>> même manière, et cela fonctionnait : \n>>> \n>>> - suppression de la permission DELETE affectée par défaut dans \n>>> \"acegi-acl-root.xml\" ; \n>>> - suppression de la permission DELETE affectée par défaut dans \n>>> \"workflow_easy.xml\" \n>>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>>> \"deletePermission\" !! \n>>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>>> <arg name=\"bean.name\">addPermission</arg> \n>>> <arg name=\"mask\">132</arg> \n) \n>>> \n>>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>>> Aurais-tu une piste ? \n>>> \n>>> Merci ! \n>>> \n>>> Jacques \n>>> \n>>> \n>>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Bonjour Jacques, \n>>>> \n>>>> Dans la version 1.1, le role moderator part avec le masque de \n>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>>>> \n>>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>>> \n<property name=\"mask\" value=\"48\"/>\n>>>> \n<property name=\"recipient\" value=\"4\"/>\n>>>> </bean> \n>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, \n>>>> il faut lui ôter en ajoutant des les post-fonctions : \n>>>> \n>>>> <function type=\"spring\"> \n>>>> <arg \n>>>> name=\"bean.name\">deletePermission</arg> \n>>>> <arg name=\"mask\">16</arg>\n>>>> <arg name=\"recipient\">4</arg>\n>>>> </function> \n>>>> \n>>>> Cordialement, \n>>>> \n>>>> François \n>>>> \n>>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> Bonjour, \n>>>>> \n>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>>> dans le workflow \"easy\" (version v1.1). \n>>>>> \n>>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>>> Publish\" dans le workflow \"easy\" \n>>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>>> \n>>>>> \n>>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>>> \n>>>>> **************************** \n>>>>> <step id=\"1\" name=\"Private\"> \n>>>>> ... \n>>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>>> \n<post-functions>\n>>>>> ... \n>>>>> <function type=\"spring\"> \n>>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>>> * <arg name=\"mask\">128</arg> \n>>>>> \n>>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>>> \n>>>>> ***************************** \n>>>>> \n>>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>>> \n>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>>> fiches que lui demande de publier l\'auteur. \n>>>>> (case à cocher toujours présente dans la première colonne). \n>>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après \n>>>>> cette modif !! (le modérateur ne pouvait alors plus \"Supprimer\" \n>>>>> une fiche qu\'il avait à examiner) \n>>>>> \n>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>>> attendre un certain temps après la modif ?) \n>>>>> \n>>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>>> MODERATOR ? \n>>>>> \n>>>>> Merci ! \n>>>>> \n>>>>> Jacques \n>>>>> \n>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> \n>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> \n>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:8ba2a3c78158d9ee33535542a4142ab1' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:fd98440362a9ef73d400563f25fcdc36' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour François, \nOui pourquoi pas : on casse l\'héritage des permissions/rôles à un \nniveau donné. \n[à voir pour une prochaine version si le besoin s\'en fait vraiment sentir ] \nVincent.\nFrançois Jannin wrote: \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Salut Vincent, \n> \n> Dans Moodle, il existe un moyen de modifier contextuellement les \n> permissions attribuées aux rôles, il s\'agit du concept de dérogation. \n> Dans le workflow, le principe des permissions globales=immuables et \n> locales=modifiables n\'est pas forcément plus simple à appréhender, \n> sauf en ceci qu\'une base de permissions est posée globalement tel un \n> roc inébranlable, sur laquelle viennent se superposer des permissions \n> en fonction de l\'état du workflow. \n> Le problème est de distinguer quelles permissions relèvent de la base \n> immuable, et quelles de l\'état. Rien ne permet de distinguer, en \n> l\'état, lors de la configuration d\'un workflow, ces permissions \n> \"removables\" des \"unremovables\", ce qui amène à l\'échec de la \n> configuration tentée par Jacques initialement. \n> \n> La solution dans ce cas précis consiste à éroder la base du rôle \n> MODERATOR et à remplacer ce qui était immuable (DELETE) par quelque \n> chose dépendant de l\'état du workflow. Au fil de l\'eau, tous les rôles \n> ne risquent-ils pas de semblables érosions ? \n> D\'où ma question : peut-être pourrait-on mettre à l\'étude un principe \n> de dérogation dans le workflow, afin que ce gain de souplesse empêche \n> l\'érosion des rôles ? \n> \n> François \n> \n> \n> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour, \n>> \n>> L\'algorithme de calcul des rôles et permissions a toujours été le \n>> même au travers des versions. \n>> \n>> \n>> Et voici comment cela fonctionne (selon vos retours à tous on peut \n>> bien sûr envisager de changer ce comportement, mais il me semble que \n>> c\'est le plus simple à appréhender et que l\'on arrivait ainsi à \n>> couvrir l\'ensemble des besoins). \n>> \n>> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont \n>> globaux à toute l\'application et appliquées ainsi à toutes les \n>> fiches, cela Indépendamment de toute autre chose. Il n\'est pas \n>> possible de supprimer une permission ou un rôle sur une fiche alors \n>> que celui-ci a été positionné de manière globale dans toute \n>> l\'application (via acegi-acls-root.xml). \n>> \n>> * Des permissions et rôles locaux supplémentaires peuvent être \n>> positionnés sur une fiche via le Workflow lui-même. On peut alors \n>> ajouter ou supprimer ces permissions. \n>> \n>> \n>> => pour une fiche donnée, les permissions et rôles effectifs sont \n>> l\'UNION \n>> * des permissions et rôles positionnées en local sur celle-ci \n>> * et des permissions et rôles positionnées en global. \n>> \n>> \n>> Vincent. \n>> \n>> \n>> \n>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour François, \n>>> \n>>> Ca ne fonctionne toujours pas ! \n>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>>> suppression possible d\'une fiche à modérer. \n>>> \n>>> \n>>> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n>>> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n>>> \n<property name=\"mask\" value=\"128\"/>\n>>> au lieu de : \n>>> \n<property name=\"mask\" value=\"48\"/>\n. \n>>> \n>>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>>> l\'affectation de \"permissions\" par défaut à certains rôles \n>>> n\'a pour seul objectif que l\'affichage de ces permissions sur la \n>>> page \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n>>> authentifié. Je ne vois aucun autre impact fonctionnel. \n>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>>> \n>>> \n>>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la \n>>> même manière, et cela fonctionnait : \n>>> \n>>> - suppression de la permission DELETE affectée par défaut dans \n>>> \"acegi-acl-root.xml\" ; \n>>> - suppression de la permission DELETE affectée par défaut dans \n>>> \"workflow_easy.xml\" \n>>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>>> \"deletePermission\" !! \n>>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>>> <arg name=\"bean.name\">addPermission</arg> \n>>> <arg name=\"mask\">132</arg> \n) \n>>> \n>>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>>> Aurais-tu une piste ? \n>>> \n>>> Merci ! \n>>> \n>>> Jacques \n>>> \n>>> \n>>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Bonjour Jacques, \n>>>> \n>>>> Dans la version 1.1, le role moderator part avec le masque de \n>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>>>> \n>>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>>> \n<property name=\"mask\" value=\"48\"/>\n>>>> \n<property name=\"recipient\" value=\"4\"/>\n>>>> </bean> \n>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, \n>>>> il faut lui ôter en ajoutant des les post-fonctions : \n>>>> \n>>>> <function type=\"spring\"> \n>>>> <arg \n>>>> name=\"bean.name\">deletePermission</arg> \n>>>> <arg name=\"mask\">16</arg>\n>>>> <arg name=\"recipient\">4</arg>\n>>>> </function> \n>>>> \n>>>> Cordialement, \n>>>> \n>>>> François \n>>>> \n>>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> Bonjour, \n>>>>> \n>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>>> dans le workflow \"easy\" (version v1.1). \n>>>>> \n>>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>>> Publish\" dans le workflow \"easy\" \n>>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>>> \n>>>>> \n>>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>>> \n>>>>> **************************** \n>>>>> <step id=\"1\" name=\"Private\"> \n>>>>> ... \n>>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>>> \n<post-functions>\n>>>>> ... \n>>>>> <function type=\"spring\"> \n>>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>>> * <arg name=\"mask\">128</arg> \n>>>>> \n>>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>>> \n>>>>> ***************************** \n>>>>> \n>>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>>> \n>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>>> fiches que lui demande de publier l\'auteur. \n>>>>> (case à cocher toujours présente dans la première colonne). \n>>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après \n>>>>> cette modif !! (le modérateur ne pouvait alors plus \"Supprimer\" \n>>>>> une fiche qu\'il avait à examiner) \n>>>>> \n>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>>> attendre un certain temps après la modif ?) \n>>>>> \n>>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>>> MODERATOR ? \n>>>>> \n>>>>> Merci ! \n>>>>> \n>>>>> Jacques \n>>>>> \n>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> \n>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:fd98440362a9ef73d400563f25fcdc36' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:6b2e60ff220f49f6aad704202901b483' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour Vincent,\nOui, le bouton supprimer reste présent !\nVincent, j\'ai peut-être une piste. \nJ\'ai bien l\'impression qu\'il y a AU MOINS une différence entre la v1.0 \net la v1.1, dans l\'IHM du workflow. \nElle se situerait dans l\'affichage des cases à cocher !!\n1) Dans la v1.0 \nLe comportement normal de l\'application est le suivant : \n- bouton supprimer toujours présent, quelques soient les permissions ; \n- si permission DELETE donnée à un rôle, pour un état de la fiche, alors \ncase à cocher présente \n(ex : dossier \"Mes ressources en cours d\'édition\" pour OWNER et état \nPrivé) ; \n- sinon, case à cocher absente (ex : dossier \"Mes ressources en cours de \npublication\" pour OWNER et état En attente de publication).\n2) Dans la v1.1 \nLe comportement normal de l\'application est le suivant : \n- bouton supprimer toujours présent, quelque soit les permissions ; (= \nà la v1.0) \n- case à cocher toujours présente quelques soient les rôles, les \npermissions, les états de la fiche. (DIFFERRENT de la v1.0 !!)\nAutrement dit, dans la v1.1 contrairement à la v1.0, donner ou non la \npermission DELETE à un rôle, ne change rien \nà l\'affichage des cases à cocher. Je pense que le pb se situe à ce niveau. \nPeux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ?\nMerci,\nJacques\nVincent Bonamy a écrit : \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Les cases à cocher restent présentes (je pense que c\'est normal) par \n> contre le bouton \"Supprimer\" reste présent également ? \n> Vincent. \n> \n> \n> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Vincent, \n>> \n>> Cela ne fonctionne toujours pas. \n>> \n>> J\'ai refait un test (en respectant l\'algorithme dont tu parles), \n>> et j\'ai configuré ORI-OAI v1.1 comme je l\'avais fait pour la v1.0 (où \n>> cela fonctionnait !!). \n>> \n>> J\'ai fait un \"ant all\" puis un \"ant update-acls\" dans \n>> \"ori-oai-workflow-svn\\\". \n>> \n>> Mais rien à faire, les cases à cocher restent toujours visibles. \n>> \n>> Je ne sais plus quoi faire. \n>> Quelle pourrait-être la source du pb ? \n>> As-tu une idée ? \n>> \n>> Pour info, je mets en attaché les messages que j\'obtiens quand je \n>> déploie avec \"ant all\" et \"ant update-acls\". \n>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache \n>> avec le acls) que je ne sais pas interpréter : \n>> sont-ils liés à mon pb ? \n>> \n>> Merci, \n>> \n>> Jacques \n>> \n>> \n>> \n>> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour, \n>>> \n>>> L\'algorithme de calcul des rôles et permissions a toujours été le \n>>> même au travers des versions. \n>>> \n>>> \n>>> Et voici comment cela fonctionne (selon vos retours à tous on peut \n>>> bien sûr envisager de changer ce comportement, mais il me semble que \n>>> c\'est le plus simple à appréhender et que l\'on arrivait ainsi à \n>>> couvrir l\'ensemble des besoins). \n>>> \n>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont \n>>> globaux à toute l\'application et appliquées ainsi à toutes les \n>>> fiches, cela Indépendamment de toute autre chose. Il n\'est pas \n>>> possible de supprimer une permission ou un rôle sur une fiche alors \n>>> que celui-ci a été positionné de manière globale dans toute \n>>> l\'application (via acegi-acls-root.xml). \n>>> \n>>> * Des permissions et rôles locaux supplémentaires peuvent être \n>>> positionnés sur une fiche via le Workflow lui-même. On peut alors \n>>> ajouter ou supprimer ces permissions. \n>>> \n>>> \n>>> => pour une fiche donnée, les permissions et rôles effectifs sont \n>>> l\'UNION \n>>> * des permissions et rôles positionnées en local sur celle-ci \n>>> * et des permissions et rôles positionnées en global. \n>>> \n>>> \n>>> Vincent. \n>>> \n>>> \n>>> \n>>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Bonjour François, \n>>>> \n>>>> Ca ne fonctionne toujours pas ! \n>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>>>> suppression possible d\'une fiche à modérer. \n>>>> \n>>>> \n>>>> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n>>>> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n>>>> \n<property name=\"mask\" value=\"128\"/>\n>>>> au lieu de : \n>>>> \n<property name=\"mask\" value=\"48\"/>\n. \n>>>> \n>>>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>>>> l\'affectation de \"permissions\" par défaut à certains rôles \n>>>> n\'a pour seul objectif que l\'affichage de ces permissions sur la \n>>>> page \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n>>>> authentifié. Je ne vois aucun autre impact fonctionnel. \n>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>>>> \n>>>> \n>>>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la \n>>>> même manière, et cela fonctionnait : \n>>>> \n>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>> \"acegi-acl-root.xml\" ; \n>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>> \"workflow_easy.xml\" \n>>>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>>>> \"deletePermission\" !! \n>>>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>>>> <arg name=\"bean.name\">addPermission</arg> \n>>>> <arg name=\"mask\">132</arg> \n) \n>>>> \n>>>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>>>> Aurais-tu une piste ? \n>>>> \n>>>> Merci ! \n>>>> \n>>>> Jacques \n>>>> \n>>>> \n>>>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> Bonjour Jacques, \n>>>>> \n>>>>> Dans la version 1.1, le role moderator part avec le masque de \n>>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>>>>> \n>>>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>>>> \n<property name=\"mask\" value=\"48\"/>\n>>>>> \n<property name=\"recipient\" value=\"4\"/>\n>>>>> </bean> \n>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, \n>>>>> il faut lui ôter en ajoutant des les post-fonctions : \n>>>>> \n>>>>> <function type=\"spring\"> \n>>>>> <arg \n>>>>> name=\"bean.name\">deletePermission</arg> \n>>>>> <arg name=\"mask\">16</arg>\n>>>>> <arg name=\"recipient\">4</arg>\n>>>>> </function> \n>>>>> \n>>>>> Cordialement, \n>>>>> \n>>>>> François \n>>>>> \n>>>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>> Bonjour, \n>>>>>> \n>>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>>>> dans le workflow \"easy\" (version v1.1). \n>>>>>> \n>>>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>>>> Publish\" dans le workflow \"easy\" \n>>>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>>>> \n>>>>>> \n>>>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>>>> \n>>>>>> **************************** \n>>>>>> <step id=\"1\" name=\"Private\"> \n>>>>>> ... \n>>>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>>>> \n<post-functions>\n>>>>>> ... \n>>>>>> <function type=\"spring\"> \n>>>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>>>> * <arg name=\"mask\">128</arg> \n>>>>>> \n>>>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>>>> \n>>>>>> ***************************** \n>>>>>> \n>>>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>>>> \n>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>>>> fiches que lui demande de publier l\'auteur. \n>>>>>> (case à cocher toujours présente dans la première colonne). \n>>>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après \n>>>>>> cette modif !! (le modérateur ne pouvait alors plus \"Supprimer\" \n>>>>>> une fiche qu\'il avait à examiner) \n>>>>>> \n>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>>>> attendre un certain temps après la modif ?) \n>>>>>> \n>>>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>>>> MODERATOR ? \n>>>>>> \n>>>>>> Merci ! \n>>>>>> \n>>>>>> Jacques \n>>>>>> \n>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> \n>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> \n>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">> \n></div>\n</blockquote>\n-- \nJacques Brassart \nUNR Nord-Pas de Calais \nUniversité de Valenciennes et du Hainaut-Cambrésis \nTél : 03 27 51 17 70\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:6b2e60ff220f49f6aad704202901b483' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:b59f695a42efc26014bc8ca465f6ffb1' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour Jacques,\nEffectivement j\'ai regardé, en 1.1 on utilise les cases à cocher non \nplus seulement pour permettre une suppression de masse des fiches mais \négalement pour faire du copier/coller par exemple. \nDonc il n\'est plus possible de cacher la case à cocher pour signifier \nqu\'on ne peut pas supprimer la fiche correspondant à cette case (puisque \nla case peut-être utile aussi pour faire un copier/coller) ...\nLe vrai problème ici est que même si tu n\'as pas les droits tu peux \neffectivement supprimer la fiche : le seul comportement acceptable \ndevrait être similaire à la tentative de suppression de fiches publiées \n(c\'est à dire indexées dans ori-oai-indexing) : on ne signale qu\'après \ncoup que certaines fiches ne peuvent être supprimées car on n\'a pas les \ndroits adéquats pour ce faire.\nSauf si tu as une meilleure idée, je fais la modification dans le code \net te transmets le patch.\nA bientôt, \nVincent.\nJacques Brassart wrote: \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour Vincent, \n> \n> Oui, le bouton supprimer reste présent ! \n> \n> Vincent, j\'ai peut-être une piste. \n> J\'ai bien l\'impression qu\'il y a AU MOINS une différence entre la v1.0 \n> et la v1.1, dans l\'IHM du workflow. \n> Elle se situerait dans l\'affichage des cases à cocher !! \n> \n> 1) Dans la v1.0 \n> Le comportement normal de l\'application est le suivant : \n> - bouton supprimer toujours présent, quelques soient les permissions ; \n> - si permission DELETE donnée à un rôle, pour un état de la fiche, \n> alors case à cocher présente \n> (ex : dossier \"Mes ressources en cours d\'édition\" pour OWNER et état \n> Privé) ; \n> - sinon, case à cocher absente (ex : dossier \"Mes ressources en cours \n> de publication\" pour OWNER et état En attente de publication). \n> \n> 2) Dans la v1.1 \n> Le comportement normal de l\'application est le suivant : \n> - bouton supprimer toujours présent, quelque soit les permissions ; \n> (= à la v1.0) \n> - case à cocher toujours présente quelques soient les rôles, les \n> permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!) \n> \n> Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non la \n> permission DELETE à un rôle, ne change rien \n> à l\'affichage des cases à cocher. Je pense que le pb se situe à ce \n> niveau. \n> Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ? \n> \n> Merci, \n> \n> Jacques \n> \n> \n> \n> \n> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Les cases à cocher restent présentes (je pense que c\'est normal) par \n>> contre le bouton \"Supprimer\" reste présent également ? \n>> Vincent. \n>> \n>> \n>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Vincent, \n>>> \n>>> Cela ne fonctionne toujours pas. \n>>> \n>>> J\'ai refait un test (en respectant l\'algorithme dont tu parles), \n>>> et j\'ai configuré ORI-OAI v1.1 comme je l\'avais fait pour la v1.0 \n>>> (où cela fonctionnait !!). \n>>> \n>>> J\'ai fait un \"ant all\" puis un \"ant update-acls\" dans \n>>> \"ori-oai-workflow-svn\\\". \n>>> \n>>> Mais rien à faire, les cases à cocher restent toujours visibles. \n>>> \n>>> Je ne sais plus quoi faire. \n>>> Quelle pourrait-être la source du pb ? \n>>> As-tu une idée ? \n>>> \n>>> Pour info, je mets en attaché les messages que j\'obtiens quand je \n>>> déploie avec \"ant all\" et \"ant update-acls\". \n>>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache \n>>> avec le acls) que je ne sais pas interpréter : \n>>> sont-ils liés à mon pb ? \n>>> \n>>> Merci, \n>>> \n>>> Jacques \n>>> \n>>> \n>>> \n>>> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Bonjour, \n>>>> \n>>>> L\'algorithme de calcul des rôles et permissions a toujours été le \n>>>> même au travers des versions. \n>>>> \n>>>> \n>>>> Et voici comment cela fonctionne (selon vos retours à tous on peut \n>>>> bien sûr envisager de changer ce comportement, mais il me semble \n>>>> que c\'est le plus simple à appréhender et que l\'on arrivait ainsi à \n>>>> couvrir l\'ensemble des besoins). \n>>>> \n>>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml \n>>>> sont globaux à toute l\'application et appliquées ainsi à toutes les \n>>>> fiches, cela Indépendamment de toute autre chose. Il n\'est pas \n>>>> possible de supprimer une permission ou un rôle sur une fiche alors \n>>>> que celui-ci a été positionné de manière globale dans toute \n>>>> l\'application (via acegi-acls-root.xml). \n>>>> \n>>>> * Des permissions et rôles locaux supplémentaires peuvent être \n>>>> positionnés sur une fiche via le Workflow lui-même. On peut alors \n>>>> ajouter ou supprimer ces permissions. \n>>>> \n>>>> \n>>>> => pour une fiche donnée, les permissions et rôles effectifs sont \n>>>> l\'UNION \n>>>> * des permissions et rôles positionnées en local sur celle-ci \n>>>> * et des permissions et rôles positionnées en global. \n>>>> \n>>>> \n>>>> Vincent. \n>>>> \n>>>> \n>>>> \n>>>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> Bonjour François, \n>>>>> \n>>>>> Ca ne fonctionne toujours pas ! \n>>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>>>>> suppression possible d\'une fiche à modérer. \n>>>>> \n>>>>> \n>>>>> Pour info, hier, avant de modifier le fichier \"workflow_easy.xml\", \n>>>>> j\'avais aussi modifié le fichier \"acegi-acl-root.xml\" : \n>>>>> \n<property name=\"mask\" value=\"128\"/>\n>>>>> au lieu de : \n>>>>> \n<property name=\"mask\" value=\"48\"/>\n. \n>>>>> \n>>>>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>>>>> l\'affectation de \"permissions\" par défaut à certains rôles \n>>>>> n\'a pour seul objectif que l\'affichage de ces permissions sur la \n>>>>> page \"Profil\" de l\'IHM du workflow, pour en informer l\'utilisateur \n>>>>> authentifié. Je ne vois aucun autre impact fonctionnel. \n>>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>>>>> \n>>>>> \n>>>>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la \n>>>>> même manière, et cela fonctionnait : \n>>>>> \n>>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>>> \"acegi-acl-root.xml\" ; \n>>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>>> \"workflow_easy.xml\" \n>>>>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>>>>> \"deletePermission\" !! \n>>>>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>>>>> <arg name=\"bean.name\">addPermission</arg> \n>>>>> <arg name=\"mask\">132</arg> \n) \n>>>>> \n>>>>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>>>>> Aurais-tu une piste ? \n>>>>> \n>>>>> Merci ! \n>>>>> \n>>>>> Jacques \n>>>>> \n>>>>> \n>>>>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>> Bonjour Jacques, \n>>>>>> \n>>>>>> Dans la version 1.1, le role moderator part avec le masque de \n>>>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml : \n>>>>>> \n>>>>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>>>>> \n<property name=\"mask\" value=\"48\"/>\n>>>>>> \n<property name=\"recipient\" value=\"4\"/>\n>>>>>> </bean> \n>>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit \n>>>>>> pas, il faut lui ôter en ajoutant des les post-fonctions : \n>>>>>> \n>>>>>> <function type=\"spring\"> \n>>>>>> <arg \n>>>>>> name=\"bean.name\">deletePermission</arg> \n>>>>>> <arg name=\"mask\">16</arg>\n>>>>>> <arg name=\"recipient\">4</arg>\n>>>>>> </function> \n>>>>>> \n>>>>>> Cordialement, \n>>>>>> \n>>>>>> François \n>>>>>> \n>>>>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_6\">>>>>>>> Bonjour, \n>>>>>>> \n>>>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>>>>> dans le workflow \"easy\" (version v1.1). \n>>>>>>> \n>>>>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>>>>> Publish\" dans le workflow \"easy\" \n>>>>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>>>>> \n>>>>>>> \n>>>>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>>>>> \n>>>>>>> **************************** \n>>>>>>> <step id=\"1\" name=\"Private\"> \n>>>>>>> ... \n>>>>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>>>>> \n<post-functions>\n>>>>>>> ... \n>>>>>>> <function type=\"spring\"> \n>>>>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>>>>> * <arg name=\"mask\">128</arg> \n>>>>>>> \n>>>>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>>>>> \n>>>>>>> ***************************** \n>>>>>>> \n>>>>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>>>>> \n>>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>>>>> fiches que lui demande de publier l\'auteur. \n>>>>>>> (case à cocher toujours présente dans la première colonne). \n>>>>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après \n>>>>>>> cette modif !! (le modérateur ne pouvait alors plus \"Supprimer\" \n>>>>>>> une fiche qu\'il avait à examiner) \n>>>>>>> \n>>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>>>>> attendre un certain temps après la modif ?) \n>>>>>>> \n>>>>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>>>>> MODERATOR ? \n>>>>>>> \n>>>>>>> Merci ! \n>>>>>>> \n>>>>>>> Jacques \n>>>>>>> \n>>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>> \n>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> \n>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> \n>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:b59f695a42efc26014bc8ca465f6ffb1' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:bd819c0537f6dbdcda24945861212299' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Rebonjour Jacques,\nJ\'ai modifié un fichier source.\nCf ici : \n<a href=\"http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src/org/orioai/workflow/services/WorkflowInstanceService.java?root=ori-workflow&r1=831&r2=830&pathrev=831\" title=\"http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src/org/orioai/workflow/services/WorkflowInstanceService.java?root=ori-workflow&r1=831&r2=830&pathrev=831\">http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src...</a>\nTu as 3 possibilités au choix pour répercuter la modif :\n* tu peux réinjecter la modif complètement manuellement\n* tu peux appliquer le patch ci-joint via cette commande : \npatch src/org/orioai/workflow/services/WorkflowInstanceService.java \nWorkflowInstanceService.java.diff\n* et le plus simple et rapide tu peux appliquer directement la \nmodification via subversion (si tu es branché sur subversion) \nsvn merge -r 830:831 \n<a href=\"http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk\" title=\"http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk\">http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk</a> \n[depuis ton répertoire ori-oai-workflow]\nDis moi si cela convient. \n@+ \nVincent.\nVincent Bonamy wrote: \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Bonjour Jacques, \n> \n> Effectivement j\'ai regardé, en 1.1 on utilise les cases à cocher non \n> plus seulement pour permettre une suppression de masse des fiches mais \n> également pour faire du copier/coller par exemple. \n> Donc il n\'est plus possible de cacher la case à cocher pour signifier \n> qu\'on ne peut pas supprimer la fiche correspondant à cette case \n> (puisque la case peut-être utile aussi pour faire un copier/coller) ... \n> \n> Le vrai problème ici est que même si tu n\'as pas les droits tu peux \n> effectivement supprimer la fiche : le seul comportement acceptable \n> devrait être similaire à la tentative de suppression de fiches \n> publiées (c\'est à dire indexées dans ori-oai-indexing) : on ne signale \n> qu\'après coup que certaines fiches ne peuvent être supprimées car on \n> n\'a pas les droits adéquats pour ce faire. \n> \n> Sauf si tu as une meilleure idée, je fais la modification dans le code \n> et te transmets le patch. \n> \n> A bientôt, \n> Vincent. \n> \n> \n> \n> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour Vincent, \n>> \n>> Oui, le bouton supprimer reste présent ! \n>> \n>> Vincent, j\'ai peut-être une piste. \n>> J\'ai bien l\'impression qu\'il y a AU MOINS une différence entre la \n>> v1.0 et la v1.1, dans l\'IHM du workflow. \n>> Elle se situerait dans l\'affichage des cases à cocher !! \n>> \n>> 1) Dans la v1.0 \n>> Le comportement normal de l\'application est le suivant : \n>> - bouton supprimer toujours présent, quelques soient les permissions ; \n>> - si permission DELETE donnée à un rôle, pour un état de la fiche, \n>> alors case à cocher présente \n>> (ex : dossier \"Mes ressources en cours d\'édition\" pour OWNER et état \n>> Privé) ; \n>> - sinon, case à cocher absente (ex : dossier \"Mes ressources en cours \n>> de publication\" pour OWNER et état En attente de publication). \n>> \n>> 2) Dans la v1.1 \n>> Le comportement normal de l\'application est le suivant : \n>> - bouton supprimer toujours présent, quelque soit les permissions ; \n>> (= à la v1.0) \n>> - case à cocher toujours présente quelques soient les rôles, les \n>> permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!) \n>> \n>> Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non la \n>> permission DELETE à un rôle, ne change rien \n>> à l\'affichage des cases à cocher. Je pense que le pb se situe à ce \n>> niveau. \n>> Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ? \n>> \n>> Merci, \n>> \n>> Jacques \n>> \n>> \n>> \n>> \n>> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Les cases à cocher restent présentes (je pense que c\'est normal) par \n>>> contre le bouton \"Supprimer\" reste présent également ? \n>>> Vincent. \n>>> \n>>> \n>>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Vincent, \n>>>> \n>>>> Cela ne fonctionne toujours pas. \n>>>> \n>>>> J\'ai refait un test (en respectant l\'algorithme dont tu parles), \n>>>> et j\'ai configuré ORI-OAI v1.1 comme je l\'avais fait pour la v1.0 \n>>>> (où cela fonctionnait !!). \n>>>> \n>>>> J\'ai fait un \"ant all\" puis un \"ant update-acls\" dans \n>>>> \"ori-oai-workflow-svn\\\". \n>>>> \n>>>> Mais rien à faire, les cases à cocher restent toujours visibles. \n>>>> \n>>>> Je ne sais plus quoi faire. \n>>>> Quelle pourrait-être la source du pb ? \n>>>> As-tu une idée ? \n>>>> \n>>>> Pour info, je mets en attaché les messages que j\'obtiens quand je \n>>>> déploie avec \"ant all\" et \"ant update-acls\". \n>>>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache \n>>>> avec le acls) que je ne sais pas interpréter : \n>>>> sont-ils liés à mon pb ? \n>>>> \n>>>> Merci, \n>>>> \n>>>> Jacques \n>>>> \n>>>> \n>>>> \n>>>> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> Bonjour, \n>>>>> \n>>>>> L\'algorithme de calcul des rôles et permissions a toujours été le \n>>>>> même au travers des versions. \n>>>>> \n>>>>> \n>>>>> Et voici comment cela fonctionne (selon vos retours à tous on peut \n>>>>> bien sûr envisager de changer ce comportement, mais il me semble \n>>>>> que c\'est le plus simple à appréhender et que l\'on arrivait ainsi \n>>>>> à couvrir l\'ensemble des besoins). \n>>>>> \n>>>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml \n>>>>> sont globaux à toute l\'application et appliquées ainsi à toutes \n>>>>> les fiches, cela Indépendamment de toute autre chose. Il n\'est pas \n>>>>> possible de supprimer une permission ou un rôle sur une fiche \n>>>>> alors que celui-ci a été positionné de manière globale dans toute \n>>>>> l\'application (via acegi-acls-root.xml). \n>>>>> \n>>>>> * Des permissions et rôles locaux supplémentaires peuvent être \n>>>>> positionnés sur une fiche via le Workflow lui-même. On peut alors \n>>>>> ajouter ou supprimer ces permissions. \n>>>>> \n>>>>> \n>>>>> => pour une fiche donnée, les permissions et rôles effectifs sont \n>>>>> l\'UNION \n>>>>> * des permissions et rôles positionnées en local sur celle-ci \n>>>>> * et des permissions et rôles positionnées en global. \n>>>>> \n>>>>> \n>>>>> Vincent. \n>>>>> \n>>>>> \n>>>>> \n>>>>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>> Bonjour François, \n>>>>>> \n>>>>>> Ca ne fonctionne toujours pas ! \n>>>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>>>>>> suppression possible d\'une fiche à modérer. \n>>>>>> \n>>>>>> \n>>>>>> Pour info, hier, avant de modifier le fichier \n>>>>>> \"workflow_easy.xml\", j\'avais aussi modifié le fichier \n>>>>>> \"acegi-acl-root.xml\" : \n>>>>>> \n<property name=\"mask\" value=\"128\"/>\n>>>>>> au lieu de : \n>>>>>> \n<property name=\"mask\" value=\"48\"/>\n. \n>>>>>> \n>>>>>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>>>>>> l\'affectation de \"permissions\" par défaut à certains rôles \n>>>>>> n\'a pour seul objectif que l\'affichage de ces permissions sur la \n>>>>>> page \"Profil\" de l\'IHM du workflow, pour en informer \n>>>>>> l\'utilisateur authentifié. Je ne vois aucun autre impact \n>>>>>> fonctionnel. \n>>>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>>>>>> \n>>>>>> \n>>>>>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la \n>>>>>> même manière, et cela fonctionnait : \n>>>>>> \n>>>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>>>> \"acegi-acl-root.xml\" ; \n>>>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>>>> \"workflow_easy.xml\" \n>>>>>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>>>>>> \"deletePermission\" !! \n>>>>>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>>>>>> <arg name=\"bean.name\">addPermission</arg> \n>>>>>> <arg name=\"mask\">132</arg> \n) \n>>>>>> \n>>>>>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>>>>>> Aurais-tu une piste ? \n>>>>>> \n>>>>>> Merci ! \n>>>>>> \n>>>>>> Jacques \n>>>>>> \n>>>>>> \n>>>>>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_6\">>>>>>>> Bonjour Jacques, \n>>>>>>> \n>>>>>>> Dans la version 1.1, le role moderator part avec le masque de \n>>>>>>> permission moderate + delete, comme défini dans \n>>>>>>> acegi-acl-root.xml : \n>>>>>>> \n>>>>>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>>>>>> \n<property name=\"mask\" value=\"48\"/>\n>>>>>>> \n<property name=\"recipient\" value=\"4\"/>\n>>>>>>> </bean> \n>>>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit \n>>>>>>> pas, il faut lui ôter en ajoutant des les post-fonctions : \n>>>>>>> \n>>>>>>> <function type=\"spring\"> \n>>>>>>> <arg \n>>>>>>> name=\"bean.name\">deletePermission</arg> \n>>>>>>> <arg name=\"mask\">16</arg>\n>>>>>>> <arg name=\"recipient\">4</arg>\n>>>>>>> </function> \n>>>>>>> \n>>>>>>> Cordialement, \n>>>>>>> \n>>>>>>> François \n>>>>>>> \n>>>>>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_7\">>>>>>>>> Bonjour, \n>>>>>>>> \n>>>>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR \n>>>>>>>> dans le workflow \"easy\" (version v1.1). \n>>>>>>>> \n>>>>>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask to \n>>>>>>>> Publish\" dans le workflow \"easy\" \n>>>>>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>>>>>> \n>>>>>>>> \n>>>>>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>>>>>> \n>>>>>>>> **************************** \n>>>>>>>> <step id=\"1\" name=\"Private\"> \n>>>>>>>> ... \n>>>>>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>>>>>> \n<post-functions>\n>>>>>>>> ... \n>>>>>>>> <function type=\"spring\"> \n>>>>>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>>>>>> * <arg name=\"mask\">128</arg> \n>>>>>>>> \n>>>>>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>>>>>> \n>>>>>>>> ***************************** \n>>>>>>>> \n>>>>>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>>>>>> \n>>>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les \n>>>>>>>> fiches que lui demande de publier l\'auteur. \n>>>>>>>> (case à cocher toujours présente dans la première colonne). \n>>>>>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après \n>>>>>>>> cette modif !! (le modérateur ne pouvait alors plus \"Supprimer\" \n>>>>>>>> une fiche qu\'il avait à examiner) \n>>>>>>>> \n>>>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je \n>>>>>>>> attendre un certain temps après la modif ?) \n>>>>>>>> \n>>>>>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" pour \n>>>>>>>> MODERATOR ? \n>>>>>>>> \n>>>>>>>> Merci ! \n>>>>>>>> \n>>>>>>>> Jacques \n>>>>>>>> \n>>>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_6\">>>>>>>> \n>>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> \n>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> \n>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">></div>\n</blockquote>\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:bd819c0537f6dbdcda24945861212299' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_filter WHERE cid = '4:b7000a39ef649398adc9d7f0bef26204' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 27.
user warning: Table './drupal_www_ori_oai_org/cache_filter' is marked as crashed and last (automatic?) repair failed query: UPDATE cache_filter SET data = '<div class=\"emailFilter\">Bonjour Vincent,\nJe viens de tester : c\'est parfait comme cela ! \nPourrais-tu juste m\'indiquer dans quel fichier est le texte en français \ndu message d\'erreur, en cas de besoin ?\nMerci beaucoup pour le coup de main !\nJacques\nVincent Bonamy a écrit : \n<div class=\"emailFilter_Toggle\">\n<blockquote class=\"emailFilter_Author_0\">> Rebonjour Jacques, \n> \n> J\'ai modifié un fichier source. \n> \n> Cf ici : \n> <a href=\"http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src/org/orioai/workflow/services/WorkflowInstanceService.java?root=ori-workflow&r1=831&r2=830&pathrev=831\" title=\"http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src/org/orioai/workflow/services/WorkflowInstanceService.java?root=ori-workflow&r1=831&r2=830&pathrev=831\">http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src...</a> \n> \n> \n> Tu as 3 possibilités au choix pour répercuter la modif : \n> \n> * tu peux réinjecter la modif complètement manuellement \n> \n> * tu peux appliquer le patch ci-joint via cette commande : \n> patch src/org/orioai/workflow/services/WorkflowInstanceService.java \n> WorkflowInstanceService.java.diff \n> \n> * et le plus simple et rapide tu peux appliquer directement la \n> modification via subversion (si tu es branché sur subversion) \n> svn merge -r 830:831 \n> <a href=\"http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk\" title=\"http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk\">http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk</a> \n> [depuis ton répertoire ori-oai-workflow] \n> \n> \n> Dis moi si cela convient. \n> @+ \n> Vincent. \n> \n> \n> \n> Vincent Bonamy wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_1\">>> Bonjour Jacques, \n>> \n>> Effectivement j\'ai regardé, en 1.1 on utilise les cases à cocher non \n>> plus seulement pour permettre une suppression de masse des fiches \n>> mais également pour faire du copier/coller par exemple. \n>> Donc il n\'est plus possible de cacher la case à cocher pour signifier \n>> qu\'on ne peut pas supprimer la fiche correspondant à cette case \n>> (puisque la case peut-être utile aussi pour faire un copier/coller) ... \n>> \n>> Le vrai problème ici est que même si tu n\'as pas les droits tu peux \n>> effectivement supprimer la fiche : le seul comportement acceptable \n>> devrait être similaire à la tentative de suppression de fiches \n>> publiées (c\'est à dire indexées dans ori-oai-indexing) : on ne \n>> signale qu\'après coup que certaines fiches ne peuvent être supprimées \n>> car on n\'a pas les droits adéquats pour ce faire. \n>> \n>> Sauf si tu as une meilleure idée, je fais la modification dans le \n>> code et te transmets le patch. \n>> \n>> A bientôt, \n>> Vincent. \n>> \n>> \n>> \n>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>> Bonjour Vincent, \n>>> \n>>> Oui, le bouton supprimer reste présent ! \n>>> \n>>> Vincent, j\'ai peut-être une piste. \n>>> J\'ai bien l\'impression qu\'il y a AU MOINS une différence entre la \n>>> v1.0 et la v1.1, dans l\'IHM du workflow. \n>>> Elle se situerait dans l\'affichage des cases à cocher !! \n>>> \n>>> 1) Dans la v1.0 \n>>> Le comportement normal de l\'application est le suivant : \n>>> - bouton supprimer toujours présent, quelques soient les permissions ; \n>>> - si permission DELETE donnée à un rôle, pour un état de la fiche, \n>>> alors case à cocher présente \n>>> (ex : dossier \"Mes ressources en cours d\'édition\" pour OWNER et état \n>>> Privé) ; \n>>> - sinon, case à cocher absente (ex : dossier \"Mes ressources en \n>>> cours de publication\" pour OWNER et état En attente de publication). \n>>> \n>>> 2) Dans la v1.1 \n>>> Le comportement normal de l\'application est le suivant : \n>>> - bouton supprimer toujours présent, quelque soit les permissions \n>>> ; (= à la v1.0) \n>>> - case à cocher toujours présente quelques soient les rôles, les \n>>> permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!) \n>>> \n>>> Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non \n>>> la permission DELETE à un rôle, ne change rien \n>>> à l\'affichage des cases à cocher. Je pense que le pb se situe à ce \n>>> niveau. \n>>> Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ? \n>>> \n>>> Merci, \n>>> \n>>> Jacques \n>>> \n>>> \n>>> \n>>> \n>>> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> Les cases à cocher restent présentes (je pense que c\'est normal) \n>>>> par contre le bouton \"Supprimer\" reste présent également ? \n>>>> Vincent. \n>>>> \n>>>> \n>>>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>> Vincent, \n>>>>> \n>>>>> Cela ne fonctionne toujours pas. \n>>>>> \n>>>>> J\'ai refait un test (en respectant l\'algorithme dont tu parles), \n>>>>> et j\'ai configuré ORI-OAI v1.1 comme je l\'avais fait pour la v1.0 \n>>>>> (où cela fonctionnait !!). \n>>>>> \n>>>>> J\'ai fait un \"ant all\" puis un \"ant update-acls\" dans \n>>>>> \"ori-oai-workflow-svn\\\". \n>>>>> \n>>>>> Mais rien à faire, les cases à cocher restent toujours visibles. \n>>>>> \n>>>>> Je ne sais plus quoi faire. \n>>>>> Quelle pourrait-être la source du pb ? \n>>>>> As-tu une idée ? \n>>>>> \n>>>>> Pour info, je mets en attaché les messages que j\'obtiens quand je \n>>>>> déploie avec \"ant all\" et \"ant update-acls\". \n>>>>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache \n>>>>> avec le acls) que je ne sais pas interpréter : \n>>>>> sont-ils liés à mon pb ? \n>>>>> \n>>>>> Merci, \n>>>>> \n>>>>> Jacques \n>>>>> \n>>>>> \n>>>>> \n>>>>> Vincent Bonamy a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>> Bonjour, \n>>>>>> \n>>>>>> L\'algorithme de calcul des rôles et permissions a toujours été le \n>>>>>> même au travers des versions. \n>>>>>> \n>>>>>> \n>>>>>> Et voici comment cela fonctionne (selon vos retours à tous on \n>>>>>> peut bien sûr envisager de changer ce comportement, mais il me \n>>>>>> semble que c\'est le plus simple à appréhender et que l\'on \n>>>>>> arrivait ainsi à couvrir l\'ensemble des besoins). \n>>>>>> \n>>>>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml \n>>>>>> sont globaux à toute l\'application et appliquées ainsi à toutes \n>>>>>> les fiches, cela Indépendamment de toute autre chose. Il n\'est \n>>>>>> pas possible de supprimer une permission ou un rôle sur une fiche \n>>>>>> alors que celui-ci a été positionné de manière globale dans toute \n>>>>>> l\'application (via acegi-acls-root.xml). \n>>>>>> \n>>>>>> * Des permissions et rôles locaux supplémentaires peuvent être \n>>>>>> positionnés sur une fiche via le Workflow lui-même. On peut alors \n>>>>>> ajouter ou supprimer ces permissions. \n>>>>>> \n>>>>>> \n>>>>>> => pour une fiche donnée, les permissions et rôles effectifs sont \n>>>>>> l\'UNION \n>>>>>> * des permissions et rôles positionnées en local sur celle-ci \n>>>>>> * et des permissions et rôles positionnées en global. \n>>>>>> \n>>>>>> \n>>>>>> Vincent. \n>>>>>> \n>>>>>> \n>>>>>> \n>>>>>> Jacques Brassart wrote:</blockquote>\n<blockquote class=\"emailFilter_Author_6\">>>>>>>> Bonjour François, \n>>>>>>> \n>>>>>>> Ca ne fonctionne toujours pas ! \n>>>>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc \n>>>>>>> suppression possible d\'une fiche à modérer. \n>>>>>>> \n>>>>>>> \n>>>>>>> Pour info, hier, avant de modifier le fichier \n>>>>>>> \"workflow_easy.xml\", j\'avais aussi modifié le fichier \n>>>>>>> \"acegi-acl-root.xml\" : \n>>>>>>> \n<property name=\"mask\" value=\"128\"/>\n>>>>>>> au lieu de : \n>>>>>>> \n<property name=\"mask\" value=\"48\"/>\n. \n>>>>>>> \n>>>>>>> Apparemment, dans \"acegi-acl-root.xml\", j\'ai l\'impression que \n>>>>>>> l\'affectation de \"permissions\" par défaut à certains rôles \n>>>>>>> n\'a pour seul objectif que l\'affichage de ces permissions sur la \n>>>>>>> page \"Profil\" de l\'IHM du workflow, pour en informer \n>>>>>>> l\'utilisateur authentifié. Je ne vois aucun autre impact \n>>>>>>> fonctionnel. \n>>>>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE) \n>>>>>>> \n>>>>>>> \n>>>>>>> Dans la v1.0, j\'avais touché aux mêmes fichiers, quasiment de la \n>>>>>>> même manière, et cela fonctionnait : \n>>>>>>> \n>>>>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>>>>> \"acegi-acl-root.xml\" ; \n>>>>>>> - suppression de la permission DELETE affectée par défaut dans \n>>>>>>> \"workflow_easy.xml\" \n>>>>>>> (dans ce dernier cas, je n\'ai pas eu à ajouter une post-fonction \n>>>>>>> \"deletePermission\" !! \n>>>>>>> j\'ai juste modifié la post-focntion \"addPermission\" : \n>>>>>>> <arg name=\"bean.name\">addPermission</arg> \n>>>>>>> <arg name=\"mask\">132</arg> \n) \n>>>>>>> \n>>>>>>> Qu\'est-ce qui aurait changé entre la v1.0 et la v1.1 ? \n>>>>>>> Aurais-tu une piste ? \n>>>>>>> \n>>>>>>> Merci ! \n>>>>>>> \n>>>>>>> Jacques \n>>>>>>> \n>>>>>>> \n>>>>>>> François Jannin a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_7\">>>>>>>>> Bonjour Jacques, \n>>>>>>>> \n>>>>>>>> Dans la version 1.1, le role moderator part avec le masque de \n>>>>>>>> permission moderate + delete, comme défini dans \n>>>>>>>> acegi-acl-root.xml : \n>>>>>>>> \n>>>>>>>> <bean class=\"org.orioai.workflow.beans.acls.OriAclPermission\"> \n>>>>>>>> \n<property name=\"mask\" value=\"48\"/>\n>>>>>>>> \n<property name=\"recipient\" value=\"4\"/>\n>>>>>>>> </bean> \n>>>>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit \n>>>>>>>> pas, il faut lui ôter en ajoutant des les post-fonctions : \n>>>>>>>> \n>>>>>>>> <function type=\"spring\"> \n>>>>>>>> <arg \n>>>>>>>> name=\"bean.name\">deletePermission</arg> \n>>>>>>>> <arg name=\"mask\">16</arg>\n>>>>>>>> <arg name=\"recipient\">4</arg>\n>>>>>>>> </function> \n>>>>>>>> \n>>>>>>>> Cordialement, \n>>>>>>>> \n>>>>>>>> François \n>>>>>>>> \n>>>>>>>> Jacques Brassart a écrit :</blockquote>\n<blockquote class=\"emailFilter_Author_8\">>>>>>>>>> Bonjour, \n>>>>>>>>> \n>>>>>>>>> Je souhaite enlever la permission DELETE pour le rôle \n>>>>>>>>> MODERATOR dans le workflow \"easy\" (version v1.1). \n>>>>>>>>> \n>>>>>>>>> Sous la v1.0, j\'avais réussi en modifiant la transition \"Ask \n>>>>>>>>> to Publish\" dans le workflow \"easy\" \n>>>>>>>>> (ori-oai-workflow-svn\\conf\\properties\\spring\\osworkflow\\workflows\\workflow_easy.xml). \n>>>>>>>>> \n>>>>>>>>> \n>>>>>>>>> J\'ai appliqué la même recette pour la v1.1, à savoir : \n>>>>>>>>> \n>>>>>>>>> **************************** \n>>>>>>>>> <step id=\"1\" name=\"Private\"> \n>>>>>>>>> ... \n>>>>>>>>> <action id=\"1\" name=\"Ask to Publish\"> \n>>>>>>>>> \n<post-functions>\n>>>>>>>>> ... \n>>>>>>>>> <function type=\"spring\"> \n>>>>>>>>> <arg name=\"bean.name\">addPermission</arg>* \n>>>>>>>>> * <arg name=\"mask\">128</arg> \n>>>>>>>>> \n>>>>>>>>> (au lieu de : <arg name=\"mask\">148</arg> \n, dans la config d\'origine). \n>>>>>>>>> \n>>>>>>>>> ***************************** \n>>>>>>>>> \n>>>>>>>>> J\'ai fait un \"ant all\", puis un \"ant update-acls\". \n>>>>>>>>> \n>>>>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer \n>>>>>>>>> les fiches que lui demande de publier l\'auteur. \n>>>>>>>>> (case à cocher toujours présente dans la première colonne). \n>>>>>>>>> Or, sous la v1.0, la case à cocher n\'était plus visible après \n>>>>>>>>> cette modif !! (le modérateur ne pouvait alors plus \n>>>>>>>>> \"Supprimer\" une fiche qu\'il avait à examiner) \n>>>>>>>>> \n>>>>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? \n>>>>>>>>> (dois-je attendre un certain temps après la modif ?) \n>>>>>>>>> \n>>>>>>>>> Sinon, comment désactiver cette fonctionnalité \"Supprimer\" \n>>>>>>>>> pour MODERATOR ? \n>>>>>>>>> \n>>>>>>>>> Merci ! \n>>>>>>>>> \n>>>>>>>>> Jacques \n>>>>>>>>> \n>>>>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_7\">>>>>>>>> \n>>>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_6\">>>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_5\">>>>>>> \n>>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_4\">>>>>></blockquote>\n<blockquote class=\"emailFilter_Author_3\">>>>> \n>>>></blockquote>\n<blockquote class=\"emailFilter_Author_2\">>>></blockquote>\n<blockquote class=\"emailFilter_Author_1\">>></blockquote>\n<blockquote class=\"emailFilter_Author_0\">> \n></div>\n</blockquote>\n-- \nJacques Brassart \nUNR Nord-Pas de Calais \nUniversité de Valenciennes et du Hainaut-Cambrésis \nTél : 03 27 51 17 70\n-- \nCe message a été vérifié par MailScanner \npour des virus ou des polluriels et rien de \nsuspect n\'a été trouvé.\n</div>\n', created = 1507746175, expire = 1507832575, headers = '', serialized = 0 WHERE cid = '4:b7000a39ef649398adc9d7f0bef26204' in /home/ori-oai/drupal/drupal-6.34/includes/cache.inc on line 112.

12 messages / 0 nouveaux

Sujet clos

Dernière contribution

18 septembre 2008 - 5:01pm

jbrassar

Workflow : suppression permission DELETE pour rôle MODERATOR

Bonjour,

Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans le
workflow "easy" (version v1.1).

Sous la v1.0, j'avais réussi en modifiant la transition "Ask to Publish"
dans le workflow "easy"
(ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).

J'ai appliqué la même recette pour la v1.1, à savoir :

****************************

...

...

addPermission*
* 128

(au lieu de : 148

, dans la config d'origine).

*****************************

J'ai fait un "ant all", puis un "ant update-acls".

Mais apparemment, le rôle MODERATOR peut toujours supprimer les fiches
que lui demande de publier l'auteur.
(case à cocher toujours présente dans la première colonne).
Or, sous la v1.0, la case à cocher n'était plus visible après cette
modif !! (le modérateur ne pouvait alors plus "Supprimer" une fiche
qu'il avait à examiner)

Y aurait-t-il un pb de cache avec le module workflow ? (dois-je attendre
un certain temps après la modif ?)

Sinon, comment désactiver cette fonctionnalité "Supprimer" pour MODERATOR ?

Merci !

Jacques

--
Jacques Brassart
UNR Nord-Pas de Calais
Université de Valenciennes et du Hainaut-Cambrésis
Tél : 03 27 51 17 70

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

18 septembre 2008 - 5:26pm

francoisjannin

Bonjour Jacques,

Dans la version 1.1, le role moderator part avec le masque de permission
moderate + delete, comme défini dans acegi-acl-root.xml :

Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, il
faut lui ôter en ajoutant des les post-fonctions :

deletePermission
16

Cordialement,

François

Jacques Brassart a écrit :

> Bonjour,
>
> Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans
> le workflow "easy" (version v1.1).
>
> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
> Publish" dans le workflow "easy"
> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>
>
> J'ai appliqué la même recette pour la v1.1, à savoir :
>
> ****************************
>
> ...
>
>
> ...
>
> addPermission*
> * 128

>
> (au lieu de : 148

, dans la config d'origine).
>
> *****************************
>
> J'ai fait un "ant all", puis un "ant update-acls".
>
> Mais apparemment, le rôle MODERATOR peut toujours supprimer les fiches
> que lui demande de publier l'auteur.
> (case à cocher toujours présente dans la première colonne).
> Or, sous la v1.0, la case à cocher n'était plus visible après cette
> modif !! (le modérateur ne pouvait alors plus "Supprimer" une fiche
> qu'il avait à examiner)
>
> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
> attendre un certain temps après la modif ?)
>
> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
> MODERATOR ?
>
> Merci !
>
> Jacques
>
>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

19 septembre 2008 - 11:12am

(Répondre à #2) #3

jbrassar

Bonjour François,

Ca ne fonctionne toujours pas !
La case à cocher apparaît toujours pour le rôle MODERATOR, donc
suppression possible d'une fiche à modérer.

Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
j'avais aussi modifié le fichier "acegi-acl-root.xml" :

au lieu de :

Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
l'affectation de "permissions" par défaut à certains rôles
n'a pour seul objectif que l'affichage de ces permissions sur la page
"Profil" de l'IHM du workflow, pour en informer l'utilisateur
authentifié. Je ne vois aucun autre impact fonctionnel.
(voir aussi mon mail du 17/09 : test sur la permission CREATE)

Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la même
manière, et cela fonctionnait :

- suppression de la permission DELETE affectée par défaut dans
"acegi-acl-root.xml" ;
- suppression de la permission DELETE affectée par défaut dans
"workflow_easy.xml"
(dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
"deletePermission" !!
j'ai juste modifié la post-focntion "addPermission" :
addPermission
132

)

Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
Aurais-tu une piste ?

Merci !

Jacques

François Jannin a écrit :

> Bonjour Jacques,
>
> Dans la version 1.1, le role moderator part avec le masque de
> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>
>
>

>

>
> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, il
> faut lui ôter en ajoutant des les post-fonctions :
>
>
> deletePermission
> 16

> 4

>
>
> Cordialement,
>
> François
>
> Jacques Brassart a écrit :

>> Bonjour,
>>
>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans
>> le workflow "easy" (version v1.1).
>>
>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>> Publish" dans le workflow "easy"
>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>
>>
>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>
>> ****************************
>>
>> ...
>>
>>
>> ...
>>
>> addPermission*
>> * 128

>>
>> (au lieu de : 148

, dans la config d'origine).
>>
>> *****************************
>>
>> J'ai fait un "ant all", puis un "ant update-acls".
>>
>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>> fiches que lui demande de publier l'auteur.
>> (case à cocher toujours présente dans la première colonne).
>> Or, sous la v1.0, la case à cocher n'était plus visible après cette
>> modif !! (le modérateur ne pouvait alors plus "Supprimer" une fiche
>> qu'il avait à examiner)
>>
>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>> attendre un certain temps après la modif ?)
>>
>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>> MODERATOR ?
>>
>> Merci !
>>
>> Jacques
>>
>>

>
>

--
Jacques Brassart
UNR Nord-Pas de Calais
Université de Valenciennes et du Hainaut-Cambrésis
Tél : 03 27 51 17 70

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

22 septembre 2008 - 9:13am

(Répondre à #3) #4

vincentbonamy

Bonjour,

L'algorithme de calcul des rôles et permissions a toujours été le même
au travers des versions.

Et voici comment cela fonctionne (selon vos retours à tous on peut bien
sûr envisager de changer ce comportement, mais il me semble que c'est le
plus simple à appréhender et que l'on arrivait ainsi à couvrir
l'ensemble des besoins).

* Les permissions et rôles positionnés dans acegi-acls-root.xml sont
globaux à toute l'application et appliquées ainsi à toutes les fiches,
cela Indépendamment de toute autre chose. Il n'est pas possible de
supprimer une permission ou un rôle sur une fiche alors que celui-ci a
été positionné de manière globale dans toute l'application (via
acegi-acls-root.xml).

* Des permissions et rôles locaux supplémentaires peuvent être
positionnés sur une fiche via le Workflow lui-même. On peut alors
ajouter ou supprimer ces permissions.

=> pour une fiche donnée, les permissions et rôles effectifs sont l'UNION
* des permissions et rôles positionnées en local sur celle-ci
* et des permissions et rôles positionnées en global.

Vincent.

Jacques Brassart wrote:

> Bonjour François,
>
> Ca ne fonctionne toujours pas !
> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
> suppression possible d'une fiche à modérer.
>
>
> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>

> au lieu de :
>

.
>
> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
> l'affectation de "permissions" par défaut à certains rôles
> n'a pour seul objectif que l'affichage de ces permissions sur la page
> "Profil" de l'IHM du workflow, pour en informer l'utilisateur
> authentifié. Je ne vois aucun autre impact fonctionnel.
> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>
>
> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la même
> manière, et cela fonctionnait :
>
> - suppression de la permission DELETE affectée par défaut dans
> "acegi-acl-root.xml" ;
> - suppression de la permission DELETE affectée par défaut dans
> "workflow_easy.xml"
> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
> "deletePermission" !!
> j'ai juste modifié la post-focntion "addPermission" :
> addPermission
> 132

)
>
> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
> Aurais-tu une piste ?
>
> Merci !
>
> Jacques
>
>
> François Jannin a écrit :

>> Bonjour Jacques,
>>
>> Dans la version 1.1, le role moderator part avec le masque de
>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>
>>
>>

>>

>>
>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas, il
>> faut lui ôter en ajoutant des les post-fonctions :
>>
>>
>> deletePermission
>> 16

>> 4

>>
>>
>> Cordialement,
>>
>> François
>>
>> Jacques Brassart a écrit :

>>> Bonjour,
>>>
>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR dans
>>> le workflow "easy" (version v1.1).
>>>
>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>> Publish" dans le workflow "easy"
>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>
>>>
>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>
>>> ****************************
>>>
>>> ...
>>>
>>>
>>> ...
>>>
>>> addPermission*
>>> * 128

>>>
>>> (au lieu de : 148

, dans la config d'origine).
>>>
>>> *****************************
>>>
>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>
>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>> fiches que lui demande de publier l'auteur.
>>> (case à cocher toujours présente dans la première colonne).
>>> Or, sous la v1.0, la case à cocher n'était plus visible après cette
>>> modif !! (le modérateur ne pouvait alors plus "Supprimer" une fiche
>>> qu'il avait à examiner)
>>>
>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>> attendre un certain temps après la modif ?)
>>>
>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>> MODERATOR ?
>>>
>>> Merci !
>>>
>>> Jacques
>>>
>>>

>>
>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

24 septembre 2008 - 4:28pm

(Répondre à #4) #5

jbrassar

Vincent,

Cela ne fonctionne toujours pas.

J'ai refait un test (en respectant l'algorithme dont tu parles),
et j'ai configuré ORI-OAI v1.1 comme je l'avais fait pour la v1.0 (où
cela fonctionnait !!).

J'ai fait un "ant all" puis un "ant update-acls" dans
"ori-oai-workflow-svn\".

Mais rien à faire, les cases à cocher restent toujours visibles.

Je ne sais plus quoi faire.
Quelle pourrait-être la source du pb ?
As-tu une idée ?

Pour info, je mets en attaché les messages que j'obtiens quand je
déploie avec "ant all" et "ant update-acls".
Il y a en effet qqs warnings (deprecation avec le ant all, ehcache avec
le acls) que je ne sais pas interpréter :
sont-ils liés à mon pb ?

Merci,

Jacques

Vincent Bonamy a écrit :

> Bonjour,
>
> L'algorithme de calcul des rôles et permissions a toujours été le même
> au travers des versions.
>
>
> Et voici comment cela fonctionne (selon vos retours à tous on peut
> bien sûr envisager de changer ce comportement, mais il me semble que
> c'est le plus simple à appréhender et que l'on arrivait ainsi à
> couvrir l'ensemble des besoins).
>
> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont
> globaux à toute l'application et appliquées ainsi à toutes les fiches,
> cela Indépendamment de toute autre chose. Il n'est pas possible de
> supprimer une permission ou un rôle sur une fiche alors que celui-ci a
> été positionné de manière globale dans toute l'application (via
> acegi-acls-root.xml).
>
> * Des permissions et rôles locaux supplémentaires peuvent être
> positionnés sur une fiche via le Workflow lui-même. On peut alors
> ajouter ou supprimer ces permissions.
>
>
> => pour une fiche donnée, les permissions et rôles effectifs sont l'UNION
> * des permissions et rôles positionnées en local sur celle-ci
> * et des permissions et rôles positionnées en global.
>
>
> Vincent.
>
>
>
> Jacques Brassart wrote:

>> Bonjour François,
>>
>> Ca ne fonctionne toujours pas !
>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>> suppression possible d'une fiche à modérer.
>>
>>
>> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
>> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>>

>> au lieu de :
>>

.
>>
>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>> l'affectation de "permissions" par défaut à certains rôles
>> n'a pour seul objectif que l'affichage de ces permissions sur la page
>> "Profil" de l'IHM du workflow, pour en informer l'utilisateur
>> authentifié. Je ne vois aucun autre impact fonctionnel.
>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>
>>
>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la même
>> manière, et cela fonctionnait :
>>
>> - suppression de la permission DELETE affectée par défaut dans
>> "acegi-acl-root.xml" ;
>> - suppression de la permission DELETE affectée par défaut dans
>> "workflow_easy.xml"
>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>> "deletePermission" !!
>> j'ai juste modifié la post-focntion "addPermission" :
>> addPermission
>> 132

)
>>
>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>> Aurais-tu une piste ?
>>
>> Merci !
>>
>> Jacques
>>
>>
>> François Jannin a écrit :

>>> Bonjour Jacques,
>>>
>>> Dans la version 1.1, le role moderator part avec le masque de
>>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>>
>>>
>>>

>>>

>>>
>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas,
>>> il faut lui ôter en ajoutant des les post-fonctions :
>>>
>>>
>>> deletePermission
>>> 16

>>> 4

>>>
>>>
>>> Cordialement,
>>>
>>> François
>>>
>>> Jacques Brassart a écrit :

>>>> Bonjour,
>>>>
>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>> dans le workflow "easy" (version v1.1).
>>>>
>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>> Publish" dans le workflow "easy"
>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>
>>>>
>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>
>>>> ****************************
>>>>
>>>> ...
>>>>
>>>>
>>>> ...
>>>>
>>>> addPermission*
>>>> * 128

>>>>
>>>> (au lieu de : 148

, dans la config d'origine).
>>>>
>>>> *****************************
>>>>
>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>
>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>> fiches que lui demande de publier l'auteur.
>>>> (case à cocher toujours présente dans la première colonne).
>>>> Or, sous la v1.0, la case à cocher n'était plus visible après cette
>>>> modif !! (le modérateur ne pouvait alors plus "Supprimer" une fiche
>>>> qu'il avait à examiner)
>>>>
>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>> attendre un certain temps après la modif ?)
>>>>
>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>> MODERATOR ?
>>>>
>>>> Merci !
>>>>
>>>> Jacques
>>>>
>>>>

>>>
>>>

>>

>
>

--
Jacques Brassart
UNR Nord-Pas de Calais
Université de Valenciennes et du Hainaut-Cambrésis
Tél : 03 27 51 17 70

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

24 septembre 2008 - 2:51pm

(Répondre à #4) #6

francoisjannin

Salut Vincent,

Dans Moodle, il existe un moyen de modifier contextuellement les
permissions attribuées aux rôles, il s'agit du concept de dérogation.
Dans le workflow, le principe des permissions globales=immuables et
locales=modifiables n'est pas forcément plus simple à appréhender, sauf
en ceci qu'une base de permissions est posée globalement tel un roc
inébranlable, sur laquelle viennent se superposer des permissions en
fonction de l'état du workflow.
Le problème est de distinguer quelles permissions relèvent de la base
immuable, et quelles de l'état. Rien ne permet de distinguer, en l'état,
lors de la configuration d'un workflow, ces permissions "removables" des
"unremovables", ce qui amène à l'échec de la configuration tentée par
Jacques initialement.

La solution dans ce cas précis consiste à éroder la base du rôle
MODERATOR et à remplacer ce qui était immuable (DELETE) par quelque
chose dépendant de l'état du workflow. Au fil de l'eau, tous les rôles
ne risquent-ils pas de semblables érosions ?
D'où ma question : peut-être pourrait-on mettre à l'étude un principe de
dérogation dans le workflow, afin que ce gain de souplesse empêche
l'érosion des rôles ?

François

Vincent Bonamy a écrit :

> Bonjour,
>
> L'algorithme de calcul des rôles et permissions a toujours été le même
> au travers des versions.
>
>
> Et voici comment cela fonctionne (selon vos retours à tous on peut
> bien sûr envisager de changer ce comportement, mais il me semble que
> c'est le plus simple à appréhender et que l'on arrivait ainsi à
> couvrir l'ensemble des besoins).
>
> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont
> globaux à toute l'application et appliquées ainsi à toutes les fiches,
> cela Indépendamment de toute autre chose. Il n'est pas possible de
> supprimer une permission ou un rôle sur une fiche alors que celui-ci a
> été positionné de manière globale dans toute l'application (via
> acegi-acls-root.xml).
>
> * Des permissions et rôles locaux supplémentaires peuvent être
> positionnés sur une fiche via le Workflow lui-même. On peut alors
> ajouter ou supprimer ces permissions.
>
>
> => pour une fiche donnée, les permissions et rôles effectifs sont l'UNION
> * des permissions et rôles positionnées en local sur celle-ci
> * et des permissions et rôles positionnées en global.
>
>
> Vincent.
>
>
>
> Jacques Brassart wrote:

>> Bonjour François,
>>
>> Ca ne fonctionne toujours pas !
>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>> suppression possible d'une fiche à modérer.
>>
>>
>> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
>> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>>

>> au lieu de :
>>

.
>>
>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>> l'affectation de "permissions" par défaut à certains rôles
>> n'a pour seul objectif que l'affichage de ces permissions sur la page
>> "Profil" de l'IHM du workflow, pour en informer l'utilisateur
>> authentifié. Je ne vois aucun autre impact fonctionnel.
>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>
>>
>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la même
>> manière, et cela fonctionnait :
>>
>> - suppression de la permission DELETE affectée par défaut dans
>> "acegi-acl-root.xml" ;
>> - suppression de la permission DELETE affectée par défaut dans
>> "workflow_easy.xml"
>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>> "deletePermission" !!
>> j'ai juste modifié la post-focntion "addPermission" :
>> addPermission
>> 132

)
>>
>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>> Aurais-tu une piste ?
>>
>> Merci !
>>
>> Jacques
>>
>>
>> François Jannin a écrit :

>>> Bonjour Jacques,
>>>
>>> Dans la version 1.1, le role moderator part avec le masque de
>>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>>
>>>
>>>

>>>

>>>
>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas,
>>> il faut lui ôter en ajoutant des les post-fonctions :
>>>
>>>
>>> deletePermission
>>> 16

>>> 4

>>>
>>>
>>> Cordialement,
>>>
>>> François
>>>
>>> Jacques Brassart a écrit :

>>>> Bonjour,
>>>>
>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>> dans le workflow "easy" (version v1.1).
>>>>
>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>> Publish" dans le workflow "easy"
>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>
>>>>
>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>
>>>> ****************************
>>>>
>>>> ...
>>>>
>>>>
>>>> ...
>>>>
>>>> addPermission*
>>>> * 128

>>>>
>>>> (au lieu de : 148

, dans la config d'origine).
>>>>
>>>> *****************************
>>>>
>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>
>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>> fiches que lui demande de publier l'auteur.
>>>> (case à cocher toujours présente dans la première colonne).
>>>> Or, sous la v1.0, la case à cocher n'était plus visible après cette
>>>> modif !! (le modérateur ne pouvait alors plus "Supprimer" une fiche
>>>> qu'il avait à examiner)
>>>>
>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>> attendre un certain temps après la modif ?)
>>>>
>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>> MODERATOR ?
>>>>
>>>> Merci !
>>>>
>>>> Jacques
>>>>
>>>>

>>>
>>>

>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

24 septembre 2008 - 6:20pm

(Répondre à #5) #7

vincentbonamy

Les cases à cocher restent présentes (je pense que c'est normal) par
contre le bouton "Supprimer" reste présent également ?
Vincent.

Jacques Brassart wrote:

> Vincent,
>
> Cela ne fonctionne toujours pas.
>
> J'ai refait un test (en respectant l'algorithme dont tu parles),
> et j'ai configuré ORI-OAI v1.1 comme je l'avais fait pour la v1.0 (où
> cela fonctionnait !!).
>
> J'ai fait un "ant all" puis un "ant update-acls" dans
> "ori-oai-workflow-svn\".
>
> Mais rien à faire, les cases à cocher restent toujours visibles.
>
> Je ne sais plus quoi faire.
> Quelle pourrait-être la source du pb ?
> As-tu une idée ?
>
> Pour info, je mets en attaché les messages que j'obtiens quand je
> déploie avec "ant all" et "ant update-acls".
> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache
> avec le acls) que je ne sais pas interpréter :
> sont-ils liés à mon pb ?
>
> Merci,
>
> Jacques
>
>
>
> Vincent Bonamy a écrit :

>> Bonjour,
>>
>> L'algorithme de calcul des rôles et permissions a toujours été le
>> même au travers des versions.
>>
>>
>> Et voici comment cela fonctionne (selon vos retours à tous on peut
>> bien sûr envisager de changer ce comportement, mais il me semble que
>> c'est le plus simple à appréhender et que l'on arrivait ainsi à
>> couvrir l'ensemble des besoins).
>>
>> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont
>> globaux à toute l'application et appliquées ainsi à toutes les
>> fiches, cela Indépendamment de toute autre chose. Il n'est pas
>> possible de supprimer une permission ou un rôle sur une fiche alors
>> que celui-ci a été positionné de manière globale dans toute
>> l'application (via acegi-acls-root.xml).
>>
>> * Des permissions et rôles locaux supplémentaires peuvent être
>> positionnés sur une fiche via le Workflow lui-même. On peut alors
>> ajouter ou supprimer ces permissions.
>>
>>
>> => pour une fiche donnée, les permissions et rôles effectifs sont
>> l'UNION
>> * des permissions et rôles positionnées en local sur celle-ci
>> * et des permissions et rôles positionnées en global.
>>
>>
>> Vincent.
>>
>>
>>
>> Jacques Brassart wrote:

>>> Bonjour François,
>>>
>>> Ca ne fonctionne toujours pas !
>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>>> suppression possible d'une fiche à modérer.
>>>
>>>
>>> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
>>> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>>>

>>> au lieu de :
>>>

.
>>>
>>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>>> l'affectation de "permissions" par défaut à certains rôles
>>> n'a pour seul objectif que l'affichage de ces permissions sur la
>>> page "Profil" de l'IHM du workflow, pour en informer l'utilisateur
>>> authentifié. Je ne vois aucun autre impact fonctionnel.
>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>>
>>>
>>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la
>>> même manière, et cela fonctionnait :
>>>
>>> - suppression de la permission DELETE affectée par défaut dans
>>> "acegi-acl-root.xml" ;
>>> - suppression de la permission DELETE affectée par défaut dans
>>> "workflow_easy.xml"
>>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>>> "deletePermission" !!
>>> j'ai juste modifié la post-focntion "addPermission" :
>>> addPermission
>>> 132

)
>>>
>>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>>> Aurais-tu une piste ?
>>>
>>> Merci !
>>>
>>> Jacques
>>>
>>>
>>> François Jannin a écrit :

>>>> Bonjour Jacques,
>>>>
>>>> Dans la version 1.1, le role moderator part avec le masque de
>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>>>
>>>>
>>>>

>>>>

>>>>
>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas,
>>>> il faut lui ôter en ajoutant des les post-fonctions :
>>>>
>>>>
>>>> >>>> name="bean.name">deletePermission
>>>> 16

>>>> 4

>>>>
>>>>
>>>> Cordialement,
>>>>
>>>> François
>>>>
>>>> Jacques Brassart a écrit :

>>>>> Bonjour,
>>>>>
>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>>> dans le workflow "easy" (version v1.1).
>>>>>
>>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>>> Publish" dans le workflow "easy"
>>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>>
>>>>>
>>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>>
>>>>> ****************************
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> addPermission*
>>>>> * 128

>>>>>
>>>>> (au lieu de : 148

, dans la config d'origine).
>>>>>
>>>>> *****************************
>>>>>
>>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>>
>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>>> fiches que lui demande de publier l'auteur.
>>>>> (case à cocher toujours présente dans la première colonne).
>>>>> Or, sous la v1.0, la case à cocher n'était plus visible après
>>>>> cette modif !! (le modérateur ne pouvait alors plus "Supprimer"
>>>>> une fiche qu'il avait à examiner)
>>>>>
>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>>> attendre un certain temps après la modif ?)
>>>>>
>>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>>> MODERATOR ?
>>>>>
>>>>> Merci !
>>>>>
>>>>> Jacques
>>>>>
>>>>>

>>>>
>>>>

>>>

>>
>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

24 septembre 2008 - 6:26pm

(Répondre à #6) #8

vincentbonamy

Bonjour François,
Oui pourquoi pas : on casse l'héritage des permissions/rôles à un
niveau donné.
[à voir pour une prochaine version si le besoin s'en fait vraiment sentir ]
Vincent.

François Jannin wrote:

> Salut Vincent,
>
> Dans Moodle, il existe un moyen de modifier contextuellement les
> permissions attribuées aux rôles, il s'agit du concept de dérogation.
> Dans le workflow, le principe des permissions globales=immuables et
> locales=modifiables n'est pas forcément plus simple à appréhender,
> sauf en ceci qu'une base de permissions est posée globalement tel un
> roc inébranlable, sur laquelle viennent se superposer des permissions
> en fonction de l'état du workflow.
> Le problème est de distinguer quelles permissions relèvent de la base
> immuable, et quelles de l'état. Rien ne permet de distinguer, en
> l'état, lors de la configuration d'un workflow, ces permissions
> "removables" des "unremovables", ce qui amène à l'échec de la
> configuration tentée par Jacques initialement.
>
> La solution dans ce cas précis consiste à éroder la base du rôle
> MODERATOR et à remplacer ce qui était immuable (DELETE) par quelque
> chose dépendant de l'état du workflow. Au fil de l'eau, tous les rôles
> ne risquent-ils pas de semblables érosions ?
> D'où ma question : peut-être pourrait-on mettre à l'étude un principe
> de dérogation dans le workflow, afin que ce gain de souplesse empêche
> l'érosion des rôles ?
>
> François
>
>
> Vincent Bonamy a écrit :

>> Bonjour,
>>
>> L'algorithme de calcul des rôles et permissions a toujours été le
>> même au travers des versions.
>>
>>
>> Et voici comment cela fonctionne (selon vos retours à tous on peut
>> bien sûr envisager de changer ce comportement, mais il me semble que
>> c'est le plus simple à appréhender et que l'on arrivait ainsi à
>> couvrir l'ensemble des besoins).
>>
>> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont
>> globaux à toute l'application et appliquées ainsi à toutes les
>> fiches, cela Indépendamment de toute autre chose. Il n'est pas
>> possible de supprimer une permission ou un rôle sur une fiche alors
>> que celui-ci a été positionné de manière globale dans toute
>> l'application (via acegi-acls-root.xml).
>>
>> * Des permissions et rôles locaux supplémentaires peuvent être
>> positionnés sur une fiche via le Workflow lui-même. On peut alors
>> ajouter ou supprimer ces permissions.
>>
>>
>> => pour une fiche donnée, les permissions et rôles effectifs sont
>> l'UNION
>> * des permissions et rôles positionnées en local sur celle-ci
>> * et des permissions et rôles positionnées en global.
>>
>>
>> Vincent.
>>
>>
>>
>> Jacques Brassart wrote:

>>> Bonjour François,
>>>
>>> Ca ne fonctionne toujours pas !
>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>>> suppression possible d'une fiche à modérer.
>>>
>>>
>>> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
>>> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>>>

>>> au lieu de :
>>>

.
>>>
>>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>>> l'affectation de "permissions" par défaut à certains rôles
>>> n'a pour seul objectif que l'affichage de ces permissions sur la
>>> page "Profil" de l'IHM du workflow, pour en informer l'utilisateur
>>> authentifié. Je ne vois aucun autre impact fonctionnel.
>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>>
>>>
>>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la
>>> même manière, et cela fonctionnait :
>>>
>>> - suppression de la permission DELETE affectée par défaut dans
>>> "acegi-acl-root.xml" ;
>>> - suppression de la permission DELETE affectée par défaut dans
>>> "workflow_easy.xml"
>>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>>> "deletePermission" !!
>>> j'ai juste modifié la post-focntion "addPermission" :
>>> addPermission
>>> 132

)
>>>
>>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>>> Aurais-tu une piste ?
>>>
>>> Merci !
>>>
>>> Jacques
>>>
>>>
>>> François Jannin a écrit :

>>>> Bonjour Jacques,
>>>>
>>>> Dans la version 1.1, le role moderator part avec le masque de
>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>>>
>>>>
>>>>

>>>>

>>>>
>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas,
>>>> il faut lui ôter en ajoutant des les post-fonctions :
>>>>
>>>>
>>>> >>>> name="bean.name">deletePermission
>>>> 16

>>>> 4

>>>>
>>>>
>>>> Cordialement,
>>>>
>>>> François
>>>>
>>>> Jacques Brassart a écrit :

>>>>> Bonjour,
>>>>>
>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>>> dans le workflow "easy" (version v1.1).
>>>>>
>>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>>> Publish" dans le workflow "easy"
>>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>>
>>>>>
>>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>>
>>>>> ****************************
>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>> ...
>>>>>
>>>>> addPermission*
>>>>> * 128

>>>>>
>>>>> (au lieu de : 148

, dans la config d'origine).
>>>>>
>>>>> *****************************
>>>>>
>>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>>
>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>>> fiches que lui demande de publier l'auteur.
>>>>> (case à cocher toujours présente dans la première colonne).
>>>>> Or, sous la v1.0, la case à cocher n'était plus visible après
>>>>> cette modif !! (le modérateur ne pouvait alors plus "Supprimer"
>>>>> une fiche qu'il avait à examiner)
>>>>>
>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>>> attendre un certain temps après la modif ?)
>>>>>
>>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>>> MODERATOR ?
>>>>>
>>>>> Merci !
>>>>>
>>>>> Jacques
>>>>>
>>>>>

>>>>
>>>>

>>>

>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

25 septembre 2008 - 10:00am

(Répondre à #7) #9

jbrassar

Bonjour Vincent,

Oui, le bouton supprimer reste présent !

Vincent, j'ai peut-être une piste.
J'ai bien l'impression qu'il y a AU MOINS une différence entre la v1.0
et la v1.1, dans l'IHM du workflow.
Elle se situerait dans l'affichage des cases à cocher !!

1) Dans la v1.0
Le comportement normal de l'application est le suivant :
- bouton supprimer toujours présent, quelques soient les permissions ;
- si permission DELETE donnée à un rôle, pour un état de la fiche, alors
case à cocher présente
(ex : dossier "Mes ressources en cours d'édition" pour OWNER et état
Privé) ;
- sinon, case à cocher absente (ex : dossier "Mes ressources en cours de
publication" pour OWNER et état En attente de publication).

2) Dans la v1.1
Le comportement normal de l'application est le suivant :
- bouton supprimer toujours présent, quelque soit les permissions ; (=
à la v1.0)
- case à cocher toujours présente quelques soient les rôles, les
permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!)

Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non la
permission DELETE à un rôle, ne change rien
à l'affichage des cases à cocher. Je pense que le pb se situe à ce niveau.
Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ?

Merci,

Jacques

Vincent Bonamy a écrit :

> Les cases à cocher restent présentes (je pense que c'est normal) par
> contre le bouton "Supprimer" reste présent également ?
> Vincent.
>
>
> Jacques Brassart wrote:

>> Vincent,
>>
>> Cela ne fonctionne toujours pas.
>>
>> J'ai refait un test (en respectant l'algorithme dont tu parles),
>> et j'ai configuré ORI-OAI v1.1 comme je l'avais fait pour la v1.0 (où
>> cela fonctionnait !!).
>>
>> J'ai fait un "ant all" puis un "ant update-acls" dans
>> "ori-oai-workflow-svn\".
>>
>> Mais rien à faire, les cases à cocher restent toujours visibles.
>>
>> Je ne sais plus quoi faire.
>> Quelle pourrait-être la source du pb ?
>> As-tu une idée ?
>>
>> Pour info, je mets en attaché les messages que j'obtiens quand je
>> déploie avec "ant all" et "ant update-acls".
>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache
>> avec le acls) que je ne sais pas interpréter :
>> sont-ils liés à mon pb ?
>>
>> Merci,
>>
>> Jacques
>>
>>
>>
>> Vincent Bonamy a écrit :

>>> Bonjour,
>>>
>>> L'algorithme de calcul des rôles et permissions a toujours été le
>>> même au travers des versions.
>>>
>>>
>>> Et voici comment cela fonctionne (selon vos retours à tous on peut
>>> bien sûr envisager de changer ce comportement, mais il me semble que
>>> c'est le plus simple à appréhender et que l'on arrivait ainsi à
>>> couvrir l'ensemble des besoins).
>>>
>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml sont
>>> globaux à toute l'application et appliquées ainsi à toutes les
>>> fiches, cela Indépendamment de toute autre chose. Il n'est pas
>>> possible de supprimer une permission ou un rôle sur une fiche alors
>>> que celui-ci a été positionné de manière globale dans toute
>>> l'application (via acegi-acls-root.xml).
>>>
>>> * Des permissions et rôles locaux supplémentaires peuvent être
>>> positionnés sur une fiche via le Workflow lui-même. On peut alors
>>> ajouter ou supprimer ces permissions.
>>>
>>>
>>> => pour une fiche donnée, les permissions et rôles effectifs sont
>>> l'UNION
>>> * des permissions et rôles positionnées en local sur celle-ci
>>> * et des permissions et rôles positionnées en global.
>>>
>>>
>>> Vincent.
>>>
>>>
>>>
>>> Jacques Brassart wrote:

>>>> Bonjour François,
>>>>
>>>> Ca ne fonctionne toujours pas !
>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>>>> suppression possible d'une fiche à modérer.
>>>>
>>>>
>>>> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
>>>> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>>>>

>>>> au lieu de :
>>>>

.
>>>>
>>>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>>>> l'affectation de "permissions" par défaut à certains rôles
>>>> n'a pour seul objectif que l'affichage de ces permissions sur la
>>>> page "Profil" de l'IHM du workflow, pour en informer l'utilisateur
>>>> authentifié. Je ne vois aucun autre impact fonctionnel.
>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>>>
>>>>
>>>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la
>>>> même manière, et cela fonctionnait :
>>>>
>>>> - suppression de la permission DELETE affectée par défaut dans
>>>> "acegi-acl-root.xml" ;
>>>> - suppression de la permission DELETE affectée par défaut dans
>>>> "workflow_easy.xml"
>>>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>>>> "deletePermission" !!
>>>> j'ai juste modifié la post-focntion "addPermission" :
>>>> addPermission
>>>> 132

)
>>>>
>>>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>>>> Aurais-tu une piste ?
>>>>
>>>> Merci !
>>>>
>>>> Jacques
>>>>
>>>>
>>>> François Jannin a écrit :

>>>>> Bonjour Jacques,
>>>>>
>>>>> Dans la version 1.1, le role moderator part avec le masque de
>>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>>>>
>>>>>
>>>>>

>>>>>

>>>>>
>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit pas,
>>>>> il faut lui ôter en ajoutant des les post-fonctions :
>>>>>
>>>>>
>>>>> >>>>> name="bean.name">deletePermission
>>>>> 16

>>>>> 4

>>>>>
>>>>>
>>>>> Cordialement,
>>>>>
>>>>> François
>>>>>
>>>>> Jacques Brassart a écrit :

>>>>>> Bonjour,
>>>>>>
>>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>>>> dans le workflow "easy" (version v1.1).
>>>>>>
>>>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>>>> Publish" dans le workflow "easy"
>>>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>>>
>>>>>>
>>>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>>>
>>>>>> ****************************
>>>>>>
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> addPermission*
>>>>>> * 128

>>>>>>
>>>>>> (au lieu de : 148

, dans la config d'origine).
>>>>>>
>>>>>> *****************************
>>>>>>
>>>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>>>
>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>>>> fiches que lui demande de publier l'auteur.
>>>>>> (case à cocher toujours présente dans la première colonne).
>>>>>> Or, sous la v1.0, la case à cocher n'était plus visible après
>>>>>> cette modif !! (le modérateur ne pouvait alors plus "Supprimer"
>>>>>> une fiche qu'il avait à examiner)
>>>>>>
>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>>>> attendre un certain temps après la modif ?)
>>>>>>
>>>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>>>> MODERATOR ?
>>>>>>
>>>>>> Merci !
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>

>>>>>
>>>>>

>>>>

>>>
>>>

>>

>
>

--
Jacques Brassart
UNR Nord-Pas de Calais
Université de Valenciennes et du Hainaut-Cambrésis
Tél : 03 27 51 17 70

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

26 septembre 2008 - 9:34am

(Répondre à #9) #10

vincentbonamy

Bonjour Jacques,

Effectivement j'ai regardé, en 1.1 on utilise les cases à cocher non
plus seulement pour permettre une suppression de masse des fiches mais
également pour faire du copier/coller par exemple.
Donc il n'est plus possible de cacher la case à cocher pour signifier
qu'on ne peut pas supprimer la fiche correspondant à cette case (puisque
la case peut-être utile aussi pour faire un copier/coller) ...

Le vrai problème ici est que même si tu n'as pas les droits tu peux
effectivement supprimer la fiche : le seul comportement acceptable
devrait être similaire à la tentative de suppression de fiches publiées
(c'est à dire indexées dans ori-oai-indexing) : on ne signale qu'après
coup que certaines fiches ne peuvent être supprimées car on n'a pas les
droits adéquats pour ce faire.

Sauf si tu as une meilleure idée, je fais la modification dans le code
et te transmets le patch.

A bientôt,
Vincent.

Jacques Brassart wrote:

> Bonjour Vincent,
>
> Oui, le bouton supprimer reste présent !
>
> Vincent, j'ai peut-être une piste.
> J'ai bien l'impression qu'il y a AU MOINS une différence entre la v1.0
> et la v1.1, dans l'IHM du workflow.
> Elle se situerait dans l'affichage des cases à cocher !!
>
> 1) Dans la v1.0
> Le comportement normal de l'application est le suivant :
> - bouton supprimer toujours présent, quelques soient les permissions ;
> - si permission DELETE donnée à un rôle, pour un état de la fiche,
> alors case à cocher présente
> (ex : dossier "Mes ressources en cours d'édition" pour OWNER et état
> Privé) ;
> - sinon, case à cocher absente (ex : dossier "Mes ressources en cours
> de publication" pour OWNER et état En attente de publication).
>
> 2) Dans la v1.1
> Le comportement normal de l'application est le suivant :
> - bouton supprimer toujours présent, quelque soit les permissions ;
> (= à la v1.0)
> - case à cocher toujours présente quelques soient les rôles, les
> permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!)
>
> Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non la
> permission DELETE à un rôle, ne change rien
> à l'affichage des cases à cocher. Je pense que le pb se situe à ce
> niveau.
> Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ?
>
> Merci,
>
> Jacques
>
>
>
>
> Vincent Bonamy a écrit :

>> Les cases à cocher restent présentes (je pense que c'est normal) par
>> contre le bouton "Supprimer" reste présent également ?
>> Vincent.
>>
>>
>> Jacques Brassart wrote:

>>> Vincent,
>>>
>>> Cela ne fonctionne toujours pas.
>>>
>>> J'ai refait un test (en respectant l'algorithme dont tu parles),
>>> et j'ai configuré ORI-OAI v1.1 comme je l'avais fait pour la v1.0
>>> (où cela fonctionnait !!).
>>>
>>> J'ai fait un "ant all" puis un "ant update-acls" dans
>>> "ori-oai-workflow-svn\".
>>>
>>> Mais rien à faire, les cases à cocher restent toujours visibles.
>>>
>>> Je ne sais plus quoi faire.
>>> Quelle pourrait-être la source du pb ?
>>> As-tu une idée ?
>>>
>>> Pour info, je mets en attaché les messages que j'obtiens quand je
>>> déploie avec "ant all" et "ant update-acls".
>>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache
>>> avec le acls) que je ne sais pas interpréter :
>>> sont-ils liés à mon pb ?
>>>
>>> Merci,
>>>
>>> Jacques
>>>
>>>
>>>
>>> Vincent Bonamy a écrit :

>>>> Bonjour,
>>>>
>>>> L'algorithme de calcul des rôles et permissions a toujours été le
>>>> même au travers des versions.
>>>>
>>>>
>>>> Et voici comment cela fonctionne (selon vos retours à tous on peut
>>>> bien sûr envisager de changer ce comportement, mais il me semble
>>>> que c'est le plus simple à appréhender et que l'on arrivait ainsi à
>>>> couvrir l'ensemble des besoins).
>>>>
>>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml
>>>> sont globaux à toute l'application et appliquées ainsi à toutes les
>>>> fiches, cela Indépendamment de toute autre chose. Il n'est pas
>>>> possible de supprimer une permission ou un rôle sur une fiche alors
>>>> que celui-ci a été positionné de manière globale dans toute
>>>> l'application (via acegi-acls-root.xml).
>>>>
>>>> * Des permissions et rôles locaux supplémentaires peuvent être
>>>> positionnés sur une fiche via le Workflow lui-même. On peut alors
>>>> ajouter ou supprimer ces permissions.
>>>>
>>>>
>>>> => pour une fiche donnée, les permissions et rôles effectifs sont
>>>> l'UNION
>>>> * des permissions et rôles positionnées en local sur celle-ci
>>>> * et des permissions et rôles positionnées en global.
>>>>
>>>>
>>>> Vincent.
>>>>
>>>>
>>>>
>>>> Jacques Brassart wrote:

>>>>> Bonjour François,
>>>>>
>>>>> Ca ne fonctionne toujours pas !
>>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>>>>> suppression possible d'une fiche à modérer.
>>>>>
>>>>>
>>>>> Pour info, hier, avant de modifier le fichier "workflow_easy.xml",
>>>>> j'avais aussi modifié le fichier "acegi-acl-root.xml" :
>>>>>

>>>>> au lieu de :
>>>>>

.
>>>>>
>>>>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>>>>> l'affectation de "permissions" par défaut à certains rôles
>>>>> n'a pour seul objectif que l'affichage de ces permissions sur la
>>>>> page "Profil" de l'IHM du workflow, pour en informer l'utilisateur
>>>>> authentifié. Je ne vois aucun autre impact fonctionnel.
>>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>>>>
>>>>>
>>>>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la
>>>>> même manière, et cela fonctionnait :
>>>>>
>>>>> - suppression de la permission DELETE affectée par défaut dans
>>>>> "acegi-acl-root.xml" ;
>>>>> - suppression de la permission DELETE affectée par défaut dans
>>>>> "workflow_easy.xml"
>>>>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>>>>> "deletePermission" !!
>>>>> j'ai juste modifié la post-focntion "addPermission" :
>>>>> addPermission
>>>>> 132

)
>>>>>
>>>>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>>>>> Aurais-tu une piste ?
>>>>>
>>>>> Merci !
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> François Jannin a écrit :

>>>>>> Bonjour Jacques,
>>>>>>
>>>>>> Dans la version 1.1, le role moderator part avec le masque de
>>>>>> permission moderate + delete, comme défini dans acegi-acl-root.xml :
>>>>>>
>>>>>>
>>>>>>

>>>>>>

>>>>>>
>>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit
>>>>>> pas, il faut lui ôter en ajoutant des les post-fonctions :
>>>>>>
>>>>>>
>>>>>> >>>>>> name="bean.name">deletePermission
>>>>>> 16

>>>>>> 4

>>>>>>
>>>>>>
>>>>>> Cordialement,
>>>>>>
>>>>>> François
>>>>>>
>>>>>> Jacques Brassart a écrit :

>>>>>>> Bonjour,
>>>>>>>
>>>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>>>>> dans le workflow "easy" (version v1.1).
>>>>>>>
>>>>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>>>>> Publish" dans le workflow "easy"
>>>>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>>>>
>>>>>>>
>>>>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>>>>
>>>>>>> ****************************
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>> addPermission*
>>>>>>> * 128

>>>>>>>
>>>>>>> (au lieu de : 148

, dans la config d'origine).
>>>>>>>
>>>>>>> *****************************
>>>>>>>
>>>>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>>>>
>>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>>>>> fiches que lui demande de publier l'auteur.
>>>>>>> (case à cocher toujours présente dans la première colonne).
>>>>>>> Or, sous la v1.0, la case à cocher n'était plus visible après
>>>>>>> cette modif !! (le modérateur ne pouvait alors plus "Supprimer"
>>>>>>> une fiche qu'il avait à examiner)
>>>>>>>
>>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>>>>> attendre un certain temps après la modif ?)
>>>>>>>
>>>>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>>>>> MODERATOR ?
>>>>>>>
>>>>>>> Merci !
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>

>>
>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

26 septembre 2008 - 9:52am

(Répondre à #10) #11

vincentbonamy

Rebonjour Jacques,

J'ai modifié un fichier source.

Cf ici :
http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src...

Tu as 3 possibilités au choix pour répercuter la modif :

* tu peux réinjecter la modif complètement manuellement

* tu peux appliquer le patch ci-joint via cette commande :
patch src/org/orioai/workflow/services/WorkflowInstanceService.java
WorkflowInstanceService.java.diff

* et le plus simple et rapide tu peux appliquer directement la
modification via subversion (si tu es branché sur subversion)
svn merge -r 830:831
http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk
[depuis ton répertoire ori-oai-workflow]

Dis moi si cela convient.
@+
Vincent.

Vincent Bonamy wrote:

> Bonjour Jacques,
>
> Effectivement j'ai regardé, en 1.1 on utilise les cases à cocher non
> plus seulement pour permettre une suppression de masse des fiches mais
> également pour faire du copier/coller par exemple.
> Donc il n'est plus possible de cacher la case à cocher pour signifier
> qu'on ne peut pas supprimer la fiche correspondant à cette case
> (puisque la case peut-être utile aussi pour faire un copier/coller) ...
>
> Le vrai problème ici est que même si tu n'as pas les droits tu peux
> effectivement supprimer la fiche : le seul comportement acceptable
> devrait être similaire à la tentative de suppression de fiches
> publiées (c'est à dire indexées dans ori-oai-indexing) : on ne signale
> qu'après coup que certaines fiches ne peuvent être supprimées car on
> n'a pas les droits adéquats pour ce faire.
>
> Sauf si tu as une meilleure idée, je fais la modification dans le code
> et te transmets le patch.
>
> A bientôt,
> Vincent.
>
>
>
> Jacques Brassart wrote:

>> Bonjour Vincent,
>>
>> Oui, le bouton supprimer reste présent !
>>
>> Vincent, j'ai peut-être une piste.
>> J'ai bien l'impression qu'il y a AU MOINS une différence entre la
>> v1.0 et la v1.1, dans l'IHM du workflow.
>> Elle se situerait dans l'affichage des cases à cocher !!
>>
>> 1) Dans la v1.0
>> Le comportement normal de l'application est le suivant :
>> - bouton supprimer toujours présent, quelques soient les permissions ;
>> - si permission DELETE donnée à un rôle, pour un état de la fiche,
>> alors case à cocher présente
>> (ex : dossier "Mes ressources en cours d'édition" pour OWNER et état
>> Privé) ;
>> - sinon, case à cocher absente (ex : dossier "Mes ressources en cours
>> de publication" pour OWNER et état En attente de publication).
>>
>> 2) Dans la v1.1
>> Le comportement normal de l'application est le suivant :
>> - bouton supprimer toujours présent, quelque soit les permissions ;
>> (= à la v1.0)
>> - case à cocher toujours présente quelques soient les rôles, les
>> permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!)
>>
>> Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non la
>> permission DELETE à un rôle, ne change rien
>> à l'affichage des cases à cocher. Je pense que le pb se situe à ce
>> niveau.
>> Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ?
>>
>> Merci,
>>
>> Jacques
>>
>>
>>
>>
>> Vincent Bonamy a écrit :

>>> Les cases à cocher restent présentes (je pense que c'est normal) par
>>> contre le bouton "Supprimer" reste présent également ?
>>> Vincent.
>>>
>>>
>>> Jacques Brassart wrote:

>>>> Vincent,
>>>>
>>>> Cela ne fonctionne toujours pas.
>>>>
>>>> J'ai refait un test (en respectant l'algorithme dont tu parles),
>>>> et j'ai configuré ORI-OAI v1.1 comme je l'avais fait pour la v1.0
>>>> (où cela fonctionnait !!).
>>>>
>>>> J'ai fait un "ant all" puis un "ant update-acls" dans
>>>> "ori-oai-workflow-svn\".
>>>>
>>>> Mais rien à faire, les cases à cocher restent toujours visibles.
>>>>
>>>> Je ne sais plus quoi faire.
>>>> Quelle pourrait-être la source du pb ?
>>>> As-tu une idée ?
>>>>
>>>> Pour info, je mets en attaché les messages que j'obtiens quand je
>>>> déploie avec "ant all" et "ant update-acls".
>>>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache
>>>> avec le acls) que je ne sais pas interpréter :
>>>> sont-ils liés à mon pb ?
>>>>
>>>> Merci,
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Vincent Bonamy a écrit :

>>>>> Bonjour,
>>>>>
>>>>> L'algorithme de calcul des rôles et permissions a toujours été le
>>>>> même au travers des versions.
>>>>>
>>>>>
>>>>> Et voici comment cela fonctionne (selon vos retours à tous on peut
>>>>> bien sûr envisager de changer ce comportement, mais il me semble
>>>>> que c'est le plus simple à appréhender et que l'on arrivait ainsi
>>>>> à couvrir l'ensemble des besoins).
>>>>>
>>>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml
>>>>> sont globaux à toute l'application et appliquées ainsi à toutes
>>>>> les fiches, cela Indépendamment de toute autre chose. Il n'est pas
>>>>> possible de supprimer une permission ou un rôle sur une fiche
>>>>> alors que celui-ci a été positionné de manière globale dans toute
>>>>> l'application (via acegi-acls-root.xml).
>>>>>
>>>>> * Des permissions et rôles locaux supplémentaires peuvent être
>>>>> positionnés sur une fiche via le Workflow lui-même. On peut alors
>>>>> ajouter ou supprimer ces permissions.
>>>>>
>>>>>
>>>>> => pour une fiche donnée, les permissions et rôles effectifs sont
>>>>> l'UNION
>>>>> * des permissions et rôles positionnées en local sur celle-ci
>>>>> * et des permissions et rôles positionnées en global.
>>>>>
>>>>>
>>>>> Vincent.
>>>>>
>>>>>
>>>>>
>>>>> Jacques Brassart wrote:

>>>>>> Bonjour François,
>>>>>>
>>>>>> Ca ne fonctionne toujours pas !
>>>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>>>>>> suppression possible d'une fiche à modérer.
>>>>>>
>>>>>>
>>>>>> Pour info, hier, avant de modifier le fichier
>>>>>> "workflow_easy.xml", j'avais aussi modifié le fichier
>>>>>> "acegi-acl-root.xml" :
>>>>>>

>>>>>> au lieu de :
>>>>>>

.
>>>>>>
>>>>>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>>>>>> l'affectation de "permissions" par défaut à certains rôles
>>>>>> n'a pour seul objectif que l'affichage de ces permissions sur la
>>>>>> page "Profil" de l'IHM du workflow, pour en informer
>>>>>> l'utilisateur authentifié. Je ne vois aucun autre impact
>>>>>> fonctionnel.
>>>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>>>>>
>>>>>>
>>>>>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la
>>>>>> même manière, et cela fonctionnait :
>>>>>>
>>>>>> - suppression de la permission DELETE affectée par défaut dans
>>>>>> "acegi-acl-root.xml" ;
>>>>>> - suppression de la permission DELETE affectée par défaut dans
>>>>>> "workflow_easy.xml"
>>>>>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>>>>>> "deletePermission" !!
>>>>>> j'ai juste modifié la post-focntion "addPermission" :
>>>>>> addPermission
>>>>>> 132

)
>>>>>>
>>>>>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>>>>>> Aurais-tu une piste ?
>>>>>>
>>>>>> Merci !
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> François Jannin a écrit :

>>>>>>> Bonjour Jacques,
>>>>>>>
>>>>>>> Dans la version 1.1, le role moderator part avec le masque de
>>>>>>> permission moderate + delete, comme défini dans
>>>>>>> acegi-acl-root.xml :
>>>>>>>
>>>>>>>
>>>>>>>

>>>>>>>

>>>>>>>
>>>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit
>>>>>>> pas, il faut lui ôter en ajoutant des les post-fonctions :
>>>>>>>
>>>>>>>
>>>>>>> >>>>>>> name="bean.name">deletePermission
>>>>>>> 16

>>>>>>> 4

>>>>>>>
>>>>>>>
>>>>>>> Cordialement,
>>>>>>>
>>>>>>> François
>>>>>>>
>>>>>>> Jacques Brassart a écrit :

>>>>>>>> Bonjour,
>>>>>>>>
>>>>>>>> Je souhaite enlever la permission DELETE pour le rôle MODERATOR
>>>>>>>> dans le workflow "easy" (version v1.1).
>>>>>>>>
>>>>>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask to
>>>>>>>> Publish" dans le workflow "easy"
>>>>>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>>>>>
>>>>>>>>
>>>>>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>>>>>
>>>>>>>> ****************************
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>> addPermission*
>>>>>>>> * 128

>>>>>>>>
>>>>>>>> (au lieu de : 148

, dans la config d'origine).
>>>>>>>>
>>>>>>>> *****************************
>>>>>>>>
>>>>>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>>>>>
>>>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer les
>>>>>>>> fiches que lui demande de publier l'auteur.
>>>>>>>> (case à cocher toujours présente dans la première colonne).
>>>>>>>> Or, sous la v1.0, la case à cocher n'était plus visible après
>>>>>>>> cette modif !! (le modérateur ne pouvait alors plus "Supprimer"
>>>>>>>> une fiche qu'il avait à examiner)
>>>>>>>>
>>>>>>>> Y aurait-t-il un pb de cache avec le module workflow ? (dois-je
>>>>>>>> attendre un certain temps après la modif ?)
>>>>>>>>
>>>>>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer" pour
>>>>>>>> MODERATOR ?
>>>>>>>>
>>>>>>>> Merci !
>>>>>>>>
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>

>>>>>>>
>>>>>>>

>>>>>>

>>>>>
>>>>>

>>>>

>>>
>>>

>>

>

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

26 septembre 2008 - 3:50pm

(Répondre à #11) #12

jbrassar

Bonjour Vincent,

Je viens de tester : c'est parfait comme cela !
Pourrais-tu juste m'indiquer dans quel fichier est le texte en français
du message d'erreur, en cas de besoin ?

Merci beaucoup pour le coup de main !

Jacques

Vincent Bonamy a écrit :

> Rebonjour Jacques,
>
> J'ai modifié un fichier source.
>
> Cf ici :
> http://sourcesup.cru.fr/cgi/viewvc.cgi/ori-oai-workflow-spring/trunk/src...
>
>
> Tu as 3 possibilités au choix pour répercuter la modif :
>
> * tu peux réinjecter la modif complètement manuellement
>
> * tu peux appliquer le patch ci-joint via cette commande :
> patch src/org/orioai/workflow/services/WorkflowInstanceService.java
> WorkflowInstanceService.java.diff
>
> * et le plus simple et rapide tu peux appliquer directement la
> modification via subversion (si tu es branché sur subversion)
> svn merge -r 830:831
> http://subversion.cru.fr/ori-workflow/ori-oai-workflow-spring/trunk
> [depuis ton répertoire ori-oai-workflow]
>
>
> Dis moi si cela convient.
> @+
> Vincent.
>
>
>
> Vincent Bonamy wrote:

>> Bonjour Jacques,
>>
>> Effectivement j'ai regardé, en 1.1 on utilise les cases à cocher non
>> plus seulement pour permettre une suppression de masse des fiches
>> mais également pour faire du copier/coller par exemple.
>> Donc il n'est plus possible de cacher la case à cocher pour signifier
>> qu'on ne peut pas supprimer la fiche correspondant à cette case
>> (puisque la case peut-être utile aussi pour faire un copier/coller) ...
>>
>> Le vrai problème ici est que même si tu n'as pas les droits tu peux
>> effectivement supprimer la fiche : le seul comportement acceptable
>> devrait être similaire à la tentative de suppression de fiches
>> publiées (c'est à dire indexées dans ori-oai-indexing) : on ne
>> signale qu'après coup que certaines fiches ne peuvent être supprimées
>> car on n'a pas les droits adéquats pour ce faire.
>>
>> Sauf si tu as une meilleure idée, je fais la modification dans le
>> code et te transmets le patch.
>>
>> A bientôt,
>> Vincent.
>>
>>
>>
>> Jacques Brassart wrote:

>>> Bonjour Vincent,
>>>
>>> Oui, le bouton supprimer reste présent !
>>>
>>> Vincent, j'ai peut-être une piste.
>>> J'ai bien l'impression qu'il y a AU MOINS une différence entre la
>>> v1.0 et la v1.1, dans l'IHM du workflow.
>>> Elle se situerait dans l'affichage des cases à cocher !!
>>>
>>> 1) Dans la v1.0
>>> Le comportement normal de l'application est le suivant :
>>> - bouton supprimer toujours présent, quelques soient les permissions ;
>>> - si permission DELETE donnée à un rôle, pour un état de la fiche,
>>> alors case à cocher présente
>>> (ex : dossier "Mes ressources en cours d'édition" pour OWNER et état
>>> Privé) ;
>>> - sinon, case à cocher absente (ex : dossier "Mes ressources en
>>> cours de publication" pour OWNER et état En attente de publication).
>>>
>>> 2) Dans la v1.1
>>> Le comportement normal de l'application est le suivant :
>>> - bouton supprimer toujours présent, quelque soit les permissions
>>> ; (= à la v1.0)
>>> - case à cocher toujours présente quelques soient les rôles, les
>>> permissions, les états de la fiche. (DIFFERRENT de la v1.0 !!)
>>>
>>> Autrement dit, dans la v1.1 contrairement à la v1.0, donner ou non
>>> la permission DELETE à un rôle, ne change rien
>>> à l'affichage des cases à cocher. Je pense que le pb se situe à ce
>>> niveau.
>>> Peux-tu jeter un oeil de ce côté là, je ne sais pas comment faire ?
>>>
>>> Merci,
>>>
>>> Jacques
>>>
>>>
>>>
>>>
>>> Vincent Bonamy a écrit :

>>>> Les cases à cocher restent présentes (je pense que c'est normal)
>>>> par contre le bouton "Supprimer" reste présent également ?
>>>> Vincent.
>>>>
>>>>
>>>> Jacques Brassart wrote:

>>>>> Vincent,
>>>>>
>>>>> Cela ne fonctionne toujours pas.
>>>>>
>>>>> J'ai refait un test (en respectant l'algorithme dont tu parles),
>>>>> et j'ai configuré ORI-OAI v1.1 comme je l'avais fait pour la v1.0
>>>>> (où cela fonctionnait !!).
>>>>>
>>>>> J'ai fait un "ant all" puis un "ant update-acls" dans
>>>>> "ori-oai-workflow-svn\".
>>>>>
>>>>> Mais rien à faire, les cases à cocher restent toujours visibles.
>>>>>
>>>>> Je ne sais plus quoi faire.
>>>>> Quelle pourrait-être la source du pb ?
>>>>> As-tu une idée ?
>>>>>
>>>>> Pour info, je mets en attaché les messages que j'obtiens quand je
>>>>> déploie avec "ant all" et "ant update-acls".
>>>>> Il y a en effet qqs warnings (deprecation avec le ant all, ehcache
>>>>> avec le acls) que je ne sais pas interpréter :
>>>>> sont-ils liés à mon pb ?
>>>>>
>>>>> Merci,
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Vincent Bonamy a écrit :

>>>>>> Bonjour,
>>>>>>
>>>>>> L'algorithme de calcul des rôles et permissions a toujours été le
>>>>>> même au travers des versions.
>>>>>>
>>>>>>
>>>>>> Et voici comment cela fonctionne (selon vos retours à tous on
>>>>>> peut bien sûr envisager de changer ce comportement, mais il me
>>>>>> semble que c'est le plus simple à appréhender et que l'on
>>>>>> arrivait ainsi à couvrir l'ensemble des besoins).
>>>>>>
>>>>>> * Les permissions et rôles positionnés dans acegi-acls-root.xml
>>>>>> sont globaux à toute l'application et appliquées ainsi à toutes
>>>>>> les fiches, cela Indépendamment de toute autre chose. Il n'est
>>>>>> pas possible de supprimer une permission ou un rôle sur une fiche
>>>>>> alors que celui-ci a été positionné de manière globale dans toute
>>>>>> l'application (via acegi-acls-root.xml).
>>>>>>
>>>>>> * Des permissions et rôles locaux supplémentaires peuvent être
>>>>>> positionnés sur une fiche via le Workflow lui-même. On peut alors
>>>>>> ajouter ou supprimer ces permissions.
>>>>>>
>>>>>>
>>>>>> => pour une fiche donnée, les permissions et rôles effectifs sont
>>>>>> l'UNION
>>>>>> * des permissions et rôles positionnées en local sur celle-ci
>>>>>> * et des permissions et rôles positionnées en global.
>>>>>>
>>>>>>
>>>>>> Vincent.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jacques Brassart wrote:

>>>>>>> Bonjour François,
>>>>>>>
>>>>>>> Ca ne fonctionne toujours pas !
>>>>>>> La case à cocher apparaît toujours pour le rôle MODERATOR, donc
>>>>>>> suppression possible d'une fiche à modérer.
>>>>>>>
>>>>>>>
>>>>>>> Pour info, hier, avant de modifier le fichier
>>>>>>> "workflow_easy.xml", j'avais aussi modifié le fichier
>>>>>>> "acegi-acl-root.xml" :
>>>>>>>

>>>>>>> au lieu de :
>>>>>>>

.
>>>>>>>
>>>>>>> Apparemment, dans "acegi-acl-root.xml", j'ai l'impression que
>>>>>>> l'affectation de "permissions" par défaut à certains rôles
>>>>>>> n'a pour seul objectif que l'affichage de ces permissions sur la
>>>>>>> page "Profil" de l'IHM du workflow, pour en informer
>>>>>>> l'utilisateur authentifié. Je ne vois aucun autre impact
>>>>>>> fonctionnel.
>>>>>>> (voir aussi mon mail du 17/09 : test sur la permission CREATE)
>>>>>>>
>>>>>>>
>>>>>>> Dans la v1.0, j'avais touché aux mêmes fichiers, quasiment de la
>>>>>>> même manière, et cela fonctionnait :
>>>>>>>
>>>>>>> - suppression de la permission DELETE affectée par défaut dans
>>>>>>> "acegi-acl-root.xml" ;
>>>>>>> - suppression de la permission DELETE affectée par défaut dans
>>>>>>> "workflow_easy.xml"
>>>>>>> (dans ce dernier cas, je n'ai pas eu à ajouter une post-fonction
>>>>>>> "deletePermission" !!
>>>>>>> j'ai juste modifié la post-focntion "addPermission" :
>>>>>>> addPermission
>>>>>>> 132

)
>>>>>>>
>>>>>>> Qu'est-ce qui aurait changé entre la v1.0 et la v1.1 ?
>>>>>>> Aurais-tu une piste ?
>>>>>>>
>>>>>>> Merci !
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> François Jannin a écrit :

>>>>>>>> Bonjour Jacques,
>>>>>>>>
>>>>>>>> Dans la version 1.1, le role moderator part avec le masque de
>>>>>>>> permission moderate + delete, comme défini dans
>>>>>>>> acegi-acl-root.xml :
>>>>>>>>
>>>>>>>>
>>>>>>>>

>>>>>>>>

>>>>>>>>
>>>>>>>> Donc le fait de NE PAS ajouter la permission DELETE ne suffit
>>>>>>>> pas, il faut lui ôter en ajoutant des les post-fonctions :
>>>>>>>>
>>>>>>>>
>>>>>>>> >>>>>>>> name="bean.name">deletePermission
>>>>>>>> 16

>>>>>>>> 4

>>>>>>>>
>>>>>>>>
>>>>>>>> Cordialement,
>>>>>>>>
>>>>>>>> François
>>>>>>>>
>>>>>>>> Jacques Brassart a écrit :

>>>>>>>>> Bonjour,
>>>>>>>>>
>>>>>>>>> Je souhaite enlever la permission DELETE pour le rôle
>>>>>>>>> MODERATOR dans le workflow "easy" (version v1.1).
>>>>>>>>>
>>>>>>>>> Sous la v1.0, j'avais réussi en modifiant la transition "Ask
>>>>>>>>> to Publish" dans le workflow "easy"
>>>>>>>>> (ori-oai-workflow-svn\conf\properties\spring\osworkflow\workflows\workflow_easy.xml).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> J'ai appliqué la même recette pour la v1.1, à savoir :
>>>>>>>>>
>>>>>>>>> ****************************
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> addPermission*
>>>>>>>>> * 128

>>>>>>>>>
>>>>>>>>> (au lieu de : 148

, dans la config d'origine).
>>>>>>>>>
>>>>>>>>> *****************************
>>>>>>>>>
>>>>>>>>> J'ai fait un "ant all", puis un "ant update-acls".
>>>>>>>>>
>>>>>>>>> Mais apparemment, le rôle MODERATOR peut toujours supprimer
>>>>>>>>> les fiches que lui demande de publier l'auteur.
>>>>>>>>> (case à cocher toujours présente dans la première colonne).
>>>>>>>>> Or, sous la v1.0, la case à cocher n'était plus visible après
>>>>>>>>> cette modif !! (le modérateur ne pouvait alors plus
>>>>>>>>> "Supprimer" une fiche qu'il avait à examiner)
>>>>>>>>>
>>>>>>>>> Y aurait-t-il un pb de cache avec le module workflow ?
>>>>>>>>> (dois-je attendre un certain temps après la modif ?)
>>>>>>>>>
>>>>>>>>> Sinon, comment désactiver cette fonctionnalité "Supprimer"
>>>>>>>>> pour MODERATOR ?
>>>>>>>>>
>>>>>>>>> Merci !
>>>>>>>>>
>>>>>>>>> Jacques
>>>>>>>>>
>>>>>>>>>

>>>>>>>>
>>>>>>>>

>>>>>>>

>>>>>>
>>>>>>

>>>>>

>>>>
>>>>

>>>

>>

>
>

--
Jacques Brassart
UNR Nord-Pas de Calais
Université de Valenciennes et du Hainaut-Cambrésis
Tél : 03 27 51 17 70

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.

Sujet clos

Valoriser le patrimoine numérique scientifique, pédagogique et documentaire des universités et le partager par un réseau de portails communicants en OAI

Traduction auto Google

Aide

Options d'affichage des commentaires