Home

Using canCreate(), canEdit(), canDelete() and canPublish() to manage page type permissions

Often you will want to control which users can create, edit, delete and publish certain page types. For example you may only want high level users to be able to create ContactPage page types, or prevent low level users from deleting HomePage page types. This can easily be achieved by adding these functions to the page type model (usually just before getCMSFields()). Then within the function you can define conditionals which decide whether to return true or false.

So let's say you have created the permission code in this snippet. We can now use that permission code and the canCreate() function to decide whether a particular user can create this page type:

This function uses the permission::check() function to check whether the current user is in a group which has a particular permission code assigned to it.

Alternatively you could check the ID of the group the user is in by using Member::currentUser()->inGroup($GroupID) in the if() statement.

This code goes for each of these functions:

canEdit() - If false returned removes editing ability from a particular page type
canDelete()
- If false returned removes the delete buttons from the page.
canCreate() - If false returned removes from the page type dropdown.
canPublish() - If false returned removes the publish button from the page.

Combining these functions gives you a powerful way to control your site permissions and when used alongside the CMS access permissions you have complete control over your sites security structure.

About the Author

Name: Aram Balakjian

Website: http://www.aabweb.co.uk

Aram is a web designer/developer running London based agency aab web. He has a strong passion for developing attractive, usable sites around the SilverStripe CMS.

Comments (8)

  • hi,
    great code!somebody actually told me about this on SS irc.
    I got a question.
    how to add those functions (canCreate,Edit,Delete..) to Blogholder.php and Blogentry.php ? I dont want to edit the files in /blog/code/ but create some kind of decorator in mysite/code ?

    thanx for hints.
    Qlex

    Posted by Qlex, 13/10/2009 5:08am (10 months ago)

  • Good job,I like this info.thanks for your work!
    So useful information,I like it.
    Nice,great info...thanks for blog

    Posted by jiudian, 13/08/2009 3:41am (12 months ago)

  • Good recipe! :) As a side-note, its best practice to pass an optional member argument to all can*() methods, and fall back to Member::currentUser(). This makes the method easier to unit test without actually logging in the member.

    Posted by Ingo, 19/07/2009 4:26pm (1 year ago)

  • @adam: As we discovered this was due to having a space in the group name. In this case using the group ID instead fixed the problem.

    Posted by Aram, 08/07/2009 5:37am (1 year ago)

  • It is very helpful for me too

    Posted by Kate, 08/07/2009 1:42am (1 year ago)

  • How does this work if I want to limit a certain Group to create/edit/delete/publish a single page type?

    I have tried locking them out of the standard page class, then readmitting them on the sub class but it seems like the page class permissions take precident and the sub class permissions are ignored...

    Posted by Adam, 07/07/2009 11:17am (1 year ago)

  • i'm still learning

    Posted by jimmy, 25/06/2009 9:11pm (1 year ago)

  • You can also check against a group name if you don't know (or can't be bothered to find out) the id: Member::currentUser()->inGroup("SomeGroupName");

    Posted by Pete Bacon Darwin, 23/06/2009 12:37pm (1 year ago)

RSS feed for comments on this page RSS feed for all comments

Post your comment