[Resuelto] Site relationship structure.

[Autor]

Mensajes

[Mike]

I am building a directory site/web app for a convention. There will be about 1100 attendees, they will be grouped as delegations for representing a state. The states are grouped into 8 regions.

So, I have a custom post type of Person with name, email address, Facebook and twitter link.

I want to be able to filter them by their state and then the states by region. My initial thought was to create a hierarchical taxonomy for the "Person" custom post type. Something like

Region 1
Alaska
Hawaii
California
Region 2
Washington
Oregon

I also have state coordinators that will need to access the directory but only for the state they have been assigned and regional coordinators that will need to access all states and people in their regions.

Is this the most efficient way to do this. Or would I be better off creating related custom post types? So a Cpt for Person in a one to many with region and region in a one to many with States?

Coordinators will also need to search for a person by name but I don't want them to be able to access someone from another state even if they know the name. Only the people they have access to at the regional or state level.

Any guidance would be greatly appreciated.

[Mike]

After doing some searching and reading while waiting for a response it seems controlling access by taxonomy may prove difficult?

Related posts might be the only way?

[Waqar]

Hi Robert,

Thank you for contacting us and sorry about the delay in the reply.

You're thinking on the right lines and based on the requirements that you've shared, it would be more efficient to use post type relationships, rather than hierarchical taxonomy.

These will be the custom post types:

1. Regions
2. States
3. Persons

The post relationships will look like this:
( ref: https://toolset.com/documentation/post-relationships/ )

1. Regions -> States
Regions will have a one-to-many relationship with states.

2. States -> Persons
States will have a one-to-many relationship with persons.

As a result, when a person will be connected to a state, he/she will be indirectly connected to the related region too.

This structure will make it easier for you to show related posts/content and perform filter based searches through post views.

https://toolset.com/documentation/post-relationships/how-to-display-related-posts-with-toolset/
https://toolset.com/documentation/post-relationships/how-to-display-related-posts-with-toolset/how-to-filter-posts-by-their-ancestors/

For controlling access to these posts, you can use Toolset Access' post group feature:
https://toolset.com/documentation/user-guides/access-control/limiting-read-access-specific-content/

Important: These access rules won't automatically apply to post results in the views, but you can use conditional output blocks, to make sure that only allowed posts appear as results:
https://toolset.com/documentation/user-guides/access-control/using-access-to-hide-certain-posts-from-view-results/

I hope this helps and please let me know if you need any further assistance around this.

regards,
Waqar

[Mike]

Thank you very much. I have started experimenting and will let you know if I run into any problems.

I do have a second situation that is somewhat related.

I would also like to also attach a series of poll votes to each person to gauge their support for "Bob". These votes are gathered in a separate system and hopefully imported via as .csv using WP All Import.

Poll A - who do you prefer:
Bob
John

Poll B - Who do you Prefer:
Bob
Susan

Poll C - What is your favorability rating of Bob:
Favorable
Unfavorable

This one has me a little more perplexed.

[Waqar]

Thanks for writing back.

For this new requirement, you can add some "select" type custom fields in your "Persons" post type for each question:
( ref: https://toolset.com/documentation/user-guides/custom-content/using-custom-fields/#how-to-add-custom-fields-to-content )

Example:

a). Poll A - preference ( options: Bob, John )
b). Poll B - preference ( options: Bob, Susan )
c). Poll C - favorability rating of Bob ( options: Favorable, Unfavorable )

After that, you'll be able to import the external results in these custom fields.

[Mike]

Thank you. I will add that to my todo list.

Will I be able to filter people by their preference? So say I want people that voted for Bob in Poll A and Poll B?

[Waqar]

Yes, since these results will be saved as custom fields, you'll be able to add search filters to show persons, with specific preferences.

Here is a guide on the topic of front-end search filters, when using post views:
https://toolset.com/documentation/user-guides/views/front-page-filters/

Please let me know if you have any follow-up questions and for a new question or concern, you're welcome to start a new ticket.

[Mike]

I am now on the access control portion of my project.

Following the instructions here: https://toolset.com/documentation/user-guides/access-control/using-access-to-hide-certain-posts-from-view-results/

Am I correct in that this needs to be donw in the view editor and cannot be done in the blocks editor using a views block?

Also, how do I enter more than one _wpcf_access_group ID? So for example the post group for Rhode Island only sees Rhode Island and the post Group for California only sees California etc?

[Waqar]

Thanks for the update and sorry about the delay in getting back.

> Am I correct in that this needs to be donw in the view editor and cannot be done in the blocks editor using a views block?

- Not necessarily and you can still design the entire view using the new Blocks editor, but for only the protected content part inside the loop, you can use a "Custom HTML" or a "Fields and Text" block ( in "HTML" mode - screenshot: enlace oculto ).

> Also, how do I enter more than one _wpcf_access_group ID? So for example the post group for Rhode Island only sees Rhode Island and the post Group for California only sees California etc?

- Adding conditional checks for multiple post groups efficiently in this case, you'll need a bit of workaround.

Can you please share temporary admin login details along with the example content that needs to be protected? I'll be in a better to suggest the best way forward accordingly.

