Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In with Google Sign In with OpenID

User Type

edited April 2012 in Apps

I was going through defining some new user levels (I have a need to define 3 different levels of membership), so I can offer a different version of a similar page to each user type.

How many different places is this change necessary for the auth system to work? I played with the users app and added them to the config file in the user_types array, as well as various views that seemed to require it. Am I missing the easy solution here?


  • Okay, figured out the issue. The database is set to enumerated in the webpage 'access' column so I couldn't create any sort of page other than member or public.

    Modifications to the database aside, how would you suggest one goes about adding tiered approaches to pages? A whole new app?

  • Doing a quick search of the codebase, it looks like you would only need to modify these places to change the webpage permissions:

    • conf/install_*.sql (line 8)
    • apps/admin/handlers/page.php (line 40)
    • apps/admin/views/add.html (line 24-25)
    • apps/admin/views/edit.html (line 24-25)

    The same would apply for blocks too:

    • conf/install_*.sql (line 22)
    • apps/block/handlers/index.php (line 40)
    • apps/block/views/add.html (line 18-19)
    • apps/block/views/edit.html (line 18-19)

    I might try doing it a bit differently though if you need more complex permissions. You can create an alternate default_handler in conf/config.php in which you could duplicate the admin/page handler and add additional access control there. See lib/Acl.php which might be of help too.

    I kept permissions very rudimentary so far, but they may be too limited. Perhaps at least making them easier to edit would be a good thing. I'll have to think on that a bit more. Maybe even something as simple as a conf/acl.php file to list them, something like:

    ; <?php /*
    public = all
    member = login
    client = type:client
    private = type:admin
    ; */ ?>

    This could then populate the Access list for pages and blocks, then have a similar setting to edit the user type list as well. Hmm...

  • edited April 2012

    I just know it was mildly frustrating having what appeared to be an easy config setting and have it not do anything.

     user_types = "admin, member"

    apps/user/conf/config.php (line 12)

    The conf/acl.php seems like a decent plan. I'll have to play with it later. I've spent some time adding additional Facebook and Twitter plugins to the social app.

  • That setting should definitely update the user forms. I'll fix that asap.

    For access control, I'm thinking an [Access] section in apps/user/conf/config.php might be better than a separate file, to keep it close to the user_types setting, then adding a User::access() method to make it easy to integrate anywhere it might be needed. That could reduce access checking code to:

    if (! User::access ($page->access)) {
        // not allowed
    // proceed

    I'd like to keep away from a full-scale ACL list with too fine-grained control if possible. In practice, I've always found them to be cumbersome and hard for non-technical users to wrap their heads around. But I think a simple access list setting done right could be sufficient for most needs.

  • Just tried this out for the past hour and I think it works pretty well. Just checked it into the master branch on Github.

    The page and block access fields are now populated with the values from the user conf/config.php's [Access] section and the user type field is now populated from the user_types list as well. The page and block handlers are using the User::access() method for verifying permissions too, so splitting content between user groups should be doable now.

    Let me know what you think once you've had a chance to try it out :)

  • I'll check it out here in a bit. Did you check your inbox? I sent a message, haven't got a reply.

  • Just saw it and replied :) Forgot to check email all day...

  • edited May 2012

    Just curious on this implementation after looking at it. Does it support comma-seperated listing or no?

    public = all
    member = login
    private = admin
    dealer_1 = dealer_1
    dealer_2 = dealer_2
    dealer_3 = dealer_3

    That obviously works.

    public = all
    member = login
    private = admin
    dealer_1 = dealer_1, dealer_2, dealer_3
    dealer_2 = dealer_2, dealer_3 
    dealer_3 = dealer_3

    What about that? If not would the alternative be a work around.

    dealer_1 = dealer_1
    dealer_1 = dealer_2
    dealer_1 = dealer_3
  • Right now it doesn't, but I've been thinking the permissions are going to need further changes. I'm taking off for the day now but I'll try to play around with this later tonight.

Sign In or Register to comment.