I am porting my component J!Research to work in Joomla! 2.5 but I have a
small problem regarding the ACL and after a while I have been unable to
solve it. I have some table called #__jresearch_member which includes the
asset_id column. I have checked its records and they seem to match the id
in the #__assets table. The point is that for user besides the super
administrator, the method $user->authorise returns null. File s1.png shows
some records from my assets table. Pay attention to the row with id 189,
its rule column has the following value:
s2.png contains a screenhost of my form, as well as its source code
(member.xml). Note that I get a conflict for the "Publisher" group even
though my global configurations are set to allow the specified actions to
member of that group. The global configuration (config.xml) as well as my
access.xml are also attached. s3.png shows my current global configuration.
When a user of the group "Publisher" tries to edit the item from frontend,
the $user->authorise method returns null for all possible actions. I have
debugged the application and the asset_name matches my item
("com_jresearch.member.3" in my example) and everything seems to be in
order in my understanding.
Does anybody have an idea about the cause of the problem? I would really
appreciate your help since this bug is causing a lot of trouble to my
users. Thanks in advance!
All the best,
Luis
PD: The rules column of my component asset (id=187) is
You don't need the middle part of the name .... just have core.edit, core.edit.state. That way the values are inherited from the global configurations and categories. You don't need to specify the asset type, that is already known from the context and asset table (name field).
On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
> Dear Joomla! community:
> I am porting my component J!Research to work in Joomla! 2.5 but I have a > small problem regarding the ACL and after a while I have been unable to > solve it. I have some table called #__jresearch_member which includes the > asset_id column. I have checked its records and they seem to match the id > in the #__assets table. The point is that for user besides the super > administrator, the method $user->authorise returns null. File s1.png shows > some records from my assets table. Pay attention to the row with id 189, > its rule column has the following value:
> s2.png contains a screenhost of my form, as well as its source code > (member.xml). Note that I get a conflict for the "Publisher" group even > though my global configurations are set to allow the specified actions to > member of that group. The global configuration (config.xml) as well as my > access.xml are also attached. s3.png shows my current global configuration.
> When a user of the group "Publisher" tries to edit the item from frontend, > the $user->authorise method returns null for all possible actions. I have > debugged the application and the asset_name matches my item > ("com_jresearch.member.3" in my example) and everything seems to be in > order in my understanding.
> Does anybody have an idea about the cause of the problem? I would really > appreciate your help since this bug is causing a lot of trouble to my > users. Thanks in advance!
> All the best,
> Luis
> PD: The rules column of my component asset (id=187) is
On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
> You don't need the middle part of the name .... just have core.edit, > core.edit.state. That way the values are inherited from the global > configurations and categories. You don't need to specify the asset type, > that is already known from the context and asset table (name field).
> Elin
> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>> Dear Joomla! community:
>> I am porting my component J!Research to work in Joomla! 2.5 but I have a >> small problem regarding the ACL and after a while I have been unable to >> solve it. I have some table called #__jresearch_member which includes the >> asset_id column. I have checked its records and they seem to match the id >> in the #__assets table. The point is that for user besides the super >> administrator, the method $user->authorise returns null. File s1.png shows >> some records from my assets table. Pay attention to the row with id 189, >> its rule column has the following value:
>> s2.png contains a screenhost of my form, as well as its source code >> (member.xml). Note that I get a conflict for the "Publisher" group even >> though my global configurations are set to allow the specified actions to >> member of that group. The global configuration (config.xml) as well as my >> access.xml are also attached. s3.png shows my current global configuration.
>> When a user of the group "Publisher" tries to edit the item from >> frontend, the $user->authorise method returns null for all possible >> actions. I have debugged the application and the asset_name matches my item >> ("com_jresearch.member.3" in my example) and everything seems to be in >> order in my understanding.
>> Does anybody have an idea about the cause of the problem? I would really >> appreciate your help since this bug is causing a lot of trouble to my >> users. Thanks in advance!
>> All the best,
>> Luis
>> PD: The rules column of my component asset (id=187) is
Thanks for your prompt response. I am not using the Joomla! categories at
all (at least it is not my intention). Do you see any anomaly in my ACL
files?
> Oh, I see ... questions first, are you using categories? Do you want the
> permissions inherited from the core permissions?
> Elin
> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>> You don't need the middle part of the name .... just have core.edit,
>> core.edit.state. That way the values are inherited from the global
>> configurations and categories. You don't need to specify the asset type,
>> that is already known from the context and asset table (name field).
>> Elin
>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>> Dear Joomla! community:
>>> I am porting my component J!Research to work in Joomla! 2.5 but I have a
>>> small problem regarding the ACL and after a while I have been unable to
>>> solve it. I have some table called #__jresearch_member which includes the
>>> asset_id column. I have checked its records and they seem to match the id
>>> in the #__assets table. The point is that for user besides the super
>>> administrator, the method $user->authorise returns null. File s1.png shows
>>> some records from my assets table. Pay attention to the row with id 189,
>>> its rule column has the following value:
>>> s2.png contains a screenhost of my form, as well as its source code
>>> (member.xml). Note that I get a conflict for the "Publisher" group even
>>> though my global configurations are set to allow the specified actions to
>>> member of that group. The global configuration (config.xml) as well as my
>>> access.xml are also attached. s3.png shows my current global configuration.
>>> When a user of the group "Publisher" tries to edit the item from
>>> frontend, the $user->authorise method returns null for all possible
>>> actions. I have debugged the application and the asset_name matches my item
>>> ("com_jresearch.member.3" in my example) and everything seems to be in
>>> order in my understanding.
>>> Does anybody have an idea about the cause of the problem? I would really
>>> appreciate your help since this bug is causing a lot of trouble to my
>>> users. Thanks in advance!
>>> All the best,
>>> Luis
>>> PD: The rules column of my component asset (id=187) is
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
> Hi Elin:
> Thanks for your prompt response. I am not using the Joomla! categories at > all (at least it is not my intention). Do you see any anomaly in my ACL > files?
>> Oh, I see ... questions first, are you using categories? Do you want the >> permissions inherited from the core permissions?
>> Elin
>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>> You don't need the middle part of the name .... just have core.edit, >>> core.edit.state. That way the values are inherited from the global >>> configurations and categories. You don't need to specify the asset type, >>> that is already known from the context and asset table (name field).
>>> Elin
>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>> Dear Joomla! community:
>>>> I am porting my component J!Research to work in Joomla! 2.5 but I have >>>> a small problem regarding the ACL and after a while I have been unable to >>>> solve it. I have some table called #__jresearch_member which includes the >>>> asset_id column. I have checked its records and they seem to match the id >>>> in the #__assets table. The point is that for user besides the super >>>> administrator, the method $user->authorise returns null. File s1.png shows >>>> some records from my assets table. Pay attention to the row with id 189, >>>> its rule column has the following value:
>>>> s2.png contains a screenhost of my form, as well as its source code >>>> (member.xml). Note that I get a conflict for the "Publisher" group even >>>> though my global configurations are set to allow the specified actions to >>>> member of that group. The global configuration (config.xml) as well as my >>>> access.xml are also attached. s3.png shows my current global configuration.
>>>> When a user of the group "Publisher" tries to edit the item from >>>> frontend, the $user->authorise method returns null for all possible >>>> actions. I have debugged the application and the asset_name matches my item >>>> ("com_jresearch.member.3" in my example) and everything seems to be in >>>> order in my understanding.
>>>> Does anybody have an idea about the cause of the problem? I would >>>> really appreciate your help since this bug is causing a lot of trouble to >>>> my users. Thanks in advance!
>>>> All the best,
>>>> Luis
>>>> PD: The rules column of my component asset (id=187) is
>> To post to this group, send an email to >> joomla-dev-general@googlegroups.com.
>> To unsubscribe from this group, send email to >> joomla-dev-general+unsubscribe@googlegroups.com.
>> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Oh staring right at it ... your publishers are locked because your editors are denied as is everyone else in the branch. Those should be not set rather than denied. You can not over ride an explicit deny.
On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
> Can you post the json strings for authors, editors and registered also > please?
> Elin
> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>> Hi Elin:
>> Thanks for your prompt response. I am not using the Joomla! categories at >> all (at least it is not my intention). Do you see any anomaly in my ACL >> files?
>>> Oh, I see ... questions first, are you using categories? Do you want >>> the permissions inherited from the core permissions?
>>> Elin
>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>> You don't need the middle part of the name .... just have core.edit, >>>> core.edit.state. That way the values are inherited from the global >>>> configurations and categories. You don't need to specify the asset type, >>>> that is already known from the context and asset table (name field).
>>>> Elin
>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>> Dear Joomla! community:
>>>>> I am porting my component J!Research to work in Joomla! 2.5 but I have >>>>> a small problem regarding the ACL and after a while I have been unable to >>>>> solve it. I have some table called #__jresearch_member which includes the >>>>> asset_id column. I have checked its records and they seem to match the id >>>>> in the #__assets table. The point is that for user besides the super >>>>> administrator, the method $user->authorise returns null. File s1.png shows >>>>> some records from my assets table. Pay attention to the row with id 189, >>>>> its rule column has the following value:
>>>>> s2.png contains a screenhost of my form, as well as its source code >>>>> (member.xml). Note that I get a conflict for the "Publisher" group even >>>>> though my global configurations are set to allow the specified actions to >>>>> member of that group. The global configuration (config.xml) as well as my >>>>> access.xml are also attached. s3.png shows my current global configuration.
>>>>> When a user of the group "Publisher" tries to edit the item from >>>>> frontend, the $user->authorise method returns null for all possible >>>>> actions. I have debugged the application and the asset_name matches my item >>>>> ("com_jresearch.member.3" in my example) and everything seems to be in >>>>> order in my understanding.
>>>>> Does anybody have an idea about the cause of the problem? I would >>>>> really appreciate your help since this bug is causing a lot of trouble to >>>>> my users. Thanks in advance!
>>>>> All the best,
>>>>> Luis
>>>>> PD: The rules column of my component asset (id=187) is
>>> To post to this group, send an email to >>> joomla-dev-general@googlegroups.com.
>>> To unsubscribe from this group, send email to >>> joomla-dev-general+unsubscribe@googlegroups.com.
>>> For more options, visit this group at >>> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
I tried with the text you attached me and the rules effectively turned
green in the edition form for the item and now the authorise method returns
true for the mentioned actions, however when I save the item, the explicit
denies are there again! What is the default behavior regarding the content
of the rules column for an asset? Is there any Joomla! standard way to
avoid these explicit denies?
I really appreciate your help. Now I have at least the clue about the cause
of the problem. Thanks a lot!
> Oh staring right at it ... your publishers are locked because your editors
> are denied as is everyone else in the branch. Those should be not set
> rather than denied. You can not over ride an explicit deny.
> Try to avoid explicit denies and only do them once in a branch.
> Elin
> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>> Can you post the json strings for authors, editors and registered also
>> please?
>> Elin
>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>> Hi Elin:
>>> Thanks for your prompt response. I am not using the Joomla! categories
>>> at all (at least it is not my intention). Do you see any anomaly in my ACL
>>> files?
>>>> Oh, I see ... questions first, are you using categories? Do you want
>>>> the permissions inherited from the core permissions?
>>>> Elin
>>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>>> You don't need the middle part of the name .... just have core.edit,
>>>>> core.edit.state. That way the values are inherited from the global
>>>>> configurations and categories. You don't need to specify the asset type,
>>>>> that is already known from the context and asset table (name field).
>>>>> Elin
>>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>>> Dear Joomla! community:
>>>>>> I am porting my component J!Research to work in Joomla! 2.5 but I
>>>>>> have a small problem regarding the ACL and after a while I have been unable
>>>>>> to solve it. I have some table called #__jresearch_member which includes
>>>>>> the asset_id column. I have checked its records and they seem to match the
>>>>>> id in the #__assets table. The point is that for user besides the super
>>>>>> administrator, the method $user->authorise returns null. File s1.png shows
>>>>>> some records from my assets table. Pay attention to the row with id 189,
>>>>>> its rule column has the following value:
>>>>>> s2.png contains a screenhost of my form, as well as its source code
>>>>>> (member.xml). Note that I get a conflict for the "Publisher" group even
>>>>>> though my global configurations are set to allow the specified actions to
>>>>>> member of that group. The global configuration (config.xml) as well as my
>>>>>> access.xml are also attached. s3.png shows my current global configuration.
>>>>>> When a user of the group "Publisher" tries to edit the item from
>>>>>> frontend, the $user->authorise method returns null for all possible
>>>>>> actions. I have debugged the application and the asset_name matches my item
>>>>>> ("com_jresearch.member.3" in my example) and everything seems to be in
>>>>>> order in my understanding.
>>>>>> Does anybody have an idea about the cause of the problem? I would
>>>>>> really appreciate your help since this bug is causing a lot of trouble to
>>>>>> my users. Thanks in advance!
>>>>>> All the best,
>>>>>> Luis
>>>>>> PD: The rules column of my component asset (id=187) is
>>>> To post to this group, send an email to joomla-dev-general@**
>>>> googlegroups.com <joomla-dev-general@googlegroups.com>.
>>>> To unsubscribe from this group, send email to joomla-dev-general+**
>>>> unsubscribe@googlegroups.com<joomla-dev-general%2Bunsubscribe@googlegroups. com>
>>>> .
>>>> For more options, visit this group at http://groups.google.com/** >>>> group/joomla-dev-general?hl=**en-GB<http://groups.google.com/group/joomla-dev-general?hl=en-GB>
>>>> .
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Notice that parent column in your asset table. Everything has a parent of 1! You have totally different action names than global config (asset 1). That means that no inheritance from the component is going on at all. The asset name is being created correctly so all is good there, the problem is in how the parent is set.
As a short term solution, what I would do is to add a category for each of your sections and force all of your records into that (that means adding a category field to each table but you can use a hidden field if you don't want to use categories). We know that working through the category system works. However do not attempt to make dot separated groups of categories I can tell you from experience that you will end up with the same problem of parenting to 1. Just make a master category for each type.
I think that the way the CMS has implemented ACL you really either need to buy into the categories structure or you need to completely set the asset record each time at the item level. In your case that is what is happening and everything is defaulting to denied on the first save. You could give up the dot separated action names and let each record inherit defaults from the global configuration.
I tend to think/remember looking back that the total reliance on the categories was something of a workaround to this issue.
I think alternatively you could change your tables to save with the correct parent asset. Here's the query the category table uses to find the correct parent for the asset table, in your case you already know the name of the extension.
https://github.com/joomla/joomla-platform/blob/staging/libraries/lega...
On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
> Hi Elin:
> I tried with the text you attached me and the rules effectively turned > green in the edition form for the item and now the authorise method returns > true for the mentioned actions, however when I save the item, the explicit > denies are there again! What is the default behavior regarding the content > of the rules column for an asset? Is there any Joomla! standard way to > avoid these explicit denies?
> I really appreciate your help. Now I have at least the clue about the > cause of the problem. Thanks a lot!
>> Oh staring right at it ... your publishers are locked because your >> editors are denied as is everyone else in the branch. Those should be not >> set rather than denied. You can not over ride an explicit deny.
>> Try to avoid explicit denies and only do them once in a branch.
>> Elin
>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>> Can you post the json strings for authors, editors and registered also >>> please?
>>> Elin
>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>> Hi Elin:
>>>> Thanks for your prompt response. I am not using the Joomla! categories >>>> at all (at least it is not my intention). Do you see any anomaly in my ACL >>>> files?
>>>>> Oh, I see ... questions first, are you using categories? Do you want >>>>> the permissions inherited from the core permissions?
>>>>> Elin
>>>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>>>> You don't need the middle part of the name .... just have core.edit, >>>>>> core.edit.state. That way the values are inherited from the global >>>>>> configurations and categories. You don't need to specify the asset type, >>>>>> that is already known from the context and asset table (name field).
>>>>>> Elin
>>>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>>>> Dear Joomla! community:
>>>>>>> I am porting my component J!Research to work in Joomla! 2.5 but I >>>>>>> have a small problem regarding the ACL and after a while I have been unable >>>>>>> to solve it. I have some table called #__jresearch_member which includes >>>>>>> the asset_id column. I have checked its records and they seem to match the >>>>>>> id in the #__assets table. The point is that for user besides the super >>>>>>> administrator, the method $user->authorise returns null. File s1.png shows >>>>>>> some records from my assets table. Pay attention to the row with id 189, >>>>>>> its rule column has the following value:
>>>>>>> s2.png contains a screenhost of my form, as well as its source code >>>>>>> (member.xml). Note that I get a conflict for the "Publisher" group even >>>>>>> though my global configurations are set to allow the specified actions to >>>>>>> member of that group. The global configuration (config.xml) as well as my >>>>>>> access.xml are also attached. s3.png shows my current global configuration.
>>>>>>> When a user of the group "Publisher" tries to edit the item from >>>>>>> frontend, the $user->authorise method returns null for all possible >>>>>>> actions. I have debugged the application and the asset_name matches my item >>>>>>> ("com_jresearch.member.3" in my example) and everything seems to be in >>>>>>> order in my understanding.
>>>>>>> Does anybody have an idea about the cause of the problem? I would >>>>>>> really appreciate your help since this bug is causing a lot of trouble to >>>>>>> my users. Thanks in advance!
>>>>>>> All the best,
>>>>>>> Luis
>>>>>>> PD: The rules column of my component asset (id=187) is
>>>>> To post to this group, send an email to joomla-dev-general@**
>>>>> googlegroups.com <joomla-dev-general@googlegroups.com>.
>>>>> To unsubscribe from this group, send email to joomla-dev-general+**
>>>>> unsubscribe@googlegroups.com<joomla-dev-general%2Bunsubscribe@googlegroups. com>
>>>>> .
>>>>> For more options, visit this group at http://groups.google.com/** >>>>> group/joomla-dev-general?hl=**en-GB<http://groups.google.com/group/joomla-dev-general?hl=en-GB>
>>>>> .
>> To post to this group, send an email to >> joomla-dev-general@googlegroups.com.
>> To unsubscribe from this group, send email to >> joomla-dev-general+unsubscribe@googlegroups.com.
>> For more options, visit this group at >> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
Thank you so much for your help. I checked and there was a small bug in my
routine to get the asset parent id and now it is correct for all my assets.
All my items have the component configuration as parent asset. This
actually solves the problem for my users but there is still some issues.
Before trying the categories solution, I tried to save per item rules but
the problem still persists.
On the other hand the asset row corresponding to my item produces this
value *if only if I explicitly say "Allowed" for all actions* like depicted
in the picture s1.png:
As you can see the values are effectively saved, but if I select "Inherit",
the string always ends in "Deny" and the 1s are replaced by 0s. I would
expect to inherit those values from the parent asset (which is correctly
set this time). *Is there anything missing from my side or does the option
"inherit" in the rules control always refer to the category permissions?* I
just wanted to be sure as I might have to make several changes. Thanks in
advance for your guidance!
> Notice that parent column in your asset table. Everything has a parent of
> 1! You have totally different action names than global config (asset 1).
> That means that no inheritance from the component is going on at all. The
> asset name is being created correctly so all is good there, the problem is
> in how the parent is set.
> As a short term solution, what I would do is to add a category for each of
> your sections and force all of your records into that (that means adding a
> category field to each table but you can use a hidden field if you don't
> want to use categories). We know that working through the category system
> works. However do not attempt to make dot separated groups of categories I
> can tell you from experience that you will end up with the same problem of
> parenting to 1. Just make a master category for each type.
> I think that the way the CMS has implemented ACL you really either need to
> buy into the categories structure or you need to completely set the asset
> record each time at the item level. In your case that is what is happening
> and everything is defaulting to denied on the first save. You could give
> up the dot separated action names and let each record inherit defaults from
> the global configuration.
> I tend to think/remember looking back that the total reliance on the
> categories was something of a workaround to this issue.
> I think alternatively you could change your tables to save with the
> correct parent asset.
> Here's the query the category table uses to find the correct parent for
> the asset table, in your case you already know the name of the extension.
> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>> Hi Elin:
>> I tried with the text you attached me and the rules effectively turned
>> green in the edition form for the item and now the authorise method returns
>> true for the mentioned actions, however when I save the item, the explicit
>> denies are there again! What is the default behavior regarding the content
>> of the rules column for an asset? Is there any Joomla! standard way to
>> avoid these explicit denies?
>> I really appreciate your help. Now I have at least the clue about the
>> cause of the problem. Thanks a lot!
>>> Oh staring right at it ... your publishers are locked because your
>>> editors are denied as is everyone else in the branch. Those should be not
>>> set rather than denied. You can not over ride an explicit deny.
>>> Try to avoid explicit denies and only do them once in a branch.
>>> Elin
>>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>>> Can you post the json strings for authors, editors and registered also
>>>> please?
>>>> Elin
>>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>>> Hi Elin:
>>>>> Thanks for your prompt response. I am not using the Joomla! categories
>>>>> at all (at least it is not my intention). Do you see any anomaly in my ACL
>>>>> files?
>>>>>> Oh, I see ... questions first, are you using categories? Do you want
>>>>>> the permissions inherited from the core permissions?
>>>>>> Elin
>>>>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>>>>> You don't need the middle part of the name .... just have core.edit,
>>>>>>> core.edit.state. That way the values are inherited from the global
>>>>>>> configurations and categories. You don't need to specify the asset type,
>>>>>>> that is already known from the context and asset table (name field).
>>>>>>> Elin
>>>>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>>>>> Dear Joomla! community:
>>>>>>>> I am porting my component J!Research to work in Joomla! 2.5 but I
>>>>>>>> have a small problem regarding the ACL and after a while I have been unable
>>>>>>>> to solve it. I have some table called #__jresearch_member which includes
>>>>>>>> the asset_id column. I have checked its records and they seem to match the
>>>>>>>> id in the #__assets table. The point is that for user besides the super
>>>>>>>> administrator, the method $user->authorise returns null. File s1.png shows
>>>>>>>> some records from my assets table. Pay attention to the row with id 189,
>>>>>>>> its rule column has the following value:
>>>>>>>> s2.png contains a screenhost of my form, as well as its source code
>>>>>>>> (member.xml). Note that I get a conflict for the "Publisher" group even
>>>>>>>> though my global configurations are set to allow the specified actions to
>>>>>>>> member of that group. The global configuration (config.xml) as well as my
>>>>>>>> access.xml are also attached. s3.png shows my current global configuration.
>>>>>>>> When a user of the group "Publisher" tries to edit the item from
>>>>>>>> frontend, the $user->authorise method returns null for all possible
>>>>>>>> actions. I have debugged the application and the asset_name matches my item
>>>>>>>> ("com_jresearch.member.3" in my example) and everything seems to be in
>>>>>>>> order in my understanding.
>>>>>>>> Does anybody have an idea about the cause of the problem? I would
>>>>>>>> really appreciate your help since this bug is causing a lot of trouble to
>>>>>>>> my users. Thanks in advance!
>>>>>>>> All the best,
>>>>>>>> Luis
>>>>>>>> PD: The rules column of my component asset (id=187) is
>>>>>> To post to this group, send an email to joomla-dev-general@**
>>>>>> googlegroup**s.com <joomla-dev-general@googlegroups.com>.
>>>>>> To unsubscribe from this group, send email to joomla-dev-general+**
>>>>>> unsubscribe**@googlegroups.com<joomla-dev-general%2Bunsubscribe@googlegroup s.com>
>>>>>> .
>>>>>> For more options, visit this group at http://groups.google.com/** >>>>>> group**/joomla-dev-general?hl=**en-GB<http://groups.google.com/group/joomla-dev-general?hl=en-GB>
>>>>>> .
>>>>> --
>>> You received this message because you are
A question, if I use the categories system, must the parent_id in the
assets columns point to the asset of the parent category? I have tried with
this, but I still have problems with inheritance. Normally inherited rules
show a [] but I keep getting explicit denials when I save my items. Here is
my new access.xml.
> Thank you so much for your help. I checked and there was a small bug in my
> routine to get the asset parent id and now it is correct for all my assets.
> All my items have the component configuration as parent asset. This
> actually solves the problem for my users but there is still some issues.
> Before trying the categories solution, I tried to save per item rules but
> the problem still persists.
> My component asset has this value for the rules:
> On the other hand the asset row corresponding to my item produces this
> value *if only if I explicitly say "Allowed" for all actions* like
> depicted in the picture s1.png:
> As you can see the values are effectively saved, but if I select
> "Inherit", the string always ends in "Deny" and the 1s are replaced by 0s.
> I would expect to inherit those values from the parent asset (which is
> correctly set this time). *Is there anything missing from my side or does
> the option "inherit" in the rules control always refer to the category
> permissions?* I just wanted to be sure as I might have to make several
> changes. Thanks in advance for your guidance!
>> Notice that parent column in your asset table. Everything has a parent of
>> 1! You have totally different action names than global config (asset 1).
>> That means that no inheritance from the component is going on at all. The
>> asset name is being created correctly so all is good there, the problem is
>> in how the parent is set.
>> As a short term solution, what I would do is to add a category for each
>> of your sections and force all of your records into that (that means adding
>> a category field to each table but you can use a hidden field if you don't
>> want to use categories). We know that working through the category system
>> works. However do not attempt to make dot separated groups of categories I
>> can tell you from experience that you will end up with the same problem of
>> parenting to 1. Just make a master category for each type.
>> I think that the way the CMS has implemented ACL you really either need
>> to buy into the categories structure or you need to completely set the
>> asset record each time at the item level. In your case that is what is
>> happening and everything is defaulting to denied on the first save. You
>> could give up the dot separated action names and let each record inherit
>> defaults from the global configuration.
>> I tend to think/remember looking back that the total reliance on the
>> categories was something of a workaround to this issue.
>> I think alternatively you could change your tables to save with the
>> correct parent asset.
>> Here's the query the category table uses to find the correct parent for
>> the asset table, in your case you already know the name of the extension.
>> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>>> Hi Elin:
>>> I tried with the text you attached me and the rules effectively turned
>>> green in the edition form for the item and now the authorise method returns
>>> true for the mentioned actions, however when I save the item, the explicit
>>> denies are there again! What is the default behavior regarding the content
>>> of the rules column for an asset? Is there any Joomla! standard way to
>>> avoid these explicit denies?
>>> I really appreciate your help. Now I have at least the clue about the
>>> cause of the problem. Thanks a lot!
>>>> Oh staring right at it ... your publishers are locked because your
>>>> editors are denied as is everyone else in the branch. Those should be not
>>>> set rather than denied. You can not over ride an explicit deny.
>>>> Try to avoid explicit denies and only do them once in a branch.
>>>> Elin
>>>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>>>> Can you post the json strings for authors, editors and registered also
>>>>> please?
>>>>> Elin
>>>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>>>> Hi Elin:
>>>>>> Thanks for your prompt response. I am not using the Joomla!
>>>>>> categories at all (at least it is not my intention). Do you see any anomaly
>>>>>> in my ACL files?
>>>>>>> Oh, I see ... questions first, are you using categories? Do you
>>>>>>> want the permissions inherited from the core permissions?
>>>>>>> Elin
>>>>>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>>>>>> You don't need the middle part of the name .... just have
>>>>>>>> core.edit, core.edit.state. That way the values are inherited from the
>>>>>>>> global configurations and categories. You don't need to specify the asset
>>>>>>>> type, that is already known from the context and asset table (name field).
>>>>>>>> Elin
>>>>>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>>>>>> Dear Joomla! community:
>>>>>>>>> I am porting my component J!Research to work in Joomla! 2.5 but I
>>>>>>>>> have a small problem regarding the ACL and after a while I have been unable
>>>>>>>>> to solve it. I have some table called #__jresearch_member which includes
>>>>>>>>> the asset_id column. I have checked its records and they seem to match the
>>>>>>>>> id in the #__assets table. The point is that for user besides the super
>>>>>>>>> administrator, the method $user->authorise returns null. File s1.png shows
>>>>>>>>> some records from my assets table. Pay attention to the row with id 189,
>>>>>>>>> its rule column has the following value:
>>>>>>>>> s2.png contains a screenhost of my form, as well as its source
>>>>>>>>> code (member.xml). Note that I get a conflict for the "Publisher" group
>>>>>>>>> even though my global configurations are set to allow the specified actions
>>>>>>>>> to member of that group. The global configuration (config.xml) as well as
>>>>>>>>> my access.xml are also attached. s3.png shows my current global
>>>>>>>>> configuration.
>>>>>>>>> When a user of the group "Publisher" tries to edit the item from
>>>>>>>>> frontend, the $user->authorise method returns null for all possible
>>>>>>>>> actions. I have debugged the application and the asset_name matches my item
>>>>>>>>> ("com_jresearch.member.3" in my example) and everything seems to be in
>>>>>>>>> order in my understanding.
>>>>>>>>> Does anybody have an idea about the cause of the problem? I would
>>>>>>>>> really appreciate your help since this bug is causing a lot of trouble to
>>>>>>>>> my users. Thanks in advance!
>>>>>>>>> All the best,
>>>>>>>>> Luis
>>>>>>>>> PD: The rules column of my component asset (id=187) is
On Tuesday, July 3, 2012 6:35:57 PM UTC-4, Luis Galárraga wrote:
> Hi Elin:
> A question, if I use the categories system, must the parent_id in the > assets columns point to the asset of the parent category? I have tried with > this, but I still have problems with inheritance. Normally inherited rules > show a [] but I keep getting explicit denials when I save my items. Here is > my new access.xml.
>> Thank you so much for your help. I checked and there was a small bug in >> my routine to get the asset parent id and now it is correct for all my >> assets. All my items have the component configuration as parent asset. This >> actually solves the problem for my users but there is still some issues. >> Before trying the categories solution, I tried to save per item rules but >> the problem still persists.
>> My component asset has this value for the rules:
>> On the other hand the asset row corresponding to my item produces this >> value *if only if I explicitly say "Allowed" for all actions* like >> depicted in the picture s1.png:
>> As you can see the values are effectively saved, but if I select >> "Inherit", the string always ends in "Deny" and the 1s are replaced by 0s. >> I would expect to inherit those values from the parent asset (which is >> correctly set this time). *Is there anything missing from my side or >> does the option "inherit" in the rules control always refer to the category >> permissions?* I just wanted to be sure as I might have to make several >> changes. Thanks in advance for your guidance!
>>> Notice that parent column in your asset table. Everything has a parent >>> of 1! You have totally different action names than global config (asset >>> 1). That means that no inheritance from the component is going on at all. >>> The asset name is being created correctly so all is good there, the problem >>> is in how the parent is set.
>>> As a short term solution, what I would do is to add a category for each >>> of your sections and force all of your records into that (that means adding >>> a category field to each table but you can use a hidden field if you don't >>> want to use categories). We know that working through the category system >>> works. However do not attempt to make dot separated groups of categories I >>> can tell you from experience that you will end up with the same problem of >>> parenting to 1. Just make a master category for each type.
>>> I think that the way the CMS has implemented ACL you really either need >>> to buy into the categories structure or you need to completely set the >>> asset record each time at the item level. In your case that is what is >>> happening and everything is defaulting to denied on the first save. You >>> could give up the dot separated action names and let each record inherit >>> defaults from the global configuration.
>>> I tend to think/remember looking back that the total reliance on the >>> categories was something of a workaround to this issue.
>>> I think alternatively you could change your tables to save with the >>> correct parent asset. >>> Here's the query the category table uses to find the correct parent for >>> the asset table, in your case you already know the name of the extension.
>>> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>>>> Hi Elin:
>>>> I tried with the text you attached me and the rules effectively turned >>>> green in the edition form for the item and now the authorise method returns >>>> true for the mentioned actions, however when I save the item, the explicit >>>> denies are there again! What is the default behavior regarding the content >>>> of the rules column for an asset? Is there any Joomla! standard way to >>>> avoid these explicit denies?
>>>> I really appreciate your help. Now I have at least the clue about the >>>> cause of the problem. Thanks a lot!
>>>>> Oh staring right at it ... your publishers are locked because your >>>>> editors are denied as is everyone else in the branch. Those should be not >>>>> set rather than denied. You can not over ride an explicit deny.
>>>>> Try to avoid explicit denies and only do them once in a branch.
>>>>> Elin
>>>>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>>>>> Can you post the json strings for authors, editors and registered >>>>>> also please?
>>>>>> Elin
>>>>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>>>>> Hi Elin:
>>>>>>> Thanks for your prompt response. I am not using the Joomla! >>>>>>> categories at all (at least it is not my intention). Do you see any anomaly >>>>>>> in my ACL files?
>>>>>>>> Oh, I see ... questions first, are you using categories? Do you >>>>>>>> want the permissions inherited from the core permissions?
>>>>>>>> Elin
>>>>>>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>>>>>>> You don't need the middle part of the name .... just have >>>>>>>>> core.edit, core.edit.state. That way the values are inherited from the >>>>>>>>> global configurations and categories. You don't need to specify the asset >>>>>>>>> type, that is already known from the context and asset table (name field).
>>>>>>>>> Elin
>>>>>>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>>>>>>> Dear Joomla! community:
>>>>>>>>>> I am porting my component J!Research to work in Joomla! 2.5 but I >>>>>>>>>> have a small problem regarding the ACL and after a while I have been unable >>>>>>>>>> to solve it. I have some table called #__jresearch_member which includes >>>>>>>>>> the asset_id column. I have checked its records and they seem to match the >>>>>>>>>> id in the #__assets table. The point is that for user besides the super >>>>>>>>>> administrator, the method $user->authorise returns null. File s1.png shows >>>>>>>>>> some records from my assets table. Pay attention to the row with id 189, >>>>>>>>>> its rule column has the following value:
>>>>>>>>>> s2.png contains a screenhost of my form, as well as its source >>>>>>>>>> code (member.xml). Note that I get a conflict for the "Publisher" group >>>>>>>>>> even though my global configurations are set to allow the specified actions >>>>>>>>>> to member of that group. The global configuration (config.xml) as well as >>>>>>>>>> my access.xml are also attached. s3.png shows my current global >>>>>>>>>> configuration.
>>>>>>>>>> When a user of the group "Publisher" tries to edit the item from >>>>>>>>>> frontend, the $user->authorise method returns null for all possible >>>>>>>>>> actions. I have debugged the application and the asset_name matches my item >>>>>>>>>> ("com_jresearch.member.3" in my example) and everything seems to be in >>>>>>>>>> order in my understanding.
>>>>>>>>>> Does anybody have an idea about the cause of the problem? I would >>>>>>>>>> really appreciate your help since this bug is causing a lot of trouble to >>>>>>>>>> my users. Thanks in advance!
>>>>>>>>>> All the best,
>>>>>>>>>> Luis
>>>>>>>>>> PD: The rules column of my component asset (id=187) is
You can make the path installer point directly to your working copy and
install the component. I have restored the code to its initial state so I
am not using the categories system anymore. On the other hand, the bug in
the function to retrieve the parent asset is solved. Just a couple of
things:
- All my tables inherit from JResearchTable which inherits from JTable
- Since this is just in progress, most of the types do not work, so try
creating items on the Staff section.
I hope you can help me. Really thanks for your support!!!
> Do you want there to be separate defaults for each type or do you want all
> types to use the component defaults?
> Would you want to send me a zip of the component or can I get a copy from
> github or svn?
> Elin
> On Tuesday, July 3, 2012 6:35:57 PM UTC-4, Luis Galárraga wrote:
>> Hi Elin:
>> A question, if I use the categories system, must the parent_id in the
>> assets columns point to the asset of the parent category? I have tried with
>> this, but I still have problems with inheritance. Normally inherited rules
>> show a [] but I keep getting explicit denials when I save my items. Here is
>> my new access.xml.
>>> Thank you so much for your help. I checked and there was a small bug in
>>> my routine to get the asset parent id and now it is correct for all my
>>> assets. All my items have the component configuration as parent asset. This
>>> actually solves the problem for my users but there is still some issues.
>>> Before trying the categories solution, I tried to save per item rules but
>>> the problem still persists.
>>> My component asset has this value for the rules:
>>> On the other hand the asset row corresponding to my item produces this
>>> value *if only if I explicitly say "Allowed" for all actions* like
>>> depicted in the picture s1.png:
>>> As you can see the values are effectively saved, but if I select
>>> "Inherit", the string always ends in "Deny" and the 1s are replaced by 0s.
>>> I would expect to inherit those values from the parent asset (which is
>>> correctly set this time). *Is there anything missing from my side or
>>> does the option "inherit" in the rules control always refer to the category
>>> permissions?* I just wanted to be sure as I might have to make several
>>> changes. Thanks in advance for your guidance!
>>>> Notice that parent column in your asset table. Everything has a parent
>>>> of 1! You have totally different action names than global config (asset
>>>> 1). That means that no inheritance from the component is going on at all.
>>>> The asset name is being created correctly so all is good there, the problem
>>>> is in how the parent is set.
>>>> As a short term solution, what I would do is to add a category for each
>>>> of your sections and force all of your records into that (that means adding
>>>> a category field to each table but you can use a hidden field if you don't
>>>> want to use categories). We know that working through the category system
>>>> works. However do not attempt to make dot separated groups of categories I
>>>> can tell you from experience that you will end up with the same problem of
>>>> parenting to 1. Just make a master category for each type.
>>>> I think that the way the CMS has implemented ACL you really either need
>>>> to buy into the categories structure or you need to completely set the
>>>> asset record each time at the item level. In your case that is what is
>>>> happening and everything is defaulting to denied on the first save. You
>>>> could give up the dot separated action names and let each record inherit
>>>> defaults from the global configuration.
>>>> I tend to think/remember looking back that the total reliance on the
>>>> categories was something of a workaround to this issue.
>>>> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>>>>> Hi Elin:
>>>>> I tried with the text you attached me and the rules effectively turned
>>>>> green in the edition form for the item and now the authorise method returns
>>>>> true for the mentioned actions, however when I save the item, the explicit
>>>>> denies are there again! What is the default behavior regarding the content
>>>>> of the rules column for an asset? Is there any Joomla! standard way to
>>>>> avoid these explicit denies?
>>>>> I really appreciate your help. Now I have at least the clue about the
>>>>> cause of the problem. Thanks a lot!
>>>>>> Oh staring right at it ... your publishers are locked because your
>>>>>> editors are denied as is everyone else in the branch. Those should be not
>>>>>> set rather than denied. You can not over ride an explicit deny.
>>>>>> Try to avoid explicit denies and only do them once in a branch.
>>>>>> Elin
>>>>>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>>>>>> Can you post the json strings for authors, editors and registered
>>>>>>> also please?
>>>>>>> Elin
>>>>>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>>>>>> Hi Elin:
>>>>>>>> Thanks for your prompt response. I am not using the Joomla!
>>>>>>>> categories at all (at least it is not my intention). Do you see any anomaly
>>>>>>>> in my ACL files?
>>>>>>>>> Oh, I see ... questions first, are you using categories? Do you
>>>>>>>>> want the permissions inherited from the core permissions?
>>>>>>>>> Elin
>>>>>>>>> On Tuesday, June 26, 2012 6:55:14 AM UTC-4, elin wrote:
>>>>>>>>>> You don't need the middle part of the name .... just have
>>>>>>>>>> core.edit, core.edit.state. That way the values are inherited from the
>>>>>>>>>> global configurations and categories. You don't need to specify the asset
>>>>>>>>>> type, that is already known from the context and asset table (name field).
>>>>>>>>>> Elin
>>>>>>>>>> On Monday, June 25, 2012 6:57:47 PM UTC-4, Luis Galárraga wrote:
>>>>>>>>>>> Dear Joomla! community:
>>>>>>>>>>> I am porting my component J!Research to work in Joomla! 2.5 but
>>>>>>>>>>> I have a small problem regarding the ACL and after a while I have been
>>>>>>>>>>> unable to solve it. I have some table called #__jresearch_member which
>>>>>>>>>>> includes the asset_id column. I have checked its records and they seem to
>>>>>>>>>>> match the id in the #__assets table. The point is that for user besides the
>>>>>>>>>>> super administrator, the method $user->authorise returns null. File s1.png
>>>>>>>>>>> shows some records from my assets table. Pay attention to the row with id
>>>>>>>>>>> 189, its rule column has the following value:
>>>>>>>>>>> s2.png contains a screenhost of my form, as well as its source
>>>>>>>>>>> code (member.xml). Note that I get a conflict for the "Publisher" group
>>>>>>>>>>> even though my global configurations are set to allow the specified actions
>>>>>>>>>>> to member of that
So a couple of points.
First you probably want to look more carefully at JTableContent as a model for your tables. However, in doing so you will want to notice this:
the _getParentAsset function. You want to set the parent asset you want there. Most likely it will be either com_research or some thing like com_research.staff if you want there to be separate default permissions for each type.
So if you really want to independently make default configurations for each type you need to set up some way to be able to do that. So that means you need a table something like #__research_types that will hold a record for each of your asset types enabling you to have a view which will let you set the permissions via a rules field. Each type would then have an asset in the asset table that would be something like com_research.type.x where x is the id for the type. The model for types would then parent the type to com_research (also like in JTableContent _getParentAsset()). Then your individual assets like staff would be parented to the type.
Also as I mentioned before, you should just have core.create, core.edit etc if you want to be able to inherit from core.create, core.edit etc going up the asset tree. if the action names do not match exactly there can be no inheritance.
> You can make the path installer point directly to your working copy and > install the component. I have restored the code to its initial state so I > am not using the categories system anymore. On the other hand, the bug in > the function to retrieve the parent asset is solved. Just a couple of > things:
> - All my tables inherit from JResearchTable which inherits from JTable
> - Since this is just in progress, most of the types do not work, so try > creating items on the Staff section.
> I hope you can help me. Really thanks for your support!!!
>> Do you want there to be separate defaults for each type or do you want >> all types to use the component defaults?
>> Would you want to send me a zip of the component or can I get a copy from >> github or svn?
>> Elin
>> On Tuesday, July 3, 2012 6:35:57 PM UTC-4, Luis Galárraga wrote:
>>> Hi Elin:
>>> A question, if I use the categories system, must the parent_id in the >>> assets columns point to the asset of the parent category? I have tried with >>> this, but I still have problems with inheritance. Normally inherited rules >>> show a [] but I keep getting explicit denials when I save my items. Here is >>> my new access.xml.
>>> Luis,
>>> 2012/7/3 Luis Galárraga <shamant...@gmail.com>
>>>> Dear Elin:
>>>> Thank you so much for your help. I checked and there was a small bug in >>>> my routine to get the asset parent id and now it is correct for all my >>>> assets. All my items have the component configuration as parent asset. This >>>> actually solves the problem for my users but there is still some issues. >>>> Before trying the categories solution, I tried to save per item rules but >>>> the problem still persists.
>>>> My component asset has this value for the rules:
>>>> On the other hand the asset row corresponding to my item produces this >>>> value *if only if I explicitly say "Allowed" for all actions* like >>>> depicted in the picture s1.png:
>>>> As you can see the values are effectively saved, but if I select >>>> "Inherit", the string always ends in "Deny" and the 1s are replaced by 0s. >>>> I would expect to inherit those values from the parent asset (which is >>>> correctly set this time). *Is there anything missing from my side or >>>> does the option "inherit" in the rules control always refer to the category >>>> permissions?* I just wanted to be sure as I might have to make several >>>> changes. Thanks in advance for your guidance!
>>>>> Notice that parent column in your asset table. Everything has a parent >>>>> of 1! You have totally different action names than global config (asset >>>>> 1). That means that no inheritance from the component is going on at all. >>>>> The asset name is being created correctly so all is good there, the problem >>>>> is in how the parent is set.
>>>>> As a short term solution, what I would do is to add a category for >>>>> each of your sections and force all of your records into that (that means >>>>> adding a category field to each table but you can use a hidden field if you >>>>> don't want to use categories). We know that working through the category >>>>> system works. However do not attempt to make dot separated groups of >>>>> categories I can tell you from experience that you will end up with the >>>>> same problem of parenting to 1. Just make a master category for each type.
>>>>> I think that the way the CMS has implemented ACL you really either >>>>> need to buy into the categories structure or you need to completely set the >>>>> asset record each time at the item level. In your case that is what is >>>>> happening and everything is defaulting to denied on the first save. You >>>>> could give up the dot separated action names and let each record inherit >>>>> defaults from the global configuration.
>>>>> I tend to think/remember looking back that the total reliance on the >>>>> categories was something of a workaround to this issue.
>>>>> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>>>>>> Hi Elin:
>>>>>> I tried with the text you attached me and the rules effectively >>>>>> turned green in the edition form for the item and now the authorise method >>>>>> returns true for the mentioned actions, however when I save the item, the >>>>>> explicit denies are there again! What is the default behavior regarding the >>>>>> content of the rules column for an asset? Is there any Joomla! standard way >>>>>> to avoid these explicit denies?
>>>>>> I really appreciate your help. Now I have at least the clue about the >>>>>> cause of the problem. Thanks a lot!
>>>>>>> Oh staring right at it ... your publishers are locked because your >>>>>>> editors are denied as is everyone else in the branch. Those should be not >>>>>>> set rather than denied. You can not over ride an explicit deny.
>>>>>>> Try to avoid explicit denies and only do them once in a branch.
>>>>>>> Elin
>>>>>>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>>>>>>> Can you post the json strings for authors, editors and registered >>>>>>>> also please?
>>>>>>>> Elin
>>>>>>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>>>>>>> Hi Elin:
>>>>>>>>> Thanks for your prompt response. I am not using the Joomla! >>>>>>>>> categories at all (at least it is not my intention). Do you see any anomaly >>>>>>>>> in my ACL files?
> So a couple of points.
> First you probably want to look more carefully at JTableContent as a model
> for your tables. However, in doing so you will want to notice this:
> the _getParentAsset function. You want to set the parent asset you want
> there. Most likely it will be either com_research or some thing like
> com_research.staff if you want there to be separate default permissions for
> each type.
> So if you really want to independently make default configurations for
> each type you need to set up some way to be able to do that. So that means
> you need a table something like #__research_types that will hold a record
> for each of your asset types enabling you to have a view which will let you
> set the permissions via a rules field. Each type would then have an asset
> in the asset table that would be something like com_research.type.x where
> x is the id for the type. The model for types would then parent the type to
> com_research (also like in JTableContent _getParentAsset()). Then your
> individual assets like staff would be parented to the type.
> Also as I mentioned before, you should just have core.create, core.edit
> etc if you want to be able to inherit from core.create, core.edit etc going
> up the asset tree. if the action names do not match exactly there can be no
> inheritance.
> Elin
> On Wednesday, July 4, 2012 3:32:38 PM UTC-4, Luis Galárraga wrote:
>> Hi Elin:
>> Do you want there to be separate defaults for each type or do you want
>>> all types to use the component defaults?
>> Yes, as you will see my access.xml tries to do that.
>> Would you want to send me a zip of the component or can I get a copy from
>>> github or svn?
>> I have updated the repository so you can download the latest version with:
>> You can make the path installer point directly to your working copy and
>> install the component. I have restored the code to its initial state so I
>> am not using the categories system anymore. On the other hand, the bug in
>> the function to retrieve the parent asset is solved. Just a couple of
>> things:
>> - All my tables inherit from JResearchTable which inherits from JTable
>> - Since this is just in progress, most of the types do not work, so try
>> creating items on the Staff section.
>> I hope you can help me. Really thanks for your support!!!
>>> Do you want there to be separate defaults for each type or do you want
>>> all types to use the component defaults?
>>> Would you want to send me a zip of the component or can I get a copy
>>> from github or svn?
>>> Elin
>>> On Tuesday, July 3, 2012 6:35:57 PM UTC-4, Luis Galárraga wrote:
>>>> Hi Elin:
>>>> A question, if I use the categories system, must the parent_id in the
>>>> assets columns point to the asset of the parent category? I have tried with
>>>> this, but I still have problems with inheritance. Normally inherited rules
>>>> show a [] but I keep getting explicit denials when I save my items. Here is
>>>> my new access.xml.
>>>> Luis,
>>>> 2012/7/3 Luis Galárraga <shamant...@gmail.com>
>>>>> Dear Elin:
>>>>> Thank you so much for your help. I checked and there was a small bug
>>>>> in my routine to get the asset parent id and now it is correct for all my
>>>>> assets. All my items have the component configuration as parent asset. This
>>>>> actually solves the problem for my users but there is still some issues.
>>>>> Before trying the categories solution, I tried to save per item rules but
>>>>> the problem still persists.
>>>>> My component asset has this value for the rules:
>>>>> On the other hand the asset row corresponding to my item produces this
>>>>> value *if only if I explicitly say "Allowed" for all actions* like
>>>>> depicted in the picture s1.png:
>>>>> As you can see the values are effectively saved, but if I select
>>>>> "Inherit", the string always ends in "Deny" and the 1s are replaced by 0s.
>>>>> I would expect to inherit those values from the parent asset (which is
>>>>> correctly set this time). *Is there anything missing from my side or
>>>>> does the option "inherit" in the rules control always refer to the category
>>>>> permissions?* I just wanted to be sure as I might have to make
>>>>> several changes. Thanks in advance for your guidance!
>>>>>> Notice that parent column in your asset table. Everything has a
>>>>>> parent of 1! You have totally different action names than global config
>>>>>> (asset 1). That means that no inheritance from the component is going on at
>>>>>> all. The asset name is being created correctly so all is good there, the
>>>>>> problem is in how the parent is set.
>>>>>> As a short term solution, what I would do is to add a category for
>>>>>> each of your sections and force all of your records into that (that means
>>>>>> adding a category field to each table but you can use a hidden field if you
>>>>>> don't want to use categories). We know that working through the category
>>>>>> system works. However do not attempt to make dot separated groups of
>>>>>> categories I can tell you from experience that you will end up with the
>>>>>> same problem of parenting to 1. Just make a master category for each type.
>>>>>> I think that the way the CMS has implemented ACL you really either
>>>>>> need to buy into the categories structure or you need to completely set the
>>>>>> asset record each time at the item level. In your case that is what is
>>>>>> happening and everything is defaulting to denied on the first save. You
>>>>>> could give up the dot separated action names and let each record inherit
>>>>>> defaults from the global configuration.
>>>>>> I tend to think/remember looking back that the total reliance on the
>>>>>> categories was something of a workaround to this issue.
>>>>>> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>>>>>>> Hi Elin:
>>>>>>> I tried with the text you attached me and the rules effectively
>>>>>>> turned green in the edition form for the item and now the authorise method
>>>>>>> returns true for the mentioned actions, however when I save the item, the
>>>>>>> explicit denies are there again! What is the default behavior regarding the
>>>>>>> content of the rules column for an asset? Is there any Joomla! standard way
>>>>>>> to avoid these explicit denies?
>>>>>>> I really appreciate your help. Now I have at least the clue about
>>>>>>> the cause of the problem. Thanks a lot!
>>>>>>>> Oh staring right at it ... your publishers are locked because your
>>>>>>>> editors are denied as is everyone else in the branch. Those should be not
>>>>>>>> set rather than denied. You can not over ride an explicit deny.
>>>>>>>> Try to avoid explicit denies and only do them once in a branch.
>>>>>>>> Elin
>>>>>>>> On Tuesday, June 26, 2012 10:25:50 PM UTC-4, elin wrote:
>>>>>>>>> Can you post the json strings for authors, editors and registered
>>>>>>>>> also please?
>>>>>>>>> Elin
>>>>>>>>> On Tuesday, June 26, 2012 6:15:58 PM UTC-4, Luis Galárraga wrote:
>>>>>>>>>> Hi Elin:
>>>>>>>>>> Thanks for your prompt response. I am not using the Joomla!
>>>>>>>>>> categories at all (at least it is not my intention). Do you see any anomaly
>>>>>>>>>> in my ACL files?
>> So a couple of points.
>> First you probably want to look more carefully at JTableContent as a >> model for your tables. However, in doing so you will want to notice this:
>> the _getParentAsset function. You want to set the parent asset you want >> there. Most likely it will be either com_research or some thing like >> com_research.staff if you want there to be separate default permissions for >> each type.
>> So if you really want to independently make default configurations for >> each type you need to set up some way to be able to do that. So that means >> you need a table something like #__research_types that will hold a record >> for each of your asset types enabling you to have a view which will let you >> set the permissions via a rules field. Each type would then have an asset >> in the asset table that would be something like com_research.type.x where >> x is the id for the type. The model for types would then parent the type to >> com_research (also like in JTableContent _getParentAsset()). Then your >> individual assets like staff would be parented to the type.
>> Also as I mentioned before, you should just have core.create, core.edit >> etc if you want to be able to inherit from core.create, core.edit etc going >> up the asset tree. if the action names do not match exactly there can be no >> inheritance.
>> Elin
>> On Wednesday, July 4, 2012 3:32:38 PM UTC-4, Luis Galárraga wrote:
>>> Hi Elin:
>>> Do you want there to be separate defaults for each type or do you want >>>> all types to use the component defaults?
>>> Yes, as you will see my access.xml tries to do that.
>>> Would you want to send me a zip of the component or can I get a copy >>>> from github or svn?
>>> I have updated the repository so you can download the latest version >>> with:
>>> You can make the path installer point directly to your working copy and >>> install the component. I have restored the code to its initial state so I >>> am not using the categories system anymore. On the other hand, the bug in >>> the function to retrieve the parent asset is solved. Just a couple of >>> things:
>>> - All my tables inherit from JResearchTable which inherits from JTable
>>> - Since this is just in progress, most of the types do not work, so try >>> creating items on the Staff section.
>>> I hope you can help me. Really thanks for your support!!!
>>>> Do you want there to be separate defaults for each type or do you want >>>> all types to use the component defaults?
>>>> Would you want to send me a zip of the component or can I get a copy >>>> from github or svn?
>>>> Elin
>>>> On Tuesday, July 3, 2012 6:35:57 PM UTC-4, Luis Galárraga wrote:
>>>>> Hi Elin:
>>>>> A question, if I use the categories system, must the parent_id in the >>>>> assets columns point to the asset of the parent category? I have tried with >>>>> this, but I still have problems with inheritance. Normally inherited rules >>>>> show a [] but I keep getting explicit denials when I save my items. Here is >>>>> my new access.xml.
>>>>> Luis,
>>>>> 2012/7/3 Luis Galárraga <shamant...@gmail.com>
>>>>>> Dear Elin:
>>>>>> Thank you so much for your help. I checked and there was a small bug >>>>>> in my routine to get the asset parent id and now it is correct for all my >>>>>> assets. All my items have the component configuration as parent asset. This >>>>>> actually solves the problem for my users but there is still some issues. >>>>>> Before trying the categories solution, I tried to save per item rules but >>>>>> the problem still persists.
>>>>>> My component asset has this value for the rules:
>>>>>> On the other hand the asset row corresponding to my item produces >>>>>> this value *if only if I explicitly say "Allowed" for all actions*like depicted in the picture s1.png:
>>>>>> As you can see the values are effectively saved, but if I select >>>>>> "Inherit", the string always ends in "Deny" and the 1s are replaced by 0s. >>>>>> I would expect to inherit those values from the parent asset (which is >>>>>> correctly set this time). *Is there anything missing from my side or >>>>>> does the option "inherit" in the rules control always refer to the category >>>>>> permissions?* I just wanted to be sure as I might have to make >>>>>> several changes. Thanks in advance for your guidance!
>>>>>>> Notice that parent column in your asset table. Everything has a >>>>>>> parent of 1! You have totally different action names than global config >>>>>>> (asset 1). That means that no inheritance from the component is going on at >>>>>>> all. The asset name is being created correctly so all is good there, the >>>>>>> problem is in how the parent is set.
>>>>>>> As a short term solution, what I would do is to add a category for >>>>>>> each of your sections and force all of your records into that (that means >>>>>>> adding a category field to each table but you can use a hidden field if you >>>>>>> don't want to use categories). We know that working through the category >>>>>>> system works. However do not attempt to make dot separated groups of >>>>>>> categories I can tell you from experience that you will end up with the >>>>>>> same problem of parenting to 1. Just make a master category for each type.
>>>>>>> I think that the way the CMS has implemented ACL you really either >>>>>>> need to buy into the categories structure or you need to completely set the >>>>>>> asset record each time at the item level. In your case that is what is >>>>>>> happening and everything is defaulting to denied on the first save. You >>>>>>> could give up the dot separated action names and let each record inherit >>>>>>> defaults from the global configuration.
>>>>>>> I tend to think/remember looking back that the total reliance on the >>>>>>> categories was something of a workaround to this issue.
>>>>>>> On Thursday, June 28, 2012 6:28:32 PM UTC-4, Luis Galárraga wrote:
>>>>>>>> Hi Elin:
>>>>>>>> I tried with the text you attached me and the rules effectively >>>>>>>> turned green in the edition form for the item and now the authorise method >>>>>>>> returns true for the mentioned actions, however when I save the item, the >>>>>>>> explicit denies are there again! What is the default behavior regarding the >>>>>>>> content of the rules column for an asset? Is there any Joomla! standard way >>>>>>>> to avoid these explicit denies?
>>>>>>>> I really appreciate your help. Now I have at least the clue about >>>>>>>> the cause of the problem. Thanks a lot!
>>>>>>>>> Oh staring right at it ... your publishers are locked because your >>>>>>>>> editors are denied as is everyone else in the branch. Those should be not >>>>>>>>> set rather than denied. You can not over ride an explicit deny.
@Elin: Sorry for my late reply, I appreciate your help. I will wait for a
definite solution and try again. @Antanas: As I did not manage to inherit
permissions, I have removed per-item access rules for the sake of my latest
release, so that the my users can define only rules over all items. However
I intend to provide this functionality as soon as the problem is solved.
> To post to this group, send an email to
> joomla-dev-general@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-general+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/joomla-dev-general?hl=en-GB.
