I have created a custom post type called "User Stories" and set up it up to be hierarchical. User stories can be of 4 types i.e. Epic, Feature, Story or Bug. The relationship between them is as follows:
- An Epic can have many Features
- A Feature can have many Stories
- A Story can have many Bugs
As the only difference between the above 4 types of story is the story type, I have created a custom field within this post type called Story Type, instead of creating separate post type for each of them.
In the front end form, I have created a post_parent field to enable users to select the parent User Story. While this approach allows users to select stories and establish the hierarchical relationship between the User Stories, there is no way to restrict which User Stories the user can link to i.e. the above hierarchy cannot be forced. E.g. The user can set a Bug to be the parent of a Epic, which is not a permitted relationship.
Is there a way to restrict the posts that are displayed in the post_field field? e.g. in my case, if a User chooses a Story Type of Feature then only stories of Epic type must be displayed in the drop down values.
Hi there,
Thank you for contacting us and I'll be happy to assist.
I'm afraid, there is no built-in option to restrict the "post_parent" field's selection to a certain level of the hierarchy from within.
With your current arrangement of hierarchical relationship within a single post type ( i.e. User Stories ), this will require custom programming that makes use of AJAX calls and the "get_posts" function to get posts of only certain level, based on user's selection:
https://codex.wordpress.org/AJAX
https://codex.wordpress.org/Template_Tags/get_posts
The more natural way of setting these relationships would be to use separate post types for each level i.e. Epic, Feature, Story & Bug will all have their own custom post types.
These custom post types will then be linked with the next adjacent level, through one-to-many post-relationships, i.e.:
- a Story will have a one-to-many relationship with Bugs
- a Feature will have a one-to-many relationship with a Story
- an Epic will have a one-to-many relationship with a Feature
We have more details on the topic of post relationships at:
https://toolset.com/documentation/post-relationships/
I hope this helps and please let me know if you need any further assistance around this setup.
regards,
Waqar
Thanks Waqar for the detailed response and recommending best practice for this. The reason for using the same post type is that there is no material difference between each of these Story Types from a data / fields perspective and creating these as separate Post Types would result in quadrupling all the creation and maintenance effort relating to this functionality.
I have however looked at the links you have provided and that would mean complete customisation. I was hoping that you would point me to a suitable filter/action hook that would intercept the call that is already being made by the post_parent implementation. The following shortcode provides me a field that has a search box which is already doing the Ajax call and it would be good if I can intercept it somehow.
[cred_field field="post_parent" class="form-control" output="bootstrap" select_text="--- not set ---"]
Hi,
Thanks for writing back and I apologize if my earlier message wasn't clear.
The customization information, mentioned in my earlier reply, would actually be needed if you'll continue on with the current arrangement of using a single custom post type.
I'm afraid, there is no direct filter/function available to intercept "post_parent" field's list, because segmentation is not the intended use for the child-parent relationships, within the same post type.
My goal is to suggest a solution that requires the minimum amount of customization and maintenance in the longer run, and based on what you've shared, deploying multiple custom post types for storing level information/relationships, seems to be the most efficient way.
This approach will allow visitors to enter information of each post type (relationship level), without any customization needed for the front end CRED form.
Note: I haven't suggested using taxonomies for this segmentation, only because taxonomies can't be connected with each other in a hierarchal relationship, which is your requirement.
I hope this clarifies and please let me know if you have any further questions or concerns around this.
regards,
Waqar
My issue is resolved now. Thanks for the very clear articulation in your responses. Really appreciate it.
