[Resolved] Creating Functions for Inventory Management

[Author]

Posts

[Christian Cox]

It most likely will be, because you'll need different filtering mechanisms for Owners and Resellers. For instance, I would assume that your View for Owners will be filtered by post Author (Owners are Authors of their Vessel posts) but your View for Resellers must be filtered by custom field (Owners assign Reseller IDs to each Vessel). Does that make sense?

[jonB-5]

Yep that makes sense, thanks.

Now, I've been thinking about the requirements for reporting and have a question that may influence how things are structured.

I'm assuming the best way to get reports exported would be using something like hidden link, though I wonder if this would be capable of exporting data on Parents, grand-parents, great-grandparents etc. for the CPT being exported.

If it is not possible, I was wondering if the solution (if even possible) would be to copy the required parent data into custom fields in the child posts so that it is included when child posts are exported.

Can you advise on what may be possible and/or recommend any solution?

[Christian Cox]

I'm not really the best source of information about another plugin and what it can or cannot accomplish. However, if you can tell me what data that plugin needs to work with our post types, I will tell you if / how we can provide it.

Regarding your question about copying data, this is possible with some custom code. A child post already contains a reference to its parent, stored in the postmeta table under key "_wpcf_belongs_parentslug_id". This defines the relationship between a parent and child post. You could add similar keys that point to the grandparent and great-grandparent posts. You could set these values whenever the child post is created. If the relationships between ancestors change, you would need a way to inherit those changes in all the related child posts somehow, probably using a cred_save_data hook if these changes are performed in CRED. This could get complex, but it's possible.

If the changes may be performed in wp-admin, you need a different hook, something like "save_post" provided by WordPress.

[jonB-5]

Okay, no problem, I'll do some more research on the plugin, then figure out if we need to copy the parent relationship data to child fields.

Could you talk me through how to set up the process whereby the Ship Owners approve certain Resellers to view their Vessels?

[Christian Cox]

Basically you will add a custom field to the Vessel post type. This field will be a series of checkboxes, and each option will represent a different Reseller. The value of each option will be a Reseller ID. The label for each option will be the Reseller name. So how you set up this custom field depends on how many Resellers there are and how often a Reseller is added or removed. If you've got just a few Resellers, then it's probably easiest just to hard-code these values in the options for your checkboxes.

However, if you have a large number of Resellers, or the options will change frequently, this probably doesn't make much sense. You will most likely need a more dynamic approach. This might involve creating a View of Users filtered by role, and using that View to populate the options for a generic field in your CRED form. Then you can capture the generic field values selected by the Owner and use those values to set the value of your actual custom field in the backend. It's a bit more complicated to set up because of the generic field, but it will take less maintenance in the long run.

Let me know which sounds like a better option to you.

[jonB-5]

The latter would be the better option at this stage, could you talk me through that process?

[Christian Cox]

Sure, let's start a separate ticket for that so we can get into details if necessary, and use this ticket for more general how-to concepts. The new ticket should be about how to set up a dynamic checkboxes field to associate Users with custom posts created using CRED.

[jonB-5]

Okay, I have created a new thread at https://toolset.com/forums/topic/dynamic-checkboxes-field-to-associate-users-with-custom-posts-created-in-cred/#bbp-new-topic

[jonB-5]

Right, the next issue I have a question on is restricting access to wp-admin dashboard.

We want our users to be able to manage everything through CRED forms and not have it look like they're using WordPress, so it would be beneficial if we could, at the very least, hide the wp-admin bar for the two User Roles 'Ship Owner' and 'Reseller'.

Is this possible and/or is there a better option for preventing them accessing the WordPress interface? I understand they may still be able to get there with direct links, but anything we can do to prevent it would help.

[Christian Cox]

By default, the admin bar will appear for any logged-in User. If you want to override that, you can use custom code. In this example, the custom capability "hide_admin_bar" is applied to any User role that should not see the admin bar:

function remove_admin_bar_user() {
    if( current_user_can('hide_admin_bar')) {
        show_admin_bar(false);
    }
}
add_action('after_setup_theme', 'remove_admin_bar_user');

[jonB-5]

Great, that's done it.

Now I wonder if we could begin to look at the field calculations?
(let me know if you think it best to start a new thread for it)

The relevant field slugs are below...

Booking CPT
number-of-places-booked

Ticket Variation CPT
total-available-for-variation
total-sold-for-variation

Ticket CPT
total-tickets-available
total-tickets-sold

So, what we need is for number-of-places-booked to affect total-available-for-variation and total-sold-for-variation, which then affect the total-available-for-variation field in any brother Variations as well as total-tickets-available and total-tickets-sold in the Ticket CPT.

I would also need a summary of how many places are available to appear at the Vessel level (summarising all Child Tickets), which I imagine may be possible with a View, but if not then I would create fields in the Vessel CPT to be calculated also.

[Christian Cox]

Okay let's assume you have created the Booking CRED form and placed it on your site, and when it's submitted it creates a Booking as a child of the correct Variation. Let's also assume you have handled validation using cred_form_validate, meaning that it's not possible to submit the form for more places than there are available for the parent Variation. Here's the code you will need to implement to handle the calculations:

add_action('cred_save_data_12345', 'calculate_sold_tickets', 100, 2);

