tt_news permissions · 6 June 2007, 16:24
Also see 1.3.6.1. Controlling editing permissions with assigned categories which details improvements made to tt_news in version 2.5.0.
The subject of how tt_news handles permissions has seemingly become a bit of a long-term project of mine. I’ve been skirting writing a blog post on the matter as I’ve amassed so much information that I struggle to sort it. I initially planned to make a list of things that don’t work when trying to set up a permission system containing tt_news, but the solution I finally did find is so full of quirks that it alone requires exhaustive explanation.
I’ve made a ton of screenshots that will hopefully help elaborate the matter… note that the keyword is ‘hope’.
tt_news version:
- tested on 2.2.24 and 2.4.0
- presumed at least: 2.2.24 through-to 2.4.0
- presumed likely: versions 2.x
Typo3 version:
- tested on 3.8.0 and 4.1.1
- presumed at least: 3.8.0 through-to 4.1.1
- presumed likely: all past and future versions
1
Very important: The extension tt_news must have [useStoragePid] set to true. ?
2
The first thing you need is your pagetree – the structure of the website.
Your individual case will most likely differ from the variant I’ve created on the left. I’ll be elaborating the way to set up tt_news permissions in regards to this structure as it is the structure I encountered and solved my problems with.
What we want to do: We want to enable users to edit news stored in categories – each user is responsible for one or more categories, and may not create or edit news in other categories. The news will appear on the “News” pages. Additionally, we also want to set up the “News Repository” page to display the latest item out of all categories each. If you want the “News Repository” to display the latest item (or more) out of all categories combined, I’m afraid this entire article is of no help to you.
What makes this complicated: Assuming you have tt_news configured not to use the storage page IDs of your pages (as is very sane), regardless of where you store categories, they will be accessible by all back-end users enabled to view the “News categories“ table. In other words, even if you store the category in “Page 2” and set the user’s page tree mount to “Page 1”, they can file news into the category you sought to hide from them. See also: Bug report #5705
In a nutshell: whilst Typo3 lets you create a hierarchic access system with relatively small effort, the categories of tt_news are incompatible with the Typo3 access model.
What follows is the tedious work you have to now do for each and every one of your (groups of) categories. I’m sure you’ll quickly get the gist. The images are less for explanation, and more to ease quick look-up on this page – there’s nothing complicated going on here, it’s just the mass that makes it a little labyrinthine at times.
 |  |  |