Note: Your next reply will be private and please make a complete backup copy, before sharing the access details.

[Waqar]

Hi Mike,

Thank you for waiting, while I performed some tests on my own website, with a similar setup.

To dynamically protect the region and state posts, from the people/users of different states, you can make use of the already deployed relationships, without needing the post groups separately.

Note: Due to the complexity involved in this setup, it would be better to use the classic editor and not the blocks editor.

Here are the steps:

1. First, you'll have to make sure that for every registered user on the website, a "People" post exists on the website, where that user is set as the author of that post.
( ref: https://toolset.com/documentation/post-relationships/how-to-create-custom-searches-and-relationships-for-users/ )

2. Next, you'll need a post view, which can return the ID of the "state" post, which is connected to the current user's "people" post.

You can name this view to something as "View to get current user's state ID" and set it to show "people" post, where the author is the same as the currently logged-in user.

Example screenshot: enlace oculto

In the "Loop Wizard" you'll select "List with separators" format, to avoid the extra characters and empty spaces from the output of this view. Please also check the option "Disable the wrapping DIV around the View", just above the "Output Editor" section.

As only the "state" post's ID connected to the current "people" post is needed, you can adjust the content of the "Loop Editor" section to:

[wpv-layout-start]
	[wpv-items-found]
	<!-- wpv-loop-start -->
		<wpv-loop>
		[wpv-post-id item="@state-person.parent"]
		</wpv-loop>
	<!-- wpv-loop-end -->
	[/wpv-items-found]
	[wpv-no-items-found]0[/wpv-no-items-found]
[wpv-layout-end]

You can read about the "item" attribute's usage from https://toolset.com/documentation/user-guides/views/views-shortcodes/item-attribute/

After that, you can use this new view's output in a conditional check to allow or deny access to a particular state's content.
( ref: https://toolset.com/documentation/user-guides/views/conditional-html-output-in-views/ )

[wpv-conditional if="( '[wpv-view name='view-to-get-current-users-state-id']' eq '[wpv-post-id]' )"] 
You're allowed to view this post!
[/wpv-conditional]
[wpv-conditional if="( '[wpv-view name='view-to-get-current-users-state-id']' ne '[wpv-post-id]' )"] 
You're not allowed to view this post!
[/wpv-conditional]

The above conditional block compares the current state post's ID with the ID returned by the view and if they are the same, it shows the allowed message and if they're different, it shows the not allowed message.

This conditional check can be used in the single post Content Template for the state posts and/or inside the post view or WordPress Archive which lists the state posts.

3. Similarly, for a conditional check for "region" posts, you can create a duplicate of your view from the last step and name it to something as "View to get current user's region ID".

Since this view will need to return the ID of the current user's region post, we'll need a third view nested inside this second view, which will get the ID of the region post connected to the specified state's post.

This third view can be named as "View to get region of a state" and you'll set it to show "Regions" posts, with a query filter for the "Regions States" relationship, related to the post whose ID is specified through the shortcode attribute "wpvrelatedto".

Example screenshot: enlace oculto

Again, in the "Loop Wizard" you'll select "List with separators" format and check the option "Disable the wrapping DIV around the View", just above the "Output Editor" section.

You only need the "region" post's ID from this view and can adjust the content of the "Loop Editor" section to:

[wpv-layout-start]
	[wpv-items-found]
	<!-- wpv-loop-start -->
		<wpv-loop>
		[wpv-post-id]
		</wpv-loop>
	<!-- wpv-loop-end -->
	[/wpv-items-found]
	[wpv-no-items-found]0[/wpv-no-items-found]
[wpv-layout-end]

Next, in your second view "View to get current user's region ID", you can include the shortcode of this third view in the "Loop Editor" section like this:

[wpv-layout-start]
	[wpv-items-found]
	<!-- wpv-loop-start -->
		<wpv-loop> 
		[wpv-view name="view-to-get-region-of-a-state" wpvrelatedto="[wpv-post-id item='@state-person.parent']"]
		</wpv-loop>
	<!-- wpv-loop-end -->
	[/wpv-items-found]
	[wpv-no-items-found]0[/wpv-no-items-found]
[wpv-layout-end]

Please note how "[wpv-post-id item='@state-person.parent']" shortcode is used to pass current person's post ID in the "wpvrelatedto" attribute.

After that, you can use this second view's output in a conditional check to allow or deny access to a particular region's content.

[wpv-conditional if="( '[wpv-view name='view-to-get-current-users-region-id']' eq '[wpv-post-id]' )"] 
You're allowed to view this post!
[/wpv-conditional]
[wpv-conditional if="( '[wpv-view name='view-to-get-current-users-region-id']' ne '[wpv-post-id]' )"] 
You're not allowed to view this post!
[/wpv-conditional]

The above conditional block compares the current region post's ID with the ID returned by the view and if they are the same, it shows the allowed message and if they're different, it shows the not allowed message.

This conditional check can be used in the single post Content Template for the region posts and/or inside the post view or WordPress Archive which lists the region posts.

I hope this helps and please let me know if any point or step is not clear.