After having struggled through the permissions for several days now, I have concluded that they need an overhaul.
Ideally they should be integrated with blocks.
When a block is created, it should be able to be assigned to a user type.
Also for each block there should be options that do not interfere with eachother.
i.e. it should be possible to assign a block to 'unregistered' while denying that same block to the 'users' and vice versa.
Similarly, a permissions should be assignable to links in a block.
e.g. if a block has 4 links, the users may see all of them while the unregistered may see only 2.
The latter works only in part now. It still shows the disallowed link.
A link or block that has no permissions should not be visible.
This only work sometimes now, other times it doesn't.
(Topic) Categories, should be assigned permissions to.
Right now, that is all or nothing.
Again also a problem with visibility.
I have found a whole set of inconsistencies with Categories.
I has to resort to a regular Menu with Topics to solve the problem.
I sure hope someone will look into this some day.
I am willing to provide more details of my experience if needed, though I am sure that many prople have gone through these frustrations already.
One thing is for sure: The instructions on permissions do not cover the many discrepancies. i.e. the program does not follow the intructions even if we do :)
Websun
Watch
GitHub Core
Show your support for Zikula! Sign up at Github account and watch the Core project!
GitHub Modules
- mesteele101 created topic »ERR (3): E_USER_ERROR: Smarty error: [in pagesvar:pagesitem2en line XXX]…« 01:39 AM
- mesteele101 responded to »Zikula 1.3.3 - Selecting a category in Pages not working« 01:29 AM
- mdee created topic »How to implement returnpage ?« 01:00 AM
- nestormateo responded to »Fillters in Clip« 24. May
- damon responded to »Can the Updated Version Check be Turned Off (Z 1.3)« 24. May
- frw responded to »Bug in the SMTP mail transfer protocol - Port 25 - Zikula 1.2.9« 22. May
- mdee responded to »Short URL questions« 22. May
Zikula Blog
- Anatomy of Open Source Projects on Mar 07
- Continuous Review on Mar 01
- Not Invented Here on Feb 24
- How to Contribute Your Code at Github on Jan 13
- 10 Steps to Coding-Nirvana: Tips for Successful Module Writing on Nov 12
- Submitting Bug Report Tickets That Get Results on Aug 17
- Cozi Tricks #1: Syntax Highlighting on Aug 07
Login
Permissions and blocks need overhaul
-
- Rank: Developer
- Registered: Dec 31, 1969
- Last visit: Jun 01, 2010
- Posts: 6859
websun
After having struggled through the permissions for several days now, I have concluded that they need an overhaul.
I don't think they need so much of an overhaul as 3rd Party developers need to thnk outside the box in their coding. I've considered, in a couple of my modules, adding easy permissions settings in to the init and settings area. Ideally, I think this is where the simplification of permissions needs to come, keeping the current system in place for further fine tuning beyond what is able to be done in the init.
Quote
Similarly, a permissions should be assignable to links in a block.
e.g. if a block has 4 links, the users may see all of them while the unregistered may see only 2.
The latter works only in part now. It still shows the disallowed link.
A link or block that has no permissions should not be visible.
This only work sometimes now, other times it doesn't.
That is not the fault of the permissions system, but of the coding. In my PrayerPost Module, the edit/delete links only show to those with Admin rights to the module, regular users don't see them. Another module that will be released sometime soon, looks at the permissions and entery owner to determin if it should show an edit link. That's because I wrote it that way (and by doing so saved me some extra work by not needing a virtually duplicate function in the admin and user areas.
Quote
The instructions on permissions do not cover the many discrepancies. i.e. the program does not follow the intructions even if we do :)
No amount of work to the core system will solve this, this is all on the developers. Example, at this point, my PrayerPost Module only recognized Read & Admin. Realistically, I should have more flexibility in it, and will once I have time to revisit it. I should have Add, View, Edit & Admin really. View would be able to read it only, add could add thier requests, edit could remove them, and admin can change settings.
Websun[/quote]
--
Home Page | Find on Facebook | Follow on Twitter
-
**unknown user**
- Rank: Registered User
- Registered: Mar 16, 2002
- Last visit: Oct 21, 2009
- Posts: 13
What do you think of combining the permissions with the blocks?
(Is that core or developer?)
If that is done at every level, then the admin can readily select the permissions, without having to redo the thing for every sub-directory or having to move lines up or down.
Once the permissions are setup properly, the hiding of the edit/delete fuctions works well.
The problem is getting there. The manual says one thing reality is another.
e.g. The manual says that you can chainlink permissions. That only works sometimes, but mostly not. So, you end up with repeating the same thing several times.
Websun -
- Rank: Expert
- Registered: Dec 02, 2002
- Last visit: Apr 30, 2010
- Posts: 1474
I agree with Mhal here, the permissions really need to be fine tuned in the modules / blocks themselves. When designing my first module I was astounded by the flexibility in regards to design and permissions fine tuning presented to me. I was equally astounded by the under-utilisation of these features demonstrated by exisitng modules... maybe it's a themer thing, but I always try to do something different with my creations, try and think outside the square... ;)
--
-Lobos
Professional PHP Framework Services: Concept, Development and Deployment -
- Rank: Team Member
- Registered: Mar 18, 2002
- Last visit: Oct 21, 2009
- Posts: 6606
Websun,
The probem with 'combining the permissions with the blocks' is that the permissions system is far more that controlling if a block displays or not. If this is all permissions did then that would be ok. As both Michael and Lobos have said the permissions system, when implemented properly, is a very powerful tool in the right hands.
The difficullty, as is very often the case with powerful tools, is making them simpler to use. There's a balance in there somewhere between usability and flexibility - it's just a matter of finding it.....
-Mark
--
Visit My homepage and Zikula themes. -
- Rank: Legend
- Registered: Dec 11, 2002
- Last visit: Oct 21, 2009
- Posts: 11674
Which manual do you refer to?
--
itbegins.co.uk - Zikula Consulting
birtwistle.me.uk - Personal Blog
Please read the Support Guide -
**unknown user**
- Rank: Registered User
- Registered: Mar 16, 2002
- Last visit: Oct 21, 2009
- Posts: 13
The Official PostNuke Guide (pnGuide)
Simon Birtwistle
pnCorps Leader
PostNuke
pnCorps
Revision 1.01
Copyright © 2004 Simon Birtwistle
http://docs.postnuke.com/index.php?module=Static_Docs&func=view&f=pnguideprint//index.html
Section 4.1.3 and Section 6
Websun
- Moderated by:
- Support
Users on-line
- 0 users
This list is based on users active over the last 60 minutes.
