[Resuelto] Conditional remaining 'selection' BUG

[Autor]

Mensajes

[Beda]

Hello

I will not answer all the subquestions and assist all the subproblems that you reported in this ticket.

Instead, let's remain on topic and clarify the issue and handle other issues in a ticket each.

1. You reported that if you have chained Fields shown conditionally in the backend, and populate them, then remove the first condition all sub chained items disappear from the edit screens but still do show their value of subchain fields.

That is perfectly expected and as I explained it will not be changed, and I provided the solution.
https://toolset.com/forums/topic/conditional-remaining-selection-bug/#post-907403

2. Let me clarify one last doubt:

When you have a chain of conditional fields like below:
Condition Field One
- Second Dependant Field
-- Thir Dependant Field

Then, if you populate and save all 3, but later remove the value from "Condition Field One" (so that in the Admin the other 2 fields are not visible now) the values of - Second Dependant Field and -- Thir Dependant Field is, of course, still saved and as well visible on the front end - hidable as explained with HTML conditional.

We will not change this behaviour of the fields and the solution would be to use the conditions to hide sub-conditional fields if "parent" fields don't match the values.

[Beda]

changing status

[Ljuba]

This is not a critic. It is very possible that my English (generally, my way of explanation) is not clear. So, unfortunately, I must to be extended (again).

A) "I will not answer all the subquestions and assist all the subproblems that you reported in this ticket. Instead, let's remain on topic..."

GREAT, I agree 101%.

P.S. - It is completely different that I found other issues, by looking for solution.

B) "You reported that if ..."

To avoid misunderstanding (misinterpretations), about what I reported like BUG, I wasn't 'lazy' and:

1) I created on aggregated link (site) custom post type "Test Posts" with Custom Fields Group of the 'administrative division' 101% equal to initial topic post.
2) I created single demo "Simple Post Example" on custom post type "Test Posts" with Custom Fields Group of the 'administrative division' equal to initial topic post.
3) I created screencast (attached as SC_01 and available on home page of linked website as mp4):

I) of the creation of single demo "Simple Test Post" on custom post type "Test Posts" with Custom Fields Group of the 'administrative division' with scenario equal to initial topic post,
II) which shows only back-end behavior (I just noticed, that same is also in front-end, but focus of topic is on back-end - ON BROKEN FUNCTIONALITY OF ENTIRE POST),
III) which shows absolutely clear how back-end behaviors is not as you claim in your reply (and I agree that it should to be as you claim - that is why I opened ticket) - "once you break the condition of the first or second field, the subsequent and chained fields will not be shown anymore". Initially I created and saved post as US selection, but when I switched the initial conditional option (Country) to Ecuador and by this I "break the condition of the first ... field", US depending fields are keep to be shown (also in back-end), contrary to your claim (and my), how it should to be (as condition is broken). So, it appear that US (fields) "Texas Cities and Dallas Neighborhoods" belongs to Manabi Province and Ecuador Country (fields) (and they obviously don't),
IV) which shows absolutely clear also your (equal to my complain) scenario that "if you populate and save all 3, but later remove the value from "Condition Field One" (so that in the Admin the other 2 fields are not visible now)", but with difference that "in the Admin the other 2 fields are" still visible now.

C) "Thir Dependant Field is, of course, still saved and as well visible on the front end - hidable as explained with HTML conditional."

