Of course. I'll try to reproduce the issue in a test. In the meantime I want to clarify that I don't use cumulative permissions, because I need to configure for each permission if it's an ALLOW or DENY entry, and it's easier this way. Taking this fact into account, If I could update the "granting" property of an ACE, I'd just update the existing ACE instead of deleting and inserting it on the ACL. I've noticed that you can update a field ACE passing the following properties to the "updateObjectFieldAce" method of the Acl class:
$index, $field, $mask, $strategy = null Could it be an issue if we add an additional property ($granting) to update the granting property of the ACE or this could be a problem at some point of the update? if it wouldn't be an issue I could try to add the functionality, but first I'd like to be sure if there's a technical reason to not update the $granting property of an ACE. Thanks! Best regards. 2011/4/8 Johannes Schmitt <schmitt...@gmail.com> > It would be nice if you can provide a failing test case in > MutableAclProviderTest, otherwise just create a ticket, and I'll take a look > at it. > > Johannes > > > On Fri, Apr 8, 2011 at 9:43 PM, Gustavo Adrian < > comfortablynum...@gmail.com> wrote: > >> MySQL logs show: >> >> 2940 Query START TRANSACTION >> 2940 Query UPDATE acl_entries SET ace_order = 4 WHERE id = 464 >> 2940 Query UPDATE acl_entries SET ace_order = 3 WHERE id = 465 >> 2940 Query UPDATE acl_entries SET ace_order = 3 WHERE id = 466 >> 2940 Query UPDATE acl_entries SET ace_order = 1 WHERE id = 479 >> 2940 Query rollback >> >> >> It first changes ace_order's, so if I deleted the entry with ace_order = >> 1, at the time of synchronizing changes in the DB it first updates ace_order >> fields, so the ACE I deleted is still there (with ace_order = 1 too). This >> is, of course, for ACEs that are affected for the same unique index, which >> have this fields: class_id, object_identity_id, field_name and ace_order. >> >> >> Thanks. >> >> 2011/4/8 Gustavo Adrian <comfortablynum...@gmail.com> >> >>> Hi all, >>> >>> During the update process of fields ACEs I'm getting this error: >>> >>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry >>> '12-1106-entityTypeFriendly-1' for key >>> 'UNIQ_46C8B806EA000B103D9AB4A64DEF17BCE4289BF4' >>> >>> I explain what I'm doing: As I allow to change the type of granting of >>> the permission (allow or deny), and I didn't find a way to update the >>> granting property of an ACE with acl methods like "updateObjectFieldACE" or >>> the like, I'm just deleting the ACE and inserting it again on the ACL with >>> the new value for the granting property. I do all this stuff for every field >>> and, at the end, I update the ACL with $aclProvider->updateACL($acl); . >>> Could this way of updating the granting property of an ACE bring this >>> exception? >>> >>> I'm looking at the MutableAclProvider and I see that the >>> updateXXXProperty methods first insert new ACEs and finally delete old ACEs >>> (the ones which were deleted from the ACL). Could this mean that, as I >>> deleted and inserted a new ACE from an ACL at the same time, at the moment >>> of the update on the DB it first try to insert the new ACE with the same >>> ace_order as the one that is going to be deleted? it's just a guess. I'm >>> trying to trace the error so I can give further details. >>> >>> Is there a way to update the granting property of an ACE so I can update >>> the ACE instead of deleting it an reinserting it again? >>> >>> >>> >>> Thanks in advance! >>> >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony users" group. >> To post to this group, send email to symfony-users@googlegroups.com >> To unsubscribe from this group, send email to >> symfony-users+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/symfony-users?hl=en >> > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