| Shortcuts
Just for clarity, this is how I imagine the short-cuts to be set up, and as they had to be set up in the situation that spawned all this research. Having this differently shouldn’t affect this fix. In fact, having this page type – or rather, not having it – shouldn’t affect this fix, either. | News categories
Store your news categories as far up the hierarchy as possible. This way, you’ll have the opportunity to add news to categories that your users can’t edit. In this setup, consider the categories called “Category 1”, “Category 2” and “Category 3” respectively for the pages with the same numbers. | Storage page IDs
For this to work, it’s crucial that the entire tree involved in this fix points to the page containing its category. I’ve included the “Information” pages in this process for completion’s sake, but be advised they can probably be left untouched. The pages storing the categories should default to using themselves as their own storage, but I strongly recommend setting it, lest someone fiddling with the TypoScript of your site can unintentionally break your entire setup with just one line of text. |
Finally…
Where to set up which plug-ins
You should have at least one page containing the tt_news plug-in in SINGLE mode to display your news. In this example, the page is called “Singleview.”
You will want to use the “hidden” nature of Shortcut pages (meaning: their content is never displayed) to store the tt_news plug-in in LATEST mode with its limit set to 1 per category – hence the LATEST icon beside “Page #”. If these pages aren’t shortcuts in your variant, a hidden page parented by them will suffice.
The actual news pages should contain the plug-in in the mode you prefer to display them as. In my case, the plug-in has been set to LIST.
That concludes your page structure.
3
You will want to create a usergroup, using access lists, with the following permissions:
Explicitly allow/deny field values ? — The only thing that you need to grant here are the rights “Insert records“ and “News“, latter which is in the Pagecontent: Plugin: section. Everything else can – and probably should – be denied.
Modules ? — Here you should only give what’s most necessary. The bare minimum is to grant rights to “Web“ and “Web>Page“.
Tables (listing) ? should include “Page“, “Pagecontent“, “News“ and “News category“.
Tables (modify) ? should include only “News“.
Workspace permissions ? should grant access to the variant of the site you want news to be stored in. If you’re giving the users autonomy over the publishing of their news, you should check the box “Edit Live (Online)“. If you would rather review the news before it is put online, enable the group for “Edit Draft (Offline)“. Either way, I would suggest checking only one of the workspaces, lest it’s easy for your users to make a mess out of your organisation.
Your users should all make use of that usergroup. What you want to individualise is the DB Mounts: of your users. These should point to the page that should store the news of the category. If you want to set up filemounts for your user, you can, of course.
I would recommend, especially if you have a lot of pages to set up in this way, that you name your users in accordance to the news categories they’re supposed to edit news of – you’ll need to be able to match usernames to pages in the next step.
4
Crucial for Typo3’s otherwise so dynamic access control is that the user that is supposed to edit a page is also in the page‘s access list. Unfortunately, page access is modelled after the UNIX permission system, granting you only minimal flexibility. Fortunately, that is all we need.
For each “DB mount“ you granted your users in Step 3, you will have to edit the Access in. You only need to do this once per mount, regardless how deep the tree under it is, providing you select the maximum “Set recursively # levels (# pages affected“ in the drop-down that appears under the Permissions checkbox. In my specific setup, no recursion was necessary.
Take good care before you submit the new access list. Are the permissions really what you want to grant? If your page structure is supposed to remain static, you should give the table another review.
5
Finally, the “News Repository“ page itself.
To create the news listing mentioned, add an extension template to the page.
Within, extend your page ‘main content’ element by a CONTENT object. This CONTENT object should request data from tt_content, returning rows where colPos = 0 and the pid is one of those pages containing your single-element LATEST news plug-ins.
In our setup, assuming “Page 1“ to have the uid 4, “Page 2“ to have the uid 5 and “Page 3“ to have the uid 33 for variation, your TypoScript should look something like this.
The conditional statement at the bottom prevents the content of this page to be displayed on child pages, should you have any. I don’t, but I doubt I’ll remember this hack if I ever do create child pages, and it’ll save me the headache of debugging. You will have to declare thisPageId in the constants of the page. this will not work, as it is a keyword that intentionally varies depending on the page it is called from – meaning it would contain the page ID of the calling child page, and always evaluate as false.
Now, your users should be able to login and edit the news.
Known issues
Vanishing trick
Your category-containing pages will have to be owned by the user (__or usergroup__) that is supposed to edit this category’s news, too. Be aware: if it isn’t, your users can add news to the category fine. The only thing that refuses to behave is that if, after creating a piece of news, they attempt to edit it. The category will be gone from the category listing, and will have to be re-added.
Thus, if you have a setup wherein you want to grant several usergroups the rights to a category (which you can do by spreading the users of the usergroups out across several (possibly hidden) pages parented (whether directly or indirectly) by the category-containing page), you will have to inform your users that they will have to re-add the category each time they edit.
Flexibility of the “News Repository”
Regardless how you choose to display the news, you will have to do it per-category. This means you can’t instruct tt_news to collect all news across several categories, sort them, and then display the five first of the sorted result. I also don’t see a way this can be done until Bug #5705 is fixed.
This means that you can’t get “the five latest news out of all combined categories,” but you can get “the five latest news out of all categories, each.” In case the difference isn’t clear: former will return five entries ‘arbitrarily’ assigned to your categories, picked exclusively by date; latter will return the five latest entries out of Category 1, followed by the five latest entries out of Category 2, followed by… (et cetera.)
Managability
There’s really no nicer way to say it… this is only a peg short of a hack. It’s tedious to the extreme and not the nicest way to spend your time with. But providing the flexibility suffices for your needs, it works.
Still, if you know how to improve my musings, please let me know!
— Neike Taika-Tessaro
Comment
| Categories: | bugisms, development, knowledge, typo3 |
|---|---|
| Related: | Apache & PHP: Headache with POST / GET · 10 December 2011, 01:43JavaScript and CSS Block Encoding: Broken by design · 1 September 2010, 13:44Dear Google · 15 April 2010, 15:27mediawiki's Special: Recent Changes bug · 30 November 2009, 14:04Extending phpDocumentor with custom tags · 23 October 2009, 18:36 |
Hi Neike Taika-Tessaro, I know, this is an old article, but for me it was a current problem now! You’ve made a fine solution. But I’m sluggardly and was scrabble about a shorter one :-D
I had the same Problem with Typo3 4.2.6 and tt_news 2.5.2. All Users could see all categories although they didn’t have the rights (thru User- and Groups-admin).
My solution was this: At first: The [useStoragePid] is set to “false”. Now, I’ve made a new Sysfolder where I stored only the categories that should hide for some Users. After that I give this sysfolder thru the modul “access” the rights by example -chiefredactor:all, -everybody:none. Now the chiefredactor can handle the “hidden” categories. That was all. I hope, this solution can help anybody else.
With kind regards,
Angelika
— Angelika · 29 July 2009, 20:51 · #
Yeah, that’s a good solution if you have one chief editor, but that’s really not what the article’s about. :)
The setup I describe is one where the people adding news had to be autonomous to large degree. A chief editor was just not an option.
— Neike Taika-Tessaro · 29 July 2009, 21:24 · #
Yes, you are right, but what I want to say is, that you can manage the visibility of categories for users in general, if the categories are separated in different folders with different rules.
With kind regards,
Angelika
— Angelika · 31 July 2009, 10:17 · #