I don't think that you understand or realize about how HUGE PROBLEM here (topic) is. Approach that we (Toolset clients) can fix in 'surface' (front-end) something what is hugely messed in beck-end (at the begin), is more than seriousness. It looks that you cannot take the picture what is going on with (serious) 'chain' of ie 20 fields and several changes of choices (ie my Admission Field Group should be quite complex). For such reasons, I wasn't lazy and I created extended demo with Test Posts II and 3 countries (see on my site home page SC_02 - I can't upload it here as it is bigger than 1mb). It appear that both, Dallas (US) and Verona (Italy), belongs to Manabi Province (Ecuador).

I'm simply wandering what kind of 'HTML conditional' can predict and fix some significantly more complex scenario (read, many chained conditional fields).

However, fact is (easy visible in screencasts) that despite break in conditions, ALL DEPENDING CHOICES REMAIN IN DATABASE, KEEP TO BELONGS TO POST, AS WELL TO BE VISIBLE IN BACK-END OF THE POST. as more fields and changes we made, more huge mess appear, as yeast (or cancer).

GOAL OF THE TOPIC

Contrary to your observations, from my point of view is (not) complete irrelevant:

1) that all depending choices remain in database,

2) that all depending choices remain visible in back-end,

MAIN PROBLEM IS:

3) that all depending choices remain (keep) TO BELONGS TO POST.

What it mean? Simply, your (Toolset) conditional logic chain is not broken by switching the choices.

Can I prove it? YES, I do (see SC_03 attachment).

EXPLANATION (of screencast)

If we assume that it is irrelevant that Dallas selections are still visible in back-end and that they are obviously still in database, BUT HOW THEY ARE NOT ANYMORE PART OF THE POST, by switching next field in chain of "US channel" (as now is primary selection of the chain - Ecuador, so nothing from "US channel" should to be affected by any action, including any changes within already 'broken'/'excluded' fields in the chain of the "US channel").

MATERIAL FACT is that it is not the case, as post still react on any attempt to "clear" remaining "garbage fields selections", EXCEPT IF IT IS NOT DONE BY REVERSE ORIGINAL ORDER.

Sorry, even that will be nice, but ... THERE IS NO OPTION HOW TO CLEAN FIELDS (be free to try on provided website).

ALL THOSE "GARBAGE FIELDS" KEEP TO BELONGS TO THE POST FOREVER.

In other words, fields not just to keep on to belongs to post, they retain ENTIRE COLLECTION OF ANY SINGLE FIELD FUNCTIONALITY. It mean that such "garbage" field will affect all other fields in the post (in some way). With slightly more complex conditional fields and 'public' availability of usage, it mean just one - HUGE CHAOS.

EXAMPLE (what I should to have)

If Admission is in any way connected with Opening Hours (and it is - obviously), and users (members, business owners) are available to make changes (and they will do it - frequently), ..... BRRRRRRRRRRR

PAY ATTENTION (if this will help)

To use your expressions of:

Condition Field One
- Second Dependent Field
-- Third Dependent Field

equal to my post:

Country
- US States
-- Texas Cities
--- Dallas Neighborhoods

A) You can see that 'switching' value from "Condition Field One", it is not anymore shown subsequent field "Second Dependent Field" (US States), what (for my opinion is only illusion (as it keep to belongs to post - what I proved), but "Second Dependent Field" not break subsequent field (and so on in the chain).

B) Again, it is not just 'visual effect', second field keep functionality as you cannot anymore to remove it from the post in any possible combinations of steps. So, you can set all US fields to not selected (including 'hidden' US States), but it will not remove it from the post. In other words, you (Toolset) cannot even to claim how field is in database, but hidden and without functionality (not belongs to post), as it is not the MATERIAL FACT.

[Beda]

Hi

I made a screencast of how conditions do work on Toolset 3.0.
enlace oculto

I think I covered all cases.

If anything deviates from there, please could you open a ticket, where you share the data and steps how to achieve any misbehavior?

We would then need to fix this.

Related to the data that stays in the database if the conditions is broken, yes, that is true, that is exactly what I say.
Imagine you do break the condition by mistake
All that data of the sub-fields would be lost as we (if we follow your suggestion) would scratch all those values.

Now, it is true that the data remains in the database and with that may present issues in searches for example, and the solution here is to enter the correct data in your database, there is not much that can solve this otherwise

But, I will present your concern to the developers so they can decide what course of action to take in regard to that and respond you here about.

