Main menu

Forum


A toy VW combi with a Christmas tree on the roof.

The developer takes a few days off for Holidays...
...and will be back with charged battery!

From 23 December to 2 January included
During this period,
assistance from developer will not be provided.

× Forum d'aide en Français

Modification comportement ACL entre J!3 et J!4

  • web.academie@denikol.fr
  • Topic Author
  • New Member
  • New Member
More
1 year 1 week ago #18402 by web.academie@denikol.fr
Modification comportement ACL entre J!3 et J!4 was created by web.academie@denikol.fr
Bonjour Je suis en cours de migration d'un un site J3 vers J4

L'état des lieux
J'utilise Icagenda pour publier des événements qui, pour certains, utilisent la fonction inscriptions destinée au public (inscription sans identification)
Les événements sont classés par catégorie, et il existe un "référent" par catégorie qui est maitre de ses événements et des inscriptions du public.
Afin de permettre aux référents la gestion de leur calendrier, je n'ai pas eu d'autre choix que de laisser un accès restreint coté backend.
Chaque référent peut donc créer, et modifier SES événements et gérer ses inscriptions ( exportation csv).

La pré-migration sur un site de dev
Tout ceci fonctionnait très bien en J!3, mais le comportement semble changer en J!4

En effet la "modification de ses éléments"  pour un groupe d’utilisateur (Le groupe de référents) ne semble plus fonctionner correctement :Un événement créé par un référent (qui n'est pas superuser) ne peut pas être modifié par ce même utilisateur. 
idem pour l’accès aux inscriptions. Il ne voit QUE les  inscriptions des événements qu'il gère, mais ne peut pas les éditer. 

Il faut leur donner l'autorisation "modifier" pour qu'il puissent modifier les événementset éditer les inscriptions, mais dans ce cas il peuvent avoir accès a TOUS les événements, et ce n'est pas ce que je veux.j’ai du louper quelque chose

Alternative possible:
Un accès à toutes ces fonctionnalités en front-end est envisageable (version pro >3.8 ) (ce qui éviterait le backend..) mais avant de l'acquérir, je n'ai pas trouvé d'informations détaillées sur cette fonctionnalité, pour savoir s'il elle répondait à mon besoin (éditions inscriptions, mailling aux inscrits, filtrage, etc)

S'il y avait un site démo de la version pro, ce serait super.

Quoiqu'il en soit je re-nouvelle mes félicitations pour ce module de calendrier que j'utilise depuis bientôt 8 ans.

Denis

Please Log in or Create an account to join the conversation.

  • web.academie@denikol.fr
  • Topic Author
  • New Member
  • New Member
More
1 year 1 week ago #18403 by web.academie@denikol.fr
Replied by web.academie@denikol.fr on topic Modification comportement ACL entre J!3 et J!4
Bonjour Cyril,
Comme demandé, j'ajoute des copies d'écrans pour analyse.

Cordialement
Denis
Attachments:

Please Log in or Create an account to join the conversation.

  • Lyr!C
  • Lyr!C's Avatar
  • Administrator
  • Administrator
  • Lead Developer
More
1 year 1 week ago - 1 year 6 days ago #18404 by Lyr!C
Bonjour,

Effectivement, je confirme le problème sous J4/J5

Ceci seulement côté admin, car le contrôle ACL est correct côté frontal du site.

Je vais prévoir le correctif pour la version 3.9 (janvier).

En attendant, vous pouvez éditer le fichier administrator/components/com_icagenda/src/Controller/EventController.php

Après la ligne :
use VersionableControllerTrait;

Ajouter ceci :
protected function allowEdit($data = [], $key = 'id')
{
    $recordId = (int) isset($data[$key]) ? $data[$key] : 0;
    $user = $this->app->getIdentity();

    // Zero record (id:0), return component edit permission by calling parent controller method
    if (!$recordId) {
        return parent::allowEdit($data, $key);
    }

    // Check edit on the record asset (explicit or inherited)
    if ($user->authorise('core.edit', 'com_icagenda.event.' . $recordId)) {
        return true;
    }

    // Check edit own on the record asset (explicit or inherited)
    if ($user->authorise('core.edit.own', 'com_icagenda.event.' . $recordId)) {
        // Existing record already has an owner, get it
        $record = $this->getModel()->getItem($recordId);

        if (empty($record)) {
            return false;
        }

        // Grant if current user is owner of the record
        return $user->id == $record->created_by;
    }

    return false;
}

Ceci corrigera pour l'édition des évènements côté admin.

Merci de ce retour !

Bien cordialement,
Cyril
 

Latest version : iCagenda 3.9.7
We recommend every user to keep iCagenda updated.
Don't forget to have your Joomla!™ up-to-date!

Do you like iCagenda?
I would appreciate if you could take 5 minutes to post a review on JED (Joomla Extensions Directory) .

File Attachment:

Last edit: 1 year 6 days ago by Lyr!C.

Please Log in or Create an account to join the conversation.

  • web.academie@denikol.fr
  • Topic Author
  • New Member
  • New Member
More
1 year 6 days ago #18406 by web.academie@denikol.fr
Replied by web.academie@denikol.fr on topic Modification comportement ACL entre J!3 et J!4
Bonjour Cyril
Votre modification fonctionne ... enfin presque!

Pour éviter l'erreur  :
syntax error, unexpected token ","

en effet j'ai dû remplacer la ligne 34protected function allowEdit($data = , $key = 'id')
par 
protected function allowEdit($data = array(), $key = 'id')

et les événements sont éditables. Merci

En revanche, le problème est toujours présent sur les inscriptions, et je n'ai pas réussi à le résoudre en adaptant votre fonction dans \RegistrationController.php.

Cordialement
Denis
 

Please Log in or Create an account to join the conversation.

  • web.academie@denikol.fr
  • Topic Author
  • New Member
  • New Member
More
1 year 6 days ago #18407 by web.academie@denikol.fr
Replied by web.academie@denikol.fr on topic Modification comportement ACL entre J!3 et J!4
Rectificatif:
avec votre ligne 34 d'origine j'ai une erreur à l'édition de l'événement

Avec ma modification, je n'ai plus l'erreur mais désormais j'ai de nouveau le message 'Edition non permise' en rouge.

Cordialement
Denis

Please Log in or Create an account to join the conversation.

  • Lyr!C
  • Lyr!C's Avatar
  • Administrator
  • Administrator
  • Lead Developer
More
1 year 6 days ago #18408 by Lyr!C
Bonjour,

Effectivement, j'avais oublié l'array vide par défaut dans la fonction.

Par contre, de mon côté, avec le code corrigé, cela fonctionne.

Pour les inscriptions, vous avez remplacé "com_icagenda.event" par "com_icagenda.registration" ?

Bien cordialement,
Cyril

Latest version : iCagenda 3.9.7
We recommend every user to keep iCagenda updated.
Don't forget to have your Joomla!™ up-to-date!

Do you like iCagenda?
I would appreciate if you could take 5 minutes to post a review on JED (Joomla Extensions Directory) .

File Attachment:

Please Log in or Create an account to join the conversation.

  • web.academie@denikol.fr
  • Topic Author
  • New Member
  • New Member
More
1 year 6 days ago #18410 by web.academie@denikol.fr
Replied by web.academie@denikol.fr on topic Modification comportement ACL entre J!3 et J!4
Bonsoir
re-rectificatif, pour les événements c'est OK (un espace de trop dans le code php ..)

pour les inscriptions :
j'ai trouvé:
j'avais effectivement modifié les .event en .registration, mais la comparaison se faisant sur le created_by,et celui-ci étant anonyme, ca ne fonctionnait pas.

en effet, en J3, j'ai une tache périodique sql qui met a jour le userid de l'inscription avec le userid de l'évènement associé pour que le propriétaire de l'événement soit le propriétaire de l'inscription et puisse y accéder.

Il semble qu'en J4, (avec votre code en tout cas) ce soit le champ created_by qu'il faille mettre à jour.
je vais modifier ma requête SQL en ce sens.

Merci pour le dépannage
Joyeuses fêtes de fin d'année

Denis

Please Log in or Create an account to join the conversation.

  • Lyr!C
  • Lyr!C's Avatar
  • Administrator
  • Administrator
  • Lead Developer
More
1 year 5 days ago #18413 by Lyr!C
Bonjour,
En effet, pour les inscriptions, il faut quelques ajustements (car il n'y a pas obligatoirement un "propriétaire" selon les paramètres).

Il faudrait utiliser ceci:
// Grant if current user is owner of the record
if ($user->id == $record->created_by || $user->id == $record->userid) {
    return true;
}

Par contre, pour votre cas spécifique, cela s'inscrit dans une possible nouvelle option pour autoriser aussi le créateur d'un évènement d'éditer les inscriptions à celui-ci.
Cela sans besoin d'une requête SQL perso, et qui plus est, il est préférable de ne pas modifier userid ni created_by qui sont censés être liés à l'utilisateur inscrit et non le créateur de l'évènement.
L'idée est intéressante, dont je vais travailler dessus ! ;-)

Bien cordialement,
Cyril

 

Latest version : iCagenda 3.9.7
We recommend every user to keep iCagenda updated.
Don't forget to have your Joomla!™ up-to-date!

Do you like iCagenda?
I would appreciate if you could take 5 minutes to post a review on JED (Joomla Extensions Directory) .

File Attachment:

Please Log in or Create an account to join the conversation.

Moderators: Lyr!C
Time to create page: 0.263 seconds

 

Follow Us

Create your Joomla templates with Template Creator CK

acymailing logo new