Thank you very much Christian,
Promotions work well. The problem with bonuses is that they are associated with a user, not a shop. So the relationship I understand should be like that:
add_action( 'rest_api_init', 'create_api_posts_meta_field_bonos');
function create_api_posts_meta_field_bonoa() {
register_rest_field( 'bonos', 'parent-page', array(
'get_callback' => 'get_parent_page_for_api_bonos',
'schema' => null,
)
);
}
function get_parent_page_for_api_bonos( $object ) {
//get the id of the post object array
$post_id = $object['id'];
//return the related usuario post ID
return toolset_get_related_post( $post_id, 'user_bono', 'parent');
}
But... how i could associate an user? Because in user dates doesnt appear this field.
It is not possible to link Users and Posts directly using Toolset's Post Relationships - you can only associate two different post types. There are several other ways to associate Users and posts:
1. You can make the User the author of the post, then query Bonos posts by post author ID as I described before: https://toolset.com/forums/topic/relationship-in-api-rest-2/#post-1847537.
2. You can create a proxy post type for Users: a CPT like "Profiles" or "Members", or something similar. Each User must be the author of only one Profile post (see the guide link below). When Users register, you can require them to create a Profile post with Toolset Forms before they use the site, or you can automatically create the Profile post programmatically using the Forms API. Once the Profile post exists, you can link Profiles and Bonos using post relationships. See this guide for more information about using a proxy post type for Users: https://toolset.com/documentation/legacy-features/views-plugin/how-to-create-custom-searches-and-relationships-for-users/
3. Create a custom field on the Bonos post and store the related User's ID in the field. Then you can query Bonos posts by custom field value using the current User's ID. Note that you cannot use Toolset's post relationship features in this approach.
4. Create a custom field on the User profile and store the related Bonos post ID in the field. Then you can query the usermeta field for the current User to access the Bonos post ID. Note that you cannot use Toolset's post relationship features in this approach.
If you'd like to discuss one of these options in more detail, let me know.
in the case of coupons that are related to a custom type parent demonized campaigns. The user is the one who has to generate those bonuses.
When a campaign is launched, the option must be enabled in the user's profile to be able to generate that bonus (1 to 1 relationship with the user).
This bonus has an expiration date, which must be carried along with the price and title of the bonus in the user's api json.
When a campaign is launched, the option must be enabled in the user's profile to be able to generate that bonus (1 to 1 relationship with the user).
Yes that makes sense. However, as I said before there is no way to directly relate a User to a post using Toolset's post relationships feature, so there is no 1 to 1 relationship between Users and posts in Toolset's post relationships. The only direct, 1 to 1 relationship between Users and posts must defined as the post author ID. To link Users and Bonuses some other way, you may choose option 2, 3, or 4 as I described here: https://toolset.com/forums/topic/relationship-in-api-rest-2/page/2/#post-1849031.
The proxy post type solution (#2) is the most powerful but also the most complex to set up. The custom field approach (#3 or #4) is simpler to set up, but has limited features. For example, you cannot create search queries on the front-end of the site for User profiles using Views. The custom search feature in Views is limited to posts, not taxonomy terms or Users. The Author approach is probably the simplest to set up, but again you cannot set up front-end searches based on the post author. So you must decide which approach works best for your site.
If I choose solution 2, could you help me?
Of course, I have split that into another ticket. If the promociones endpoint is working correctly now, I think we can close here and follow up in the new ticket.
My issue is resolved now. Thank you!