07 3103 2894

This is a proposal for me to write a helper back end component for JUGA that will effectively allow the access control over articles to be applied at the section and category level avoiding the need for updating the JUGA site items each time an article is added.

When adding an article - say a blog entry - JUGA requires the addition of at least two and possibly five site items to access it :-

Assume the article ID is 555:

First there is the back end access :-

We need a backend item for

• option=com_content&id=555&view=article

where we let administrators access the article. That is probably it for the back end unless you want special editing rights there.

If only it were as simple for the front end. Here we need to add :-

• option=com_content&id=555&view=article

where we put the groups who can read the article, and

• option=com_content&id=555&task=apply&view=article
• option=com_content&id=555&task=cancel&view=article
• option=com_content&id=555&task=edit&view=article
• option=com_content&id=555&task=save&view=article

where we put the groups who can edit the article on the front end.

On a real site, articles are being added several times daily by a variety of users who will find this a rather big headache. Things will be forgotten. Users will be unhappy.

Its generally the case that the desired settings for these site items can be inferred from the section and category to which the article is being added. For example 'Brochure' section articles would be public, whereas 'Site documentation' articles would be restricted to Staff etc.

I propose writing a JUGA Helper back end component to set up tables with the groups who can do the jobs to the sections and categories as follows :-

groups4sections

• group_id
• section_id
• task [view | edit]

groups4categories

• group_id
• category_id
• task [view | edit]

Have an update_site_items plug in that uses these tables to:

1. Check site variables are declared appropriately.
2. Remove any duplicate site item entries for articles (leave last entered).
3. Reset all site items in the relevant sections to that the groups4sections (and only those groups) have access to each article in the section.
4. Reset the section view so that the relevant groups can view it.
5. Reset all site items in the relevant sections so that the groups4categories (and only those groups) have access to each article in the category (this overwrites groups4sections).
6. Reset the category view so that the relevant groups can view it.

Run the function as a plug in after new content is submitted (and when the above tables are changed).

This will effectively provide support for setting the groups on the basis of the sections and categories at the expense of being able to apply it to individual articles.

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Name

Email

Website

Title

Comment

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Write the displayed characters

Add Comment