HOWTO:create join form field with 'Not Specified'

This is instruction on how to create a field on join form with 'Not Specified' or 'Select it' as first element in drop down box.

It will ask user to select some value instead of some preselected value, which one user even not noticed.

1. create predefined list:

2. Create the following field on join form:

3. Test the result:

As you see - I can not submit a form without selecting this field - it gives me error message

Question: if you don't select to make it mandatory does the value submitted then become Not Specified?  If so this isn't really a work-around to the main issue.

I've tried this exact same thing before, and never could get it to work right  On the user side, the values have an ascii sort.... they do not appear in 0-1-2-3-4 order according to the 'value' field in predefined lists.

Try Again.

Alex, again thank you for responding, but I don't think that approach will work. It looks like this may be a way to force people to enter a value, but all you have done is add a new field to the predefined values table with a value of "0" (zero). Zero is not a null value - it is an actual value of zero. That means when you try to create a search form with this, it will be searching for that "zero" value.

So if you have a search with two fields - lets say "hair color" and "eye color" to use your example. You want to find members with brown hair, but you don't care about eye color so you select "brown" for hair color but leave "not selected" for eye color. This will search the database for "brown hair" and the actual value of "not selected" (zero). Using your approach, this will not return any results- the query will be looking for members with brown hair AND "o" (not selected) but since "not selected" is not null - it is an actual value, there won't be any members with both those fields so the search won't work. Please let me know if there is something I don't understand here.

NULL is not a case either, if it will be NULL value it will try to compare with NULL - and you will get no result too.

The problem you are describing is not related to this.  The problem is in multiple selector form element on search form :

- Dolphin 6.1.x had standard html multiple selector form element which allowed to select no values at all.

- Now Dolphin 7.0.x has own multiple selector which do not allow to select no values.

But, origin of the problem is join form - and as you can see it can be easily resolved.

So you are saying that you can force people to select a value in a single select on the join form, but the search still won't work no matter what, is that correct?  So it really isn't resolved at all is it?   Could D7 use the standard html multiple selector, or could D7's "own multiple selector" be made to work with an empty value?   This is a big issue with my site, and I'll bet it will be a big issue for others also as their sites get more developed.

I must be missing something.

My Country List:

My Corresponding Field in Join Form: (Note the default value)






My user side Join Form:



Note how the default value is not preselected, and the list is an ascending ascii sort... not ordered by the 'Value' field in the predefined values list, and the first value in the list is what is preselected.

I don't get it.  I think this may have actually work the first, and ONlY first time I tested it.  Afterwards, the default value specified in fields builder, is seemingly ignored.

I wish that, once in a while, Boonex staff would discuss things until they were actually resolved, instead of these hit and run posts that they always do.

Kind of reminds me of "Catch Me If You Can."

I don't know what is going on with this.  You won't be the first one to try to explain this issue to them by posting detailed images, and the Trac history looks almost like a coverup.   How could the developers at Boonex develop such a sophisticated product, and apparently not be able to understand this one very basic issue?  They seem to just want to solve this by declaration - i.e. "see, it works".  The conspiracy theory part of me tends to think they want discussions like this on the forums so that it will quickly be buried once there are 20 more posts and it moves to the next page - where for all intents and purposes it no longer exists.   I'm guessing one of the Boonex developers will eventually publish this a mod that we have to buy to get it fixed.

Let's look at this:

1.  Your stating that you want it so that when the field is set to mandatory it can permit a "null" value to be selected.

2.  You want the "null" value to be the default selection

3.  You want the "null" value to either be searchable or eliminated from the search?  I'm not sure which way you want it or recommend it should go.