Please report each issue that deviates from what you see in my screencast in a new ticket.

I would usually follow up here, but we both see that the ticket is getting too long and we are handling the question of how it should behave here, would you mind to start a ticket with the particular not working condition, as that seems an exceptional Bug on your install?

[Ljuba]

I'm confused, because it seems to reasons unknown to me, that you are trying to rid me of the public mockery. My reply is not with ‘personal touch’ and it is without any inappropriate content. Contain only pure material facts. I will now open new ticket about exact this subject – Toolset Support. Now, lets go further with this issue.

SCHOOLBOY

Your screencast - Yes, that is how I expected that conditions work. Your screencast shows exactly that.

But it is not the case in real life (real data) and that is why I opened this ticket and my screencast shows exactly how they don’t works as it should (do you saw screencasts at all?).

QUEUING

You try to 'place me in order' by asking me to do what I already did. It shows that you not even read what is in the ticket (content of replies).

You ask me to do exactly what I already did. I already created demo website by opening this ticket with:

a) I already created website by opening this ticket (where is BUG visible)

b) Demo Custom Post Type (where is BUG visible)

c) Demo Field Group (with conditional fields) what belongs to that CPT (where is BUG visible)

d) Demo post with content (where is BUG visible) what belongs to that CPT

e) Screncasts (where is BUG visible)

QUESTIONS

1) Do you ever opened website posted in private link (at the begin of the topic)?

If you do, why you ask me to repeat everything (after two wasted weeks)?

2) Do you ever saw above listed SPECIFIC (real life) data with the BUG?

If you do, why you ask me to repeat everything (after two wasted weeks)?

TOOLSET SUPPORT TASK

Instead of two weeks of wasted time on 'empty' replies, forced by you (Toolset), Toolset support (you) should to open privately posted website with reported BUG and to try to establish is it about the BUG or not (so, client did something wrong)?

1) If client did something wrong, Toolset should to help the client to fix it?

2) If it is about the BUG, Toolset should to fix it?

Do you did anything of above, or you trying to mocking me (client), despite the fact that Toolset have the BUG?

So, it looks that you didn’t mocked me, rather Toolset (you), by showing incompetence in simple support.

FINAL QUESTION

Do you still insist that I create another ticket and website with EXACT SAME DATA, where is BUG visible, or you will open website posted in this topic in private reply (you have credentials) and try to establish and fix the issue - is i BUG or client mistake?

Los hilos nuevos creados por Beda y vinculados a este se encuentran a continuación:

https://toolset.com/es/forums/topic/on-my-website-the-toolset-conditional-for-custom-fields-does-not-behave-the-same-way-as-on-a-fresh-install/

[Beda]

Let's stay on track here.

I am here to discuss a feature request that is by now filed, and this we will keep discussing here.

Any concerns with the technical support can be directed to this form:
https://toolset.com/?page_id=421149

I do not handle the technical aspect of this ticket, I am here to discuss a feature request - any technical debug and clarification is part of another process.
It seems on your site there is a problem that was not appreciated, so let's handle that properly now.

