Skip Navigation

[Resolved] Restricting access by user roles AND a second user descriptor

This support ticket is created 5 years, 10 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 10:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Kolkata (GMT+05:30)

This topic contains 6 replies, has 2 voices.

Last updated by Greig Neilson 5 years, 10 months ago.

Assisted by: Minesh.

Author
Posts
#1190874

I manage school bus route data for clients in different geographical areas and I want to restrict access based on two criteria:
1. user level (e.g. parent, board member, school bus operator, school administrator)
2. geographical area.

In essence, I want to be able to 'tag' a person associated with a certain geographical area as belonging to that area, and therefore have access only to information from that area.

I understand how to make the first part of this happen by defining new user roles, but how do I achieve the second restriction?

#1190890

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Hello. Thank you for contacting the Toolset support.

Well - I would like to know here, how did you setup the geographical area? Is it custom post type? or taxonomy?

#1190894

I haven't set it up yet, Minesh. I have been playing with Toolset and trying different ideas with different clients (on a Multisite installation).

I now realise that the only sensible way to move forward is to use a single dB for all of my clients, and then restrict access on the basis of location. To be clear, the geographical factor isn't the key here, each client might as easily be a separate company for the purposes of this discussion. The key part is making it so that the users belonging to one of my clients can't view the content belonging to another...

#1190895

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

Have you checked our membership site demo?

More info:
=> https://toolset.com/learn/create-membership-site-wordpress-using-toolset-plugins/

The key part here is how you setup your content/post relationship/ taxonomies and roles. I suggest you should divide your project in small modules and go step y step and check feasibility for each module and setup your content/post-relationship etc..etc...

You can even create a test site on our free test platform discover-wp.com:
=> https://toolset.com/faq/how-and-why-to-create-a-test-site-in-discover-wp/

#1190897
Two clients.jpeg

Hi Minesh, I agree with your comment about the >key part< and this is where I'm seeking your advice.

The core record in the dB is a student. A student lives in one area only and can therefore belong to only one of my clients. My question is how I filter records so that data belonging to Client A cannot be viewed by Client B.

I can't solve this problem using roles as described in the demo, because each client has the same roles (as shown on the attachment).

Is this best achieved by a taxonomy or a user/post relationship? I'm thinking that at the moment a user (e.g. a parent) registers on the site they can identify which Client they belong to. At that point everything they author/edit could be 'tagged' with that Client, perhaps?

I can explain the process for entering data if that helps?

#1190996

Minesh
Supporter

Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)

well - I think post-relationship is a good idea here. What if you create a relationship between student and client.

Then, you can able to display the students belongs to client and clients belongs to the student.

More info:
=> https://toolset.com/documentation/post-relationships/

#1191267

My issue is resolved now. Thank you!