function calculate_sold_tickets($post_id, $form_data) {
  $variationID = get_post_meta($post_id, '_wpcf_belongs_variation_id', true);
  $variationsAvailable = get_post_meta($variationID, 'wpcf-total-available-for-variation', true);
  $variationsSold = get_post_meta($variationID, 'wpcf-total-sold-for-variation', true);
  $ticketID = get_post_meta($variationID, '_wpcf_belongs_ticket_id', true);
  $ticketsAvailable = get_post_meta($ticketID, 'wpcf-total-tickets-available', true);
  $ticketsSold = get_post_meta($ticketID, 'wpcf-total-tickets-sold', true);
  $soldPlaces = $_POST['wpcf-number-of-places-booked'];
  $siblingVariations = get_posts(array('post_type' => 'variation', 'meta_key' => '_wpcf_belongs_ticket_id', 'meta_value' => $ticketID, 'numberposts' => -1));
  foreach ($siblingVariations as $sibling) {
    update_post_meta($sibling->ID, 'wpcf-total-available-for-variation', $variationsAvailable - $soldPlaces);
  }
  update_post_meta($variationID, 'wpcf-total-sold-for-variation', $variationsSold + $soldPlaces);
  update_post_meta($ticketID, 'wpcf-total-tickets-available', $ticketsAvailable - $soldPlaces);
  update_post_meta($ticketID, 'wpcf-total-tickets-sold', $ticketsSold + $soldPlaces);
}

- Replace 12345 with the numeric ID of the new Booking CRED form.
- This assumes your post type slugs are "ticket" and "variation", and your field slugs are exactly as you wrote them above. If not, you'll need to make adjustments.
- Create your Ticket and its Variations first, and define the numbers available and sold for each in wp-admin.
- Then submit the CRED form to create a Booking and check the numbers on the parent Variation, sibling Variations, and grandparent Ticket.
Let me know the results.

[jonB-5]

That's done it - Other than the items you mentioned, the only thing I had to do was to change variationID to ticketsID for ticketsSold as total-tickets-sold did not update on the first try. Final code is as below...

add_action('cred_save_data_248', 'calculate_sold_tickets', 100, 2);
 
function calculate_sold_tickets($post_id, $form_data) {
  $variationID = get_post_meta($post_id, '_wpcf_belongs_ticket-variation_id', true);
  $variationsAvailable = get_post_meta($variationID, 'wpcf-total-available-for-variation', true);
  $variationsSold = get_post_meta($variationID, 'wpcf-total-sold-for-variation', true);
  $ticketID = get_post_meta($variationID, '_wpcf_belongs_ticket_id', true);
  $ticketsAvailable = get_post_meta($ticketID, 'wpcf-total-tickets-available', true);
  $ticketsSold = get_post_meta($ticketID, 'wpcf-total-tickets-sold', true);
  $soldPlaces = $_POST['wpcf-number-of-places-booked'];
  $siblingVariations = get_posts(array('post_type' => 'ticket-variation', 'meta_key' => '_wpcf_belongs_ticket_id', 'meta_value' => $ticketID, 'numberposts' => -1));
  foreach ($siblingVariations as $sibling) {
    update_post_meta($sibling->ID, 'wpcf-total-available-for-variation', $variationsAvailable - $soldPlaces);
  }
  update_post_meta($variationID, 'wpcf-total-sold-for-variation', $variationsSold + $soldPlaces);
  update_post_meta($ticketID, 'wpcf-total-tickets-available', $ticketsAvailable - $soldPlaces);
  update_post_meta($ticketID, 'wpcf-total-tickets-sold', $ticketsSold + $soldPlaces);
}

Following on from this, there are two items that I should implement...

1. validation using cred_form_validate, meaning that it's not possible to submit the Booking form for more places than there are available for the parent Variation

Could you advise on how to do this? I've looked into the code but it's a little beyond me. If I see an example for Booking I can then likely implement that to limit Variation stock under a Parent Ticket also.

2. In the instance where, under the same Ticket, there is 4 of Variation A available and 6 of Variation B available, it would be useful if the stock for Variation A was not reduced until the stock for Variation B became less than the stock for Variation A.

If this is not possible, or is too complicated, we will likely set Variation stock to be automatically equal to the Parent Ticket stock on Variation creation and get users to only set stock at the Ticket level. Do please let me know your thoughts on what may be the best approach.

[jonB-5]

Further to item 2 in the last post, if a booking was made against Variation A, this would still affect any brother variations with higher or equivalent stock.

[Christian Cox]

the only thing I had to do was to change variationID to ticketsID for ticketsSold as total-tickets-sold did not update on the first try.
Good catch, I'll edit my previous comment to reflect that typo fix.

1. validation using cred_form_validate...Could you advise on how to do this? I've looked into the code but it's a little beyond me. If I see an example for Booking I can then likely implement that to limit Variation stock under a Parent Ticket also.
Certainly, please create a separate thread to discuss this in more detail.

2. In the instance where, under the same Ticket, there is 4 of Variation A available and 6 of Variation B available, it would be useful if the stock for Variation A was not reduced until the stock for Variation B became less than the stock for Variation A.
Okay I think this update to the foreach loop should resolve that issue:

 foreach ($siblingVariations as $sibling) {
    // update the number of variations available for sibling posts
    //if the number available is greater than current variation available, or is current Variation
    if( get_post_meta($sibling->ID, 'wpcf-total-available-for-variation', true) > ($variationsAvailable - $soldPlaces) || $sibling->ID == $variationID ) {
      update_post_meta($sibling->ID, 'wpcf-total-available-for-variation', $variationsAvailable - $soldPlaces);
    }
  }