During this discussion we found that actually in your install things seem to work in a broken way, suggesting a compatibility issue since we cannot replicate that situation.
That, we can either handle here, and then this ticket will cover several topics (we do not do that: https://toolset.com/toolset-support-policy/) or in a new ticket.

I have made it for you:
https://toolset.com/forums/topic/on-my-website-the-toolset-conditional-for-custom-fields-does-not-behave-the-same-way-as-on-a-fresh-install/

For the rest, I explained to you how this is working - I did not waste time.

This ticket here handles one remaining issue, which is a feature request:
- to delete all the content saved in chained child conditional fields, if a parent field of those is saved with un-matching conditions

That will be discussed by the Developers, and I will let you know here wether or not we implement this

[Ljuba]

"This ticket here handles one remaining issue, which is a feature request:
- to delete all the content saved in chained child conditional fields, if a parent field of those is saved with un-matching conditions"

I did not asked that. Christian did. Read the Topic.

I from begin reported BUG and that is the title of topic (BTW). If I'm misunderstood, I'm sorry, but we cannot keep like this by wasting the time. It is simple - is it BUG or my mistake?

You don't need to reproduce anything, you have website and credentials and you can try it yourself to establish what about it is. It is more than quick and simple.

Am I nervous? Yeas and sorry for that. But I'm all the time faced with issues and wrong direction of the development of the support (read my another topic with WYSIWYG editor).

Instead to use my time on development I waste it in useless replies. Useless as it not lead anywhere.

[Beda]

I did not asked that. Christian did. Read the Topic.

OK.
Do you need it?

Because I am about to discuss this with the developers as we discussed the last few posts, tomorrow.

is it BUG or my mistake?

- The Custom Field does NOT remove the custom fields VALUE if you remove a parent condition.
That is the good behavior that is currently happening and if you ash if this is a BUG, no, it's a feature, and it's not a mistake of your either, it is expected.

For this, as discussed several times already, I am going to discuss with the developers wether or not we want to change that.

- The Custom Field not being hidden in the BACKEND; as I show it working on my screencast and you show broken on your screencast, must be either of this:
- exception
- setup issue
- compatibility issue

We will find out here:
https://toolset.com/forums/topic/on-my-website-the-toolset-conditional-for-custom-fields-does-not-behave-the-same-way-as-on-a-fresh-install/

I will work on this bug report tomorrow myself.

My apologies if this is the sole thing you wanted to report, then I must ask, what the discussion about the fields showing up is about.

My apologies if I misunderstood the report all together.

Please lets not pollute a thread with discussions about what we think is best.

This feature, will be discussed by the DEV.
The BUG will be analyzed by me tomorrow with the data you provided and we will solve it.

Thanks.

BTW, this are my working schedules, in case you are waiting for my work on that ticket:
https://toolset.com/forums/users/beda-s/

See you there!

[Ljuba]

So, to crystallize the issue. Several ways of same issue explanation attempts.

1) I asked, why in my real life example (real CPT and this new DEMO CPT) my fields not have same behavior like in your screencast (as that is how I expect to be)?

2) i don't care, are they ('garbage fields values') still in database or not. I just don't want them to be present anymore in the post (to keep to belong to post). Finally, it is not anymore even possible to remove it any way.

Did I seriously asked anything complicated when I reported by topic something what I classify as BUG?

Problem is that nobody even open my website to see what about it is. So, why I posted links at all seven days ago (May 31, 2018 at 5:00 am)?

[Beda]

That sounded quite different before:
https://toolset.com/forums/topic/conditional-remaining-selection-bug/page/2/#post-909124

Anyway, hence the feature request is not needed anymore, and we can fix on the bug report.

The bug reported by you is:
https://toolset.com/forums/topic/conditional-remaining-selection-bug/#post-905921

Christians analysis:
https://toolset.com/forums/topic/conditional-remaining-selection-bug/#post-906932

You disagree with a lot of details:
https://toolset.com/forums/topic/conditional-remaining-selection-bug/#post-906972

It is clear by then that you refer to 2 things:
- fields still show in backend,
- fields still saved

Christian tells me to take care of this feature request.
I see that this is not required and feedback to you.
I then see what you possibly may mean and offer an alternative, a solution(front end as well as backend) and now will as well handle the issue that happens on your site on the next ticket.

From the point on this ticket changed to my responsibility I started my work trying to solve a feature request.

As said, for complaints about support, please use this:
https://toolset.com/?page_id=421149

I will handle the bug in the ticket that I created for it in the manner it has to be handled.

You will see what I mean by tomorrow.

Good day.

[Ljuba]

OK, finally we are productive and with some progress).

1) "Do you need it?"

