Fork me on GitHub

Permissions and blocks need overhaul  Bottom

  • 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
  • ...some day?

    Most everyone here has already felt the same frustration. Of course, if we're just making a list of what we want to change in the core to improve usability...
  • 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
  • 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
  • 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
  • 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.
  • Thanks! I am beginning to understand it :)
    Probably the simplest would be to update the manual.

    Cheers!

    Websun
  • 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
  • 0 users

This list is based on users active over the last 60 minutes.