Applying JUGA to article sections and categories PDF Print E-mail

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.

There is a rough cut of the component here. I'll do some more work on it when time permits. Let me know if its useful or works (its working OK on an embedded site but I haven't had time to test the zip) by commenting here.
Trackback(0)
Comments (8)Add Comment
0
...
written by specialist recruitment agencies brisbane, May 21, 2012
great job.. made things easier.
0
...
written by uss05, January 16, 2013
0
...
written by uss05, January 21, 2013
0
...
written by uss05, January 26, 2013
0
...
written by USS06, January 31, 2013
0
Joe Montana Authentic Jersey
written by uggsas13, February 28, 2013
0
...
written by hongwanxia, March 06, 2013
百度
sina
0
http://www.shoesonlinesaleshop.com
written by jordan shoes, March 09, 2013
I enjoyed this article, and very grateful for you sharing

Write comment

busy
Last Updated on Wednesday, 26 November 2008 18:21
 
Paul Whipp Consulting (BN 207 530 56) is owned by and operated for The Whipp Family Trust (ABN 32 507 522 641).