ACL Actions

[elin]

Since we are talking about ACL, but this is a different topic, I
thought I would start this thread about actions.

As I'm sure everyone knows, currently the ACL tables are not really
complete for the core components, even setting aside sample data. In
the assets table there are no entries for com_users views in the
front, nothing for weblink edit, Com_users isn't in the
#__access_sections table and so on.. So I'm sure most people have
been learning about ACL the same way I have: by filling in the missing
data when we create a new database. Given that they are incomplete,
one question I have is about what actions are going to be included in
the core.

Working inductively from the tables, I would say view, edit, publish,
manage are the standard actions for a component. Right now front end
create (which we can only really see via weblinks since content
doesn't have a submit view yet) is handled via view access to the edit
view.

On a practical level, I wonder if is it always or even usually true
that webmasters want those who can edit to be able to create. As a
webmaster, I'd say "no." In some situations you want people to be able
to create but not edit. In others you want people to be able to edit
but not create. So since the actions table and other tables need work
anyway, can we add create as a separate standard action for those
components that have front end creation?

Of course I would also like to seecom_contact.article.publish_own
built in because that's the missing link for most webmasters who want
their users to be able to work on their stuff but not mess with other
people's, but I get that we will probably leave that to 3pds.

Elin

[Amy Stephen]

Good - thank you.

On Sat, Sep 5, 2009 at 10:48 AM, elin <elin....@gmail.com> wrote:

Since we are talking about ACL, but this is a different topic, I
thought I would start this thread about actions.

As I'm sure everyone knows, currently the ACL tables are not really
complete for the core components, even setting aside sample data. In
the assets table there are no entries for com_users views in the
front, nothing for weblink edit, Com_users isn't in the
#__access_sections table and so on..   So I'm sure most people have
been learning about ACL the same way I have: by filling in the missing
data when we create a new database.  Given that they are incomplete,
one question I have is about what actions are going to be included in
the core.

Working inductively from the tables, I would say view, edit, publish,
manage are the standard actions for a component. Right now front end
create (which we can only really see via weblinks since content
doesn't have a submit view yet) is handled via view access to the edit
view.

I would *really* appreciate it if you would read the Word Document I posted that talks about cleaning up the table structures and merging legacy data elements into the new model. I would like your feedback on it, especially given your work with schools and the ACL requirements you have had. Understand, my response to your question assumes that cleanup work.

Recommend 8 Actions:

• Login
  
• View
  
• Create
• Update
• Publish
• Install
• Manage
  
• Uninstall

 

On a practical level, I wonder if  is it always or even usually  true
that webmasters want those who can edit to be able to create.  As a
webmaster, I'd say "no."

 

In some situations you want people to be able
to create but not edit.

Yes, that should be possible by creating a rule that enables the "Create" Action for a Group (and it's associated Users) for the desired Asset (specific Component, or a Category within that Component.)

Then, those in that group could create Web links, or Articles, but not update.

 

In others you want people to be able to edit
but not create.

I would handle that with a Parameter. The parameter would enable or not enable update capability for the Content Creator.

With that in mind, a Web master could create an Article, assign the User as the Article Creator, enable that User Manager Option and the User could edit their content without providing them ability to Create.

Even though it's limiting, I recommend initially that this be implemented as a system-wide option, not per Asset. (No one likes to hear this, including me, but) System plugins could be written to extend that for those who need that complexity. Later, if experience shows that level of sensitivity is desired by many, then we could revisit.

For starters, though, I'd recommend one system-wide parameter for the User Manager that allows Web masters to activate Creator Editor on all Content Objects.

 

[Andrew Eddie]

Whoa, can we keep this in one thread please until we are all on the
same page for what the requirements actually are? See my comment to
the other thread.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/9/6 elin <elin....@gmail.com>:

[Amy Stephen]

Yup, we will. I mentioned starting a new thread for use cases. My mistake.

[elin]

@Andrew, I made this a separate thread so as not to distract from the
type 2 rule topic.

I wonder if there is any feedback on the question, which is a simple
one about adding some rows to the sql file for #__access_actions table
in joomla.sql. Specifically:

com_content.article.create 1
com_weblink.weblink.create 1

I would think these should also be added to joomla.sql :

com_weblink.weblink.edit 2
com_weblink.weblink.edit_weblink 1
com_weblink.weblink.publish 1

com_weblink.weblink.edit_own 1

com_media.upload 2

com_users.profile.edit_own 3
com_users.profile.edit 1
com_users.profile.view 3

com_content.article.publish_own 1

Notes:

Note that the access_type values for weblinks are just following what
is there for com_content. Since weblinks is our model component I
think it should be a complete example.


Com_media.upload was added to 1.5 to allow more finely grained control
of upload because of hte risk of malware in pdfs and other files.
There is also com_media.popup in 1.5 but I think the com_media.upload
actually solves the issue that popup was addressing, so I'd leave that
out I think.

Com_users front end is currently not in the table at all.


For those who have not followed closely, this table takes the ACL
information that was in libraries/joomla/user/authorization.php in 1.5
and puts it into the database.

Of course this can all change later, but, I for one, would just like
to be able to work with an install as it stands right now rather than
having to add all the time since I am lazy.

Elin

On Sep 5, 9:16 pm, Amy Stephen <amystep...@gmail.com> wrote:
> Yup, we will. I mentioned starting a new thread for use cases. My mistake.
>
>
>
> On Sat, Sep 5, 2009 at 6:03 PM, Andrew Eddie <mambob...@gmail.com> wrote:
>
> > Whoa, can we keep this in one thread please until we are all on the
> > same page for what the requirements actually are?  See my comment to
> > the other thread.
>
> > Regards,
> > Andrew Eddie

> >http://www.theartofjoomla.com- the art of becoming a Joomla developer
>
> > 2009/9/6 elin <elin.war...@gmail.com>:

> > > Elin- Hide quoted text -
>
> - Show quoted text -

[Andrew Eddie]

You've actually listed type 2 actions ;)

Just trust me. We need to start from the big-picture and work down
and there will be a bit of to-ing and fro-ing in the process.

Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer




2009/9/8 elin <elin....@gmail.com>: