• I have created a CPT for Service Providers.

    I have a DB of Service Provider Listings and Users to import initially, but I also want to allow new users to “add a listing” registering themselves and adding a listing (draft for approval)

    I want to link all the existing users to their respective listing so that they only have capability to view and edit their listing in the Dashboard.

    I’m thinking, if this is possible:

    1. When a user registers, I create a Role/Capability (copy subscriber) and call it “Service-Provider-Listing-Name”
    2. Then, in the service provider listing, assign the role to the listing

    Is this logical? Any guidance or direction would be appreciated.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Moderator bcworkz

    (@bcworkz)

    Yes, creating a new role is a good idea. But assigning the role to the listing will not have the effect you desire.

    If a role lacks “edit_others_posts” capability, users in that role will only be able to edit posts they created themselves (assuming they have all the other post related capabilities). The same concept can be applied to CPTs.

    That should take care of newly created listings as far as editing is concerned. As for the imported listings, you could relate listings to a particular user by making the user the author of the listing. Of course this is possible to do manually, listing by listing. But if there are a lot of imported listings it would be very tedious and time consuming to do. The ability to auto-assign authors in bulk depends on what data already exists telling the script who to assign to what.

    Viewing ability is another matter. All posts are generally considered public where anyone can view them. There are of course private posts, but they are private to the role, not individual users. You could however add template code that prevents viewing of content unless the current user is also the author of the listing.

    All users with the role will still be able to see others listing titles, they just cannot see content. If you need to restrict viewing of even titles in back end list tables, the appropriate queries could be modified to only get listings authored by the current user.

    Thread Starter SJW

    (@whitsey)

    @bcworkz Thanks. That makes sense and I have it working now as follows but I don’t think I need to do all this.

    1. When a user registers, I copy the contributor role, rename to username_role and then set_role() to the new role
    2. Contributors can post to my CPT and posts in a status of ‘Pending’ which is perfect – must be reviewed by an admin.
    3. I created a login_redirect filter for non-admin users on login to go straight to the the CPT page with author as filter /wp-admin/edit.php?post_type=service-provider&author=".$user_id – This just shows their CPT post. They can view others posts but cant edit – perfect
    4. For all non-admin users, I added admin_init action if NOT admin, remove_menu_page() – edit.php (posts) and edit-comments.php (comments) so they canno see posts and comments.

    Question: Do I need to copy and set the new role? It is effectively just contributor with another name and the actual CPT filtering is done based on the Author (not the role) anyway?

    Moderator bcworkz

    (@bcworkz)

    Contributor role already lacks edit_others_posts capability. The only reason to copy a role is if you need to alter any of its capabilities. If you’re OK with your CPT and regular posts having the same restrictions and capabilities for contributors, then there’s no need to make a copy.

    If you want different restrictions and capabilities for posts than for your CPT, then you not only need a modified contributor role, but you also need to alter your CPT’s registered capabilities. Then it would be possible to prevent users from creating any posts and they can only create CPT posts. Or the new role could create both, but regular contributors could not create CPT posts. Or… the nuanced possibilities are virtually endless.

    Thread Starter SJW

    (@whitsey)

    Yep. That’s what I was originally trying to do. That makes sense now – but I couldn’t any help or doco which explained how to restrict a capability to a CPT so I used contributor and just blocked post access.

    Probably not ideal. I might keep looking for CPT capability managament

    thanks

    Moderator bcworkz

    (@bcworkz)

    There are a few ways to manage CPT capabilities independently from other post types. Perhaps the simplest is to pass a unique string for the “capability_type” arg supplied to register_post_type(). For example if you passed “listing” as the value, then users would need capabilities such as “edit_listing” in order to edit listing CPTs. The “edit_posts” capability other users might have will not allow them to edit listings, only “edit_listing” will do. Similar for all the other post related capabilities like publish, delete, etc.

    I know there are plugins that help you manage roles and capabilities. And there are plugins to help you create CPTs, but I don’t know how much control they give you over capability management. Of course this can all be managed with custom code for those with the requisite skills.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Creating a user managed services directory with self-editing’ is closed to new replies.