How can I possibly to know answer on this question. I don't know how Toolset handle conditional logic. Why me or anybody else of Toolset clients will care about that what Toolset do with 'remaining broken values'? We are clients, not developers (of the tools).

I (client) only want that 'garbage vlues' not keep to belongs to the post (so, to act as on your screencast) and I opened ticket as in my case I can see that they do it (keep to belongs to the post). Moreover, they connot be even removed in any possible way. You have on my website post and try to remove it. I made and attached screencast how it cannot be removed.

2) "is it BUG or my mistake?"

We obviously don't talk about same thinks. I talk about fact that subsequent field values of broken chain remain to be part of the post (and should not to be).

a) So, I have business in US (country), Texas (State), Dallas (City), Design District (Neighborhood).

b) Than, I have move the business in Ecuador (country), Manabi (State), Canoa (City), Rio Canoa (Neighborhood).

c) Post now shows that business is located in:

I) Ecuador (country), Manabi (State), Canoa (City), Rio Canoa (Neighbourhood), as well in

II) Dallas (City), Design District (Neighborhood)

By switching to Ecuador (Country), Texas (State) is not shown anymore in post (as it should to be and as it is on your screencast), but Dallas (City) and Design District (Neighborhood) are still shown in the post (and they should not to be). Worst, it cannot be even removed, as it keep to belongs as part of the post.

So, I (client) don't care what Toolset doing with US (country), Texas (State), Dallas (City), Design District (Neighborhood) - are they still in database or not.

Client (me) don't want that Dallas (City) and Design District (Neighborhood) keeps to belongs to the post (in visible way), equally as it happen to US (country) and Texas (State).

3) "...must be either of this: - exception - setup issue - compatibility issue"

Yes, that is ONLY what I ask and why I open the ticket (with remark that I claim that it is the BUG caused by Toolset decision to keep data in database). However, I asked that support determinate the issue.

REMARK

Count that I created DEMO CPT's only to simplify my issue. I have REAL LIFE ISSUE in my CPT "Sitios" where I created DEMO post "Playa de Canoa".

Open the "Playa de Canoa" and you will find the issues in Field Groups "Tipo de sitio"and "Admisión" (and further will be more similar Field Groups). "Tipo de sitio" is quite simple conditional chain and already contain issue.

I set it initially as "Espacio urbano" > "Pueblo singular".

