This is not working for me in neither my dev site or in the Cook sandbox. I am using v2.0 beta of Cook, jquery,condensed,table model. Here is what I did:

1. Add author wizard.
2. Add publish wizard. Set default to 0.
3. Add Access wizard. Set default to 2. (Registered users)
4. Open options. Set ACL for registered users to view.own and edit.own.



Does not work.

The registered user cannot see their own record. If I changed the published state to "1" and create a new record, well all of the users can now see the record. But even though the user owns the record, the user cannot edit the record as defined in the ACL.

Yeah so ... the only way to make it work is to make every user an Author. Hmm ...

Or edit the Registered Viewing Access Level and check the Author box.

Let me look at the most efficient way to do this and I will post a guide.

Surely, if the view access is set to the same group as the creators, then no matter what, anyone in that group is going to see any published records right?

I would try your suggestion of increasing the view access to editor. If that doesn't work, try removing the access field.

If all else fails, for the time being I'd adapt your model by adding a WHERE author = $user->id .

Sorry, I've got no time to look into this for the moment. Look forward to reading your findings.

@admin - is there a problem here OR something I'm missing...?

Good luck,

Gez

There is no problem as this is how Joomla 2.5 is designed. The default Viewing Access Level does not include Author in Joomla 2.5.

So, this problem can easily be overcome by opening the Registered Viewing Access Level and checking the Author box.

However, there are two issues with this:

1. I'm not positive what security issues this may cause. I am going to have to dig into the ACL documentation and post my conclusion.

2. If you are distributing your component to the public, having someone modify their ACL's to make the component work isn't exactly normal. I will have to look to see if this can be automated.

My preferred method would be to add an additional group with a name related to the component during install. This group would then be given the correct settings for that component only. Again, I have to research this to find the best solution. I'll post a tutorial once I figure out the best and most secure way to do this.

Given that in J2.5 the ACL has been opened up for admin customisation - I mean, adding new groups/levels - this behaviour is exactly normal. When a site admin utilises a component, surely they expect to be able to customise which of their user groups/levels have access to do what in their component?

Am I missing something?

BTW, are you and @gdpodesta one in the same user or working on the same project together? I just noticed in your screenshot that you're both working on a licensing component...

Best,

Gez

Mine is for managing and distributing Source Guardian licenses. His is for music it seems. I don't know him.

Ah, OK - sorry, just a coincidence!

OK, been doing a little testing here on a new dummy project and mostly it's working as expected.

3 frontend layouts - Tracks (List), Track (Item) & Edit Track (form)

Registered Users

1. Can't see any unpublished tracks in list (Tracks) - empty list if all unpublished
2. Can't add tracks (or edit, delete etc.) - get 500 error - not authorised to view this resource

However, they CAN see individual tracks by adding "&id=1" to the URL

Here's the details...

N.B. I've not added an access field yet

Cook V2.0 - Config (top to bottom) jQuery, Condensed, Maximum, No, Model, 20 secs

Setup
1 table - tracks
6 Fields - id, title, alias, created_by, modified_by, published

Component Config





@jcbenton + @gdpodesta - Is this the behaviour you're experiencing???

Hope this helps!

Gez

Hey

If I may also jump in

I already posted in another thread

I have a component written around a table FOO
This table can be maintained by the admin via the admin part of the component, no issues there

2 user groups will use this table FOO

1. A user in the default 'Registered' group, he must be allowed from the front end to create and update his own records in FOO. And he should not see any other records (of other user in the Registered group)

2. A user in the 'FOO Admin' group, that user can see & modify all records in FOO (of all users) from the frontend

So I implemented the table FOO with the published and Author wizards & fields. I can see in the source code that indeed the model for the front-end view has the functionality embedded to handle what I want by using the ACL system and checked for the properties like core.edit.own etc

Via the options in the component installation/setting I defined that the 'FOO Admin' group core.edit, core.delete and core.create and the Registered group has only the 'own' rights, The rest of the groups have no rights

When I then look at the frontend by using a user which is in the Registered group I can see the list/grid for FOO but without the create, edit or delete functionality (buttons are not there) and also I do not see the rows I previously entered when that user was still a super_user.

I saw a post which gave the hint to add a print_r of the $acl for debugging purposes in the prepareQuery which I did :

(
[_errors:protected] => Array
(
)

[core.admin] =>
[core.manage] =>
[core.create] =>
[core.edit] =>
[core.edit.state] =>
[core.edit.own] =>
[core.delete] =>
[core.delete.own] =>
)

So this leads for me to the conclusion that the ACL is 'undefined' here, but maybe I am wrong since I am not into the ACL of Joomla.

Because the $acl is empty the frontend is buttonless (new, edit & delete) and rows are not loaded.

Does any of you have an idea what I am missing here?

You can add a user_id to your post or whatever you want users/admins
to delete. then you can use the afterFind to determine if the user can
or can't do actions on that record.

@mark d

Joomla doesn't have an afterFind function. It is a PHP function. Suggestions on how to achieve this in the context of Joomla and COOK have already been made - there's no need to filter the results after find as it can be explicitly be provided in the query as explained in the thread.

@nvgogh 's issue is now to do with the ACL.

Gez

@ audibleid: Yes, that's what I am strugglin with.. I know how to code so I am able to do the debugging in the source code. The user is known (if I do a dump of the logged inuser object it displayes the user with all it's details)
But the JUser->authorise function doesn't return a value for the acl properties (like core.edit.own) it needs to check.

Which is weird. But I am unable to dig any deeper.

I am wondering if maybe the ACL system is corrupt and if the ACL Manager plugin would resolve the issue