So, how do we make this happen as anything is possible in coding.  And your right, the current set up will not allow it, though there are mods from D6 that should be updated eventually to D7 (they aren't yet though they are by Boonexers) but they still don't do exactly what you want. 

 You want it so if a member, on the join/edit profile forms selects one field that is mandatory then they can avoid another field that is mandatory as it does not apply to them.  Okay, for this one, your looking at it wrong if I'm understanding you correct.  May I give how I'm seeing this:

• You have 2 member types for argument on your site.  Industrial Business and Industrial Customer.
• The questions of a business are different than those of a question.  While some are similiar, many do not apply across the board to both and they can not be expected to answer all questions as it will cause you to obtain tons of useless data on every member.

For the above instance, your approaching this completely wrong.  It's not a null value situation, it's a way of completely removing those questions from the join/edit forms based upon the members responses early in to the join/edit process.  So why not have 2 completely different join forms for the members.  One would be Industrial Business and the other Industrial Customer. 

To accomplish this, you need to not create havoc with your database and make all the fields searchable.  In this instance, it can be done already in D6 and I believe the D7 mod for this is available and Boonex should have included it into D7.  I'll agree with you on that one.   It's a Profile Type Splitter.

Your potential member joins the click button, doesn't matter if they are a business or a customer.  It goes to the same place.  It doesn't need to go anyplace else right now.

Question #1 on the Join Form will be literally the most important question there is.  It will ask them what type of membership they want.  Industrial Business or Industrial Customer.  Once they choose this, the rest of the join form populates with it's questions.  You get to set all fields to mandatory and control from field builders which form they appear on and they do not error out if you have a mandatory question on the join form for a Business that is not on the join form for a customer. 

Next up, while your building these pages, you get to select what items appear on the profile page of each type of member and what items even each type of member gets to see.  It's really beautiful actually.  Finally, the search page is exactly what I hear you saying you want.  Matching of your Industrial Businesses to your Industrial Customers.  If a customer comes into  the search page, they only see searchable fields that apply to the businesses and vice versa.  In the end, the final search pulls up the opposing membership and can be set to ignore the same membership.

No offense Rob, but I told you I had this back in D6 and unless I'm missing something, your fighting for something that is already in existance and much better even than what your after.  Toss in some Pre-Defined Dependent Values and you have an awesome matching system that will give the appearance it is actually thinking about what your member wants and responding appropriately to them via AJAX programming.

If I'm missing the boat on what you want, then please let me know, perhaps I'm just not understanding this after all.

Yes, you are missing the boat.  I know you have developed your own private label split profile mod for D6 and I am not interested.  That has nothing to do with this issue - I only have one kind of member and don't want a split profile mod.  Go back and read the threads on this so you can gain an understanding of this issue if it is important for your own sites.

Yes, you missed the boat.   I can give you a simple demo though here:

http://demozzz.com/dolphin7b/search.php?search_mode=adv

I assume you're registered there.

Here's the advance people search form:



What I would like you to do, is go to that form, and enter 'Paris' as the city.  What we are looking for, is everyone that lives in a city called Paris.  We all know that there is a city named Paris in France ...... However.... maybe there's some other Paris in some other country.  I can tell you that there is, because I made a profile on that site where I live in a city named Paris.  I won't tell you the country.

Using only the form shown above..... Go find my profile.

There is a sorting especially for Country field. This is the reason it is not work for countries !

Try to remove or comment out the following lines in inc\classes\BxDolProfileFields.php file:

if ($mValues == '#!Country') {
$aValuesTrans = array_flip ($aValues);
ksort($aValuesTrans, SORT_STRING);
$aValues = array_flip ($aValuesTrans);
}

Correcting the problem of being able to submit the join form without any user input on required fields that are a selector element, is only part of the problem.  That's the part that Alex attempted to solve with his post here... It doesn't work for me though, as I have shown above with the screen shots.

The second part of the problem, is that if you want to build custom profile fields, and use selectors for those fields, there is no way to use those custom fields in search forms.  This is because there is no way to set a default value that tells the search function to ignore that field in searches.  The example I  described above demonstrates the problem.  If I wanted to find all members that lived in a city named Paris, and ignore the country field, I can't do it.

Now imagine if that city name is instead multiple  drop down lists corresponding to various custom profile fields, and you should quickly see how useless a search form can become.

Thanks Alex.  Commenting out the sort function took care of one part of the problem.

However, the rest of the problem remains.

Thank you Alex and HL - it does appears you have solved the first part of the problem.  Since I will also be using the country table as one of my select tables, this is useful information.  Can you include this code change in the next release?   As HL (an others) pointed out, however, that is only part of the problem - we still can't construct a search with more than one field if it is made with a predefined values table.  That is why we need Boonex involvement for an integrated approach to this issue.

p.s.  good example by the way, but it Alex is a movie buff I'll bet he can guess without even using that form.  That was one of my favorite movies.

No..... no one will guess.... because I just picked a random country.  When Alex finds a way to modify that search form so that the country field is ignored, the problem will have been solved.  (No Fair repeating the search for every country on the list)

After that problem is solved, we can start talking about a truly advanced search form, where you can select boolean operators ie....

"This Field Value" AND "That Field Value"

"This Field Value" OR "That Field Value"

The root of the problem is that the search function is stuck in dating site mode.  It needs to be a little more universal so it can be adapted to different types of sites.

http://www.boonex.com/trac/dolphin/ticket/1799

Try to change the following code:

case 'select_one':
case 'select_set':
if( isset( $_REQUEST[$sItemName] ) and !empty( $_REQUEST[$sItemName] ) ) {
if (is_array( $_REQUEST[$sItemName] )) {
$mValue = array();

foreach( $_REQUEST[$sItemName] as $sValue ) {
$sValue = trim( process_pass_data( $sValue ) );
if( $sValue )
$mValue[] = $sValue;
}
} else {
$mValue = trim( process_pass_data( $_REQUEST[$sItemName] ) );
}
}
break;

to the following:

case 'select_one':
case 'select_set':
if( isset( $_REQUEST[$sItemName] ) and !empty( $_REQUEST[$sItemName] ) ) {
if (is_array( $_REQUEST[$sItemName] )) {
$mValue = array();

foreach( $_REQUEST[$sItemName] as $sValue ) {
$sValue = trim( process_pass_data( $sValue ) );
if( $sValue )
$mValue[] = $sValue;
}
} else {
$mValue = trim( process_pass_data( $_REQUEST[$sItemName] ) );
}
}
if (!$mValue)
$mValue = null;
break;

in templates\base\scripts\BxBaseProfileView.php file.

And try to search with selecting "Not Specified" in search form as country name.

If it helps and no any negative effect on other functionality - then this fix will be included in next patch.

Alex,  I won't be able to test his until tomorrow because of a rare social engagement is getting me away from my computer for a change, but thank you for taking this issue seriously - can't wait to try it.

Rob

p.s.  HL - was it "Paris, Texas"?

OK, I am just starting to set up to test this, and right off the bat I have run into an issue.   I have added a field called "not selected" with a value of zero to two predefined tables I have - "industries" and "trade countries".  The way mine is different from what Alex has, however, is these are "multiple select" fields, and the example above is for a single selector dropdown.   On a multiple select field, there is no "default value.   I don't know why, shouldn't there be?

No.  That would have been too easy.

No there shouldn't.  In multiple select fields if a user doesn't select anything then nothing is passed ( I think it remains null).  So when you look at a profile you will notice that a multiple select field with no selection will not appear.

Ex. You have favorite colors: red, green, blue, purple multiple selection option.  If the user doesn't indicate a field, on their profile the Favorite Colors Field will not display at all.  Whereas if they select red, then on profile page it will show their Favorite Colors as red.

OK, maybe it will still work, but I can't find the code Alex says should be in templates\base\scripts\BxBaseProfileView.php

I looked at my records and can't see that I modified it elsewhere.   Could someone do me a favor and look in that file and give me the line numbers for that code.

Thanks

Rob

Could someone be so kind as to look in the file templates\base\scripts\BxBaseProfileView.php and let me know were the code Alex specified above is?  I am not finding it with my searches - maybe I am doing something wrong, or possibly Alex specified the wrong file, but could someone at least let me know if that code is there on your system.

Thanks

Rob

I think he meant: inc/classes/BxDolProfileFields.php

Bingo!   Still testing, but it seems to work.  See www.caltrade.com/community on the right side.   That is the search I wanted.   Thank you Alex - and also Maurice, HL, and other members here who supported and contributed to this effort.

Rob

Hard to believe it took so long to get a little bit of information about how to properly set up required fields, and get 2 short lines of code added.

It appears as though adding another search field using the '+' symbol, is an OR function.  It would be a really good enhancement to the search function, if the '+' were replaced with two buttons... 'OR' and 'AND'.

I know- I thought about that too, I think it probably took 100 posts to get those two lines of code.  At one point, I even heard that someone here was told this would be "impossible".   It was almost as tough to get the search functions working on D6 as you can see on this thread.   I haven't had time to test this thoroughly yet, but so far the only problem I have found is that if you use this technique with a multiple select field, there doesn't seem to be a way to make "not specified" field selected by default.  This means that while the user will still be forced to enter a value in that field, they could select "not specified" - not what I wanted, but I can live with it.

I also like the idea of having an "OR" function, so we could construct more sophisticated searches.

Ok, if it works, then I will include this fix in next patch: http://www.boonex.com/trac/dolphin/ticket/1816

regarding OR/AND feature, it is not necessary, it makes sense only for multiple select elements. For example now I can select to search people living in Canada and USA... if this feature will be available then I will be able to search people living in Canada and USA simultaneously but this is just impossible.

There is still a problem with this unfortunately.  When you use it for a multiple select field with "Not Specified" at the top, that will still be selected even though it is not highlighted, and even if the user selects something else.  This means that admin must go in and manually unselect that field as part of the registration process - kind of a pain that won't work for many here.   The searches that you can construct from this, however, do seem to work and that was important to me.

 Is there anything else that WE can do to make this perfect for YOU.  Perhaps we can set it up to notify all your contacts when your ready for your next networking call, maybe we should have it call your car for you when your ready to go home.  Seems to me for someone from silicone valley that you'd be able to take this item the rest of the way in.

Sorry folks, I see alot of people working hard on this topic and it seems that certain ones are just taking advantage of it, complaining, until they get what they want exactly.

@Mydatery.  If you have nothing to contribute here, then get lost.  Go back to writing your song lyrics or long essays.  If Alex or someone else at Boonex thinks that my discussing this function is inappropriate, then they are perfectly capable of telling me that.   As others here have tried to tell you, this is not a place for you to resolve your mental health issues.

What Rob?  Someone offers to help you make your site as you unique as you would like it, all for an amount equal to what you have financially invested into it's coding so far and you accuse them of health issues?  You know, now that you mention it, I have been having a bit of heartburn lately.  Which do you think is better:  Prevacid or Zantac? 

Great.  Somwhere in all this screwing around, my join form broke.  Now all it does is say there was an error.... but it doesn't say where.

Well at the risk of getting more hate mail, this is still an issue for me.   I'm doing some marketing to try to get more members and they all get that "not specified" selected now, even though they didn't select it on the join form.  I have to go in and manually unselect it when I approve their accounts.   Since my site is still small, it is not a huge issue at the moment, but obviously this is not a perfect fix.  I am happy to finally have working search forms so I won't be going back to the way it was, but I wish there was a fix for this..  I am almost afraid to test this when a member edits a profile to see if that "not specified" gets selected again.

So this is still a problem, right...as of 14 February?

The SEARCH part, that is. The ability to allow users to not select any non-mandatory fields has been addressed above (and I've made the changes, and my users can leave any field blank that they wish, which is good). But the SEARCH aspect wasn't addressed, right?

I have set up some non-mandatory fields with a 'blank' entry at the top. If the person does not want to share some information (height, weight, city, state, single/married, etc.) they can just leave it blank, and for them that profile's value is just 'blank'. And that works fine, if you never search then there is not a problem, it looks fine.

But when you do a search, you expect (because this is the universal standard way of searching) that leaving a field BLANK means "disregard this field & show ALL" (in other words, "use all of the other criteria but ignore this field")...but here it seems like leaving a field BLANK means "search only for those people who chose to leave the field blank". When a user leaves a field blank in a search, it ignores all of the profiles that entered a value for that field...and that is not what anybody wants. Right?

What's odd, is that (I think) if you leave 'City' blank, then it performs in the standard way (ignores that field), but if you leave any of my CUSTOM fields blank, then we have the problem above. If it can be done for 'City', why not just make it that way for custom fields?

I know it's easy for someone who is not an expert in php to say "it seems like it would be easy to fix..." and yet, I do feel like something could be done, even if it means something crude like adding a checkbox called "ignore" that you could check (as a very temporary fix, just to get this to WORK!) so that it would stop trying to match 'blank' (or 'not specified' if you did that) but actually ignore it. Or maybe somebody can just change the code, and make the search work like every other search in the world works (ignore blank fields).

Here's a thought: How about making it so that the webmaster has to go in and specifically put in the field value to trigger an 'ignore' (for me <blank>, for others 'not specified' or 'please select') somewhere manually, even if in the php code, so that a quick check could be done, and if during a search any field matches the 'ignore value' you manually added to the code, it just ignores the field (like it seems to do for City). Can somebody change the code to do that? Then tell us where to put our value to match (<blank>, 'not specified', etc.)?

I think searching for members is kinda the point of a social network site, and this should be priority one (or priority in the top 5!).

Can somebody do something for this?

- Mishka

Mishka, thank you for posting - I completely agree with you that member search is one of the most critical parts of any social networking site, and this issue should have very high priority.

Did you apply the fixes that Alex made above?  I'm pretty sure this makes the search functions work now.  See the front page of my site at www.caltrade.com/com - you can leave either of those drop down selection searches as "not selected" and it will only search the other one, and if you make a selection on both of them, it will find members with both those attributes.   I will be adding more searches today and will post if I find problems, but I am pretty sure that one works.

Fixing this, unfortunately, has made another problem though - with multiple select boxes on the join form there is no way to highlight "not selected" the way there was on D6.  Now on my site, "not selected" is a selection on every profile, and I have to go in and manually remove it - frustrating!

We have come a long way on this issue - there are a half dozen forum threads and blog posts.  I think this is close to being fixed but it is not quite there yet.  I hope this is not closed in Trac - I will drop Alex a note to see if I can get him to take another look at this.

Rob

Hi Rob,

I tested the search drop-downs on your community page, and to my amazement it worked properly. But mine doesn't work properly, and I just checked it again.

Yes, I did make the changes Alex proposed in this thread, but I'm not perfect and maybe I dropped a } or something! I guess I'll go check again.

The difference between your search and mine, is that yours uses ONLY drop-down choices...mine uses a combination of drop-down and text boxes. For example, there is a "Sex", "Orientation" (gay, straight, etc.), "Country", and "State" drop-down. Two of them have default values of "". (blank) And two have default values that are not blank (Sex has "Female", Country has  "United States" for the default)...but there is also a "City" text box. The city text box defaults to "". (blank) Oh, and there's the Age slider, but that's sorta its own thing!

So on mine you HAVE to at least change the Sex and Country fields to your own values, and the rest you can leave default values. But when I do a search with just Female & United States I get one person. When I add a state to the search it jumps up to more users. ??

I don't know if there is a difference between drop-downs and text boxes, or if I've done something wrong, but that's where I'm at, so it's still an issue for me.

What do you think?

Wait, I think I might have it...

I checked my Predefined Values tables...and for the State list, the "" value (blank value) had an ID of "1". There were no entries with an ID of "0". The list started at "1" (the blank entry) and continued on to 2, 3, 4... (the state entries). So I changed the "1" to a "0" just to see if maybe it had to be that, and I think that made it work properly. I've tested it a little and it seems to work how I'd expect.

So while the example showed the "not selected" value having an ID of 0, I was focused on the rest of it and didn't think that mattered (I guess I figured it was at the top of the list so it would assume it was the default or something...or more likely, I just wasn't thinking at all!

So perhaps that DOES bring this issue far enough to be functional.  

This solution unfortunately creates a real mess if you use a multiple select field.   When you first use the join form, the "not selected" (or "not specified") field will not be highlighted, but it will be selected anyway.  As an admin I then have to go in and fix this when I approve the account - not a good situation. What is worse - I have just confirmed, is when a member goes back in to edit their profile, "not selected" will now be highlighted, and if they then save their profile it will again have "not selected" as a real value in the profile - not a null or empty value.  Well this kind of sucks.  I am delighted that I finally have working search functions, but what a terrible trade off.   We have do decide if we want a dysfunctional join form or a dysfunctional search function.  As near as I can figure, it is still not possible to have both working properly.

Rob

Alex asked me to do more testing on this.  I have, and I can't find anything wrong with the search function now - it seems to work under several different scenarios.   The problem with the join form and edit as I described above, however, is a MAJOR headache.  My site isn't even all that big or active yet, and I am already getting those "not selected" as part of the profiles all over the place.  I don' think I can recommend this approach to others yet - at least not with "multiple select" fields.  This still needs some work.

Rob

I have to say that this issue has been solved for me (even though it hasn't been solved completely).

As Rob points out, the one way it doesn't work is if you have any 'multiple selection' fields AND they are mandatory AND there is a 'not selected' option. If all three of those are true, then it doesn't work properly. Luckily only two of my multiple selection fields (Single/Couple & Country) are mandatory, and neither of them have the 'not selected' option. So I might get the odd person who doesn't live in the US but their profile says they do, but that should be rare, and due to their own laziness for not selecting their country.

But Rob, who absolutely NEEDS a mandatory multiple selection field on their join/edit profile pages, won't be satisfied with this solution.

While this problem HAS been solved for me, I am still waiting in limbo on the other major remaining issue that Boonex must fix right away: Getting the Payments module working so that I can interface my membership & product purchases through CCBill (or whoever). When they do THAT, my site will finally be working.

Miska, that is true, but that is the whole point of this discussion - to have a "not selected" option that is mandatory. The difference is that some people will have a single select field, and some will have a multiple select field, and this doesn't work on the join form if you are using it with a multiple select field.  Alex wrote me back on this and said this:

It looks like join form uses old method of presentation in multiple select fields - using regular html multiple select fields - instead of custom one - and this cause some part of the problem.

I'm not completely sure how to interpret this - it sounds like something they forgot to do, or a mistake they made when they produced D7.  As I mentioned, this worked perfectly in D6.  This is not an obscure issue - I'm convinced that many, maybe most people using this script will encounter this problem eventually.  Alex says he will look at this issue "later" - but my site is starting to grow, and this is making a huge mess.  Can anyone think of what to do about this, or could I encourage Boonex to bump this in priority.

Thank you

Rob

Do we have any further info on this?  The empty value is quite important to my site.

thanks in advance,

Chri

It is really important for mine as well chriistanger, and I think more people will find that they need it too.   The last I heard from Alex is that he will get back to it "eventually".  All we can do, I guess, is "lobby" Boonex to let them know it is important.  Please write Alex and/or your agent, and tell them this is something you need.  Copy this link when you do.

Rob

You know, the more I look at this thread, the more annoyed I get at the ignorance level that is at play here, causing a massive waste of coding/development resources.  This is not a Bug.  This is not an item that should have been in the base D7 install.  This is a friggin' feature that someone, who is NOT Boonex, but rather a private individual, developed and they have a right to earn a profit from their work.  All this thread is about is people whining and crying because they are to cheap to open up their wallets and pay that person for their work.  This existed in D6 as a modification and I'm positive that modder has it for D7.

Now, to display this to you guys and hopefully you'll quit wasting AlexT's time, I'm going to give you an example of something we just did in hopes it makes sense to you finally.  If you need me to type slowly so you can see through all the tears in your eyes, let me know, I'll do it.

I recently, as of today, entered into a contract with HP to purchase a number of servers that we will lease out to our customers.  These servers are under and OEM type agreement (meaning they will have our name & HP's name on them with both company emblems).  So here we go, let's pretend this is a member signing up instead of a corporate contract for a moment.

HP is the site.

It has 3 different types of members.

Resellers                                                    Purchased Lease Agents                                  Retail

Now if you notice, that means 2 of them are commercial, one is retail.  So, we want something from each of these customer types, specifially information, but we don't want the same information.  Why?  Because they all have different purposes.

Best Buy is a Reseller

TDZ's is a Purchased Lease Agent

Billy Bob Jethro is a Retail Customer

We need Name/Address/E-Mail/Password on all 3 of these.

Resellers like Best Buy need to provide a Tax ID # to enable HP to wipe out the sales tax.

Purchased Lease Agent needs to provide Tax ID # to enable HP to wipe out the sales tax.

Retail does not need to provide Tax ID #, as they pay the sales tax and don't have a Tax ID #.

So, the Sales Tax is a Mandatory Field for 2 of the profile types and it is nulled for the 3rd profile type.  Hmmmm.... How do we do this?  After all, a Mandatory Field can not be Null, as Null is only utilized in Non-Mandatory Fields, if it's not null then it has a value and that is what your searching for is the value of the field.

So, how do we do this?  Also, how do we keep from confusing the Retail Customer with this Tax ID # request?  If it's Mandatory you guys want to set it to Not Selected (null/no value) which is then causing issues when your members are joining.  If it's  a multiple select item, it's really causing some problems as you have to hit the DB to fix each and every profile that selects Not Selected in these fields since it doesn't turn off.  Really, it means the Not Selected field is being selected automatically and not deactivating when other fields have been selected.

So again?  How in the world does this mess get fixed and provide a clean join page along with a functioning search page?  The answer is really, really simple and I've been saying it for weeks, but certain individuals are far to cerebrally damaged to get it.  So here we go again.

PREDEFINED DEPENDENT VALUES

Should I say it again?  AntonLV Developed this for D6 and it works perfectly.  Automatically nulls out the fields that don't apply and makes them unselectable at all.  This means that The Reseller and Purchase Lease Agent will have to input the Tax ID # and the Retail Customer will not even have the field appear.  It's not that difficult of a concept.  You get the null value on a friggin' mandatory field for the member it does not apply to and you get the field requiring a value on all the others when joining/editing the profiles and when a search is conducted.  Best of all, you get it without the errors.

Now, since Anton developed this on his own time, it's not fair for Boonex to take it and install it on D7 just to satisfy a few people.  On D6 this cost $40.  I'm thinking it will be a similiar price for D7.  As I see it, you have a choice:

1.  Get ahold of Anton and pay him to do this for D7.

2.  Go learn how to do it yourself.

I'll be honest. I don't care about this whole mess, but reading this topic puts a smile on my face.

[edited out by Andrew Boon]

If Boonex wants to make the decision that this basic database function should be a commercial module that everyone has to purchase, then that that is their call... [edited out by Andrew Boon]

For what its worth mydatery, this is one of the reasons holding me back from purchasing a license.  My intent is to buy a license as soon as my site is ready.  I think a lot of people are in the same boat as me.  I'm not asking for a full rewrite of the code, just for me, but rather an improvement that all users of dolphin can benefit from.

MD, you just wasted a lot of typing.  Dependent fields really has nothing to do with the topic of this thread, nor is such capability a solution thereof.

@HL - No, it doesn't have a thing to do with it - but that is not why he posted this - but thank you for pointed that out.

@christaeger - lots of people are in the same boat - it is a basic database function.

@mydatery - [edited out by Andrew Boon]

[edited out by Andrew Boon]

[edited out by Andrew Boon]

It's going to take quite a while for D7 to stabilize.  I just looked at the tickets for 7.0.1.  There's 216 of them!  I honestly don't see how some of the D7 developers find the time to work on mods, when there's so much to do with the core product.

[edited out by Andrew Boon]

I think this would be a good time to repeat my earlier post, because it illustrates the problem perfectly. Here it is:

You should quickly find out, that there is no way to search for profiles in a city named 'Paris", while completely ignoring the 'Country' Field.  To put it simply, what this thread is asking for, is a way for searches to ignore the 'Country' field.  (Country being used only as an example)  The only way to find that other profile in a city named Paris, would be to search each country separately, and no one wants to do that.

The first part of the issue, I believe, has been corrected.  The first part of the issue was that forms could be submitted without any user input in required fields.... basically the D7 script would select the field value for the user, when it should be the other way around.

Simple problem.... not so simple solution.

[edited out by Andrew Boon]

[edited out by Andrew Boon]

And HL, I understand what YOUR talking about and it has a different solution.  But Rob is specifically talking about different types of members having different types of profile field questions to answer on the join form.  If he'd take a moment to quit arguing and actually read what is being said, he'd see that.  He's literally spent way more time on this topic to get it for free than it would have cost him if he just did what he was instructed to do along time ago.  And this does effect the searches also, not just the join.

Pay attention Rob.  A Predefined Depent Values list, AKA Dependent Fields, will give you the profile join/edit functionality of a mandatory field with your null value for the individuals that certain mandatory fields do not apply to and it will also give you a stable search functionality for your site.  This means that fields that do not apply in the search will not even be searchable.

Example:  If your looking for a member in Canada, why would you want the 50 US States?  If your looking for a member in Ireland, you wouldn't need the state field at all.  Amazingly, for someone who's trying to block you, I can't believe I keep trying to explain this to you.

Houston, what your talking about is having a Not Specified value for the Parent Category on the "Search" form while still being able to search the Child Category DB wide.  That's the only way anyone can find that profile, unless they did a search for Paris in every country, country by country.  For yours, a Predefined Dependent Value (Dependent Fields) would not work as the solution.

We actually have 2 completely different things going on here.  Rob's issue with his join form and certain mandatory fields not needed and HL's fun little quiz which is more of what AlexT's post applies to here.

[edited out by Andrew Boon]

[edited out by Andrew Boon]

Could someone remind me where the trac is on this - or just verify that it hasn't closed.   I want to make sure this is at least being considered for D7.01.

Rob

Nevermind, I found it and it says it is closed!  Alex, there is no way this works for multiple select fields.  I will give you an account on my site if you want to see.  As already explained, the search now works, but the actual words "not selected" get selected every time someone edits a field.  Could someone re-open this ticket please.

I changed my countries list in the pre-defined values as follows :

And changed the field as follows :

When a new subscriber leaves the field 'country' (which is set to mandatory) unselected in the join form, no error is being returned.

In the search form, the 'please select' is not the first element in the dropdown box, it is the 'AE' field.

How can I change this ?

This has created a critical error on my site.  Now whenever anyone edits their profile, they get the "not selected" as an actual value - essentially ruining my site.  A detailed blog post I wrote up on this issue was deleted by Boonex, as was a more recent completely polite comment on the Boonex blog asking if this had been fixed in D7.0.2.   The trac on this has been incorrectly closed and if you look at it you will see it has been opened and closed at least a half dozen times.  I wrote both my agent and Alex and gave both access to my site.  Alex wrote me back saying that "it worked" but when I showed him how the very record he had edited now had "not selected" as an actual value, I never heard back from him.  I even made a post in the "disputes" section of Boonex to try to get them to address this but they didn't respond.  If you look around here on Unity, you will be able to find probably a dozen or so other posts where people have raised this issue - all have gone unresolved.   I have no idea what to do about this - Boonex seems to want to fix this serious bug by "proclamation" for some reason - just pretend it doesn't exists.  I still believe almost everyone building a site with any level of sophistication will encounter this sooner or later.

yes I got same problem :-( hopefully this will be finally fixed in 7.0.3 but there is not ticket for that. Can somebody with premium post that as bug ? thx

Sure you will encounter this problem AND other problems when you add fields in your join form. I started with the complete script and ended up with a nearly 'naked' one. Stripped away all the modules and options that don't work properly.

I'm left with a site that offers poor options, not even worth the name datingscript nor community script.

@freakpower - there already is a ticket for this but it has been falsely closed several times.  They keep proclaiming that this problem has been "fixed".

@Anne - I am going to have to upgrade, and then dumb down my site also.  Really frustrating for something that worked fine in D6.

annabel: is it really that bad even with 7.0.2 ?

CALTRADE: uhmmm . well...what to do ... there is clearly a problem... boonex staff have to see it .. dont understand why its not traced as bug if there is certainly prob... booonex ... some answer please here ?

Yes Freakpower, it is that bad. On first sight, everything seems to work properly. But from the moment you go online and start testing things with real members, the problems are coming on the surface. Especially when you start making minor modifications such as adding or deleting fields. Even when you disable certain options, the misery is just beginning. You have to go deleting items from the database which is tricky when you want to do an upgrade afterwards.

I'm keeping logs of all the changes I make and believe me, I have lots of them. I even have an unvisible mirrored version of my site running which I use for testing purposes and upgrading before I dare to make changes to the visible one.

Isn't that stupid ???

This issue is not trivial and assumes a few serious changes. I'd like to acknowledge that it is still considered as a problem here and we will work on it. At this point 7.1 is the most likely candidate to get this addressed, but 7.0.4 is also possible.

The ticket is now here: http://www.boonex.com/trac/dolphin/ticket/2179