Than I changed it to "Accidente geográfico" > "Formacion costera o oceánica" > "Playa costera" (actual state of post.

Now try to keep to "play with that fields" (change choices by saving) and you will see the mess ("Playa costera" keep to be on the post).

ENTIRE CONFUSION IN TOPIC arise in fact that I realize how entire mess is result of your decision to keep data in the database, but you (Toolset) don't understand that you (Toolset) are not capable to control usage scenario's (nobody can do it). So, from my point of view, your (Toolset) decision is not 'smart' (no offense, only expression), but I could be wrong in that opinion. However, my website prove the mess what Toolset can't control.

If Toolset will standing that conditional logic is aimed only for simple (one step) chains, than OK (it is legitimate), but with slightly more complex chain, it is only the CHAOS.

I have a LOT OF EXPERIENCE with Formidable Pro and there is no such of approach (so, no mess).

My DEMO "Test Post II" only shows you how serious mess can be produced by at least slightly more complex conditional chain.

[Beda]

1.

Yes, you need it.

BRIEFLY

I think that when parent conditional field is switched to new value, child fields should to be also switched to 'clean/initial state', what is not the case.

Issue what produce that behavior is very negative, as if user will /mess' a lot, final View will contain also 'garbage' child fields values displayed.

https://toolset.com/forums/topic/conditional-remaining-selection-bug/#post-906576

But I cannot guarantee that this will be done, as the opposite effect t will also need to be considered.
I will update you here in regard, I have yet no news.

I understand that the saved "garbage" data will pollute the Queries.
And, linger as orphan in the database.

But, usually this is under the responsibly of the creator of content.
No machine or software can replace control and edition of humans, so if you input data with Toolset, it saves it.
But again, I will update you in regard of this request / feature here.

2. Handled here:
https://toolset.com/forums/topic/on-my-website-the-toolset-conditional-for-custom-fields-does-not-behave-the-same-way-as-on-a-fresh-install/#post-909803

It's not a BUG
It was missing some additional checks in the conditional

[Beda]

Hi

We added a feature request to our list, which other users will be able to upvote as well.
In a very soon future, we will have a public list of feature requests and there users will be able to upvote other request as well

The request filed is about the "orphan" values that you have in the database if you do save child conditional fields but not their parents.

The request is to allow the user to decide either by option or filter, if to remove, or keep these child values.

This can as well be achieved with custom code right now, but that is not subject to the support
In case you require help with it, I suggest to contact a contractor for the task:
https://toolset.com/contractors/

The easiest is to assign capable editors who know how to enter the data in the complex conditional system.
A warning in the description can make sense as well.

For now, this feature request is filed, and there is no ETA about an implementation as it requires more upvotes, and once that is reached, some time to implement.

It is not granted that this will be implemented but we have filed it and will consider it if adequate.

Thank you!

[Ljuba]

You (Toolset) can develop it, but I don't think that Toolset take in right way the subject and significantly complicate "life" of the clients (web developers), with no reasons. Toolset actually switch the subject from the top to bottom.

1) That what you (Toolset) call (and treat as) "orphaned" values are in fact "garbage" values. Difference is clear. First you maybe will need and second you certainly don't.

2) I assume that is material fact how Toolset market is front-end usage, otherwise, it will not contain entire set of tools of 50 MB of codes, rather only Types with 2 MB (like Pods).From other side, I'm more than sure how for exclusive back-end usage (so, for web developers) those same developers will rather use 2 MB tool than 10.4 MB (plus to pay for it).

3) If above (2) is correct, than ther is no logic to keep saving "garbage" in database, as web developer those EXCEPTIONAL SITUATIONS (cases) can easy to handle with CRED conditions ('hiding' data sets). But problem is that in real life is no such kind of the case, as nobody want to permit to members to overload the database with "garbage".

Example. If I limit images (usual case is limiting data) to 6 per member post, why I will allow him to repeat new 6 images and to keep old 6 images in server database? There is no logic for such decision. Member can go indefinitely with that. So, Toolset here actually force contrary philosophy of limitation of data.

I repeat, if member decide by himself to replace 6 images, why would I decide to keep the data in database???

4) Consequences of decision to keep data in database are ridiculous, as Toolset significantly complicated creation of conditional logic by enormously rising the numbers of QUERIES and slowing the database via those queries and "garbage" data. It is specifically significant with complex conditional logic chains. Actually, for some tasks, developers will need the weeks to create it (as all scenarious must be tested), instead of couple of hours.

CONCLUSIONS

Instead to delete "garbage" by default and try to solve eventual remaining scenarious for some rare cases by simple solutions, Toolset twisted the logic and solution form up to down.

A) Front-end can be easy solved by web developer by 'hiding' data and not by delete. So, actually by usage of "repeater groups". So, if those eventually needed to be saved ("orphans") values, in Edit Form will be used 'replace' via 'hide' group, rather than working with fields (obviously, here I talk about back-end construction).

B) Back-end can be also easy to be solved by simple query (pop-up dialog) "Do you want to Delete Permanently, to put in the Trash or to Cancel"? - 'Trash' is what Toolset doing now and than if "trash' is chosen, additional warning is needed that conditional logic chain must be done with complete chain of the queries (see other topic).

However, as I certainly don't need this feature (and never will), I will close the ticket. And Toolset can do whatever want, but I don't think that further complicated (in any way HUGE) codes is something what Toolset (clients) need.

KISS (Keep It Simple, Stupid)