[Resolved] Self assigned child post filed values

[Author]

Posts

[Ljuba]

==>Tell us what you are trying to do?

I have several kinds of child posts (Reservations, Schedules, Payments, Deals, ...) that, with a small set of conditional logic, are universally applicable to several kinds of parent posts. First field in the child post is 'Type of the child post' (ie 'Type of reservations', 'Type of schedule', ...).

PROBLEM

Problem is that clients could be confused if they will see within the choices something what naturally don't belongs to there business activity. Example of 'Schedules' - Hotel owner client will be confused if he will find option to select 'Opening Hours', 'Delivery Hours, ....

QUESTION

How to display 'native choices' of 'selectable field values' per parent post (so, to disable 'aliens')?

P.S. - EXAMPLE In my site, you can see under post 'Horarios' that initial field is 'Tipo de horario'. As for now ';eading' post is Alojamientos, you will see bunch of the schedule types that do not belong to the accommodation business activity. I would like to not display it to client in CRED form and Dashboard - to avoid confusion.

P.S. I guess that it is possible with CRED conditional logic, but now (in this topic) is matter of Types (structure). So, is it something what say like

"if parent is ZZZ, hide x1, x4, x6, ...."?

==>Is there a similar example that we can see?

On my site.

[Nigel]

Do you mean that the relevant fields should be shown simply on the basis of what the parent post type is, rather than they should be shown once the user has selected the first "Type of" field?

I know you are familiar with the conditional display of Types fields, where you can show/hide some fields based upon the values selected for other fields, which (ignoring its limitations) would solve the issue if you meant the latter, that the user chooses "Type of..." and then the remaining fields update their visibility accordingly.

So I suspect you mean the first, that the visibility of fields is automatically determined by the post parent type.

Well, I guess you probably know the answer to that, too, which is that no such conditional display is possible. (It is simply not contemplated.)

From a Types perspective, I don't see how you would have any alternative to creating separate field groups for each parent post type (e.g. "Hotel schedules", "Restaurant schedules" etc. instead of one catch-all "schedules" group of fields).

[Ljuba]

1) "Do you mean that the relevant fields should be shown simply on the basis of what the parent post type is, rather than they should be shown once the user has selected the first "Type of" field?"

No. Fields depends on schedule type (from those first selectable field).

2)

Image 001 shows that there is no other fields available except 'Tipos de horario' (others are conditionally visible).

Image 002 shows how many of choices do not make any sense to be visible within 'Hotel' business activity. Indeed, from 10 choices, only 3 should be visible for this kind of post type ('reserva', 'registro' and 'limite'). Other 7 should not to be visible with Alojamiento post type.

3) WHY IT SHOULD BE AS I ASK?

There are several reasons. First is obvious easier Types structure (simple conditional logic).

Second is fact that there is no real 'recipe' where what should to be displayed (mean that within Services post type, that will depends on two fields, not just on the one - here, that one is - 'Tipo de horario').

Third (and most important) are my Views concept (conditional show/hide/replace same View on many different situations/scenario's/places/pages).

RESUME

How to 'hide' 7 field values not needed in Alojamiento post type?

[Nigel]

OK, I understand.

Well the only option you have, I think, is to use the filter 'wpt_field_options' that can be used to modify the options listed in relevant Types fields (e.g. select fields, radios).

It seems like we still haven't documented this properly, but if you add the following to your theme's functions.php file and then edit a post which includes a select field, if you inspect your debug log you'll see the arguments available and the format required to manipulate the options of a specific select field.

The post type of the post being edited will be available from the global $post object.

function tssupp_wpt_field_options( $options, $title, $type ){

	error_log(print_r($options, true));
	error_log(print_r($title, true));
	error_log(print_r($type, true));

	return $options;
}
add_filter( 'wpt_field_options', 'tssupp_wpt_field_options', 10, 3 );

[Ljuba]

Thanks a lot. I get it.