Mandatory Location Field (profiles)

Would it be possible to have the possibility of making the field in profiles?

  • 1288
  • More
Replies (12)
    • Hello Baloo!

      No, because Location depends from user's choice in broswer and UNA can't influence on it. So required Locaton will block form's submit. It will be more easy to make field where user will write his location manually and make it required.

      With the best regards, Leonid

      • Hello Leonid, I understand your answer, you're right, so it's better to create specific fields.
        So, I will make the same remark as for the birthday which was not a standard field in the first versions of UNA.
        See here this discussion: https://una.io/page/view-discussion?id=326
        On Dolphin, look, there are a lot of modules that are based on the fields " #Country ", " #City "  #zipcode  ".
        So I fear that if everyone creates their own field, developers can not exploit them in future modules.
        Would not it be better to include them in standard fields to avoid this? ( especially since we already have country )

        • Could someone answer me on this question so that I know in which direction I have to go?

          • Hello Baloo!

            Well, in Location case it's more specific point - cause if leave it as text field then some users may fill it with errors. This is the common problem, so making this field as "automatic filled" or "unfilled at all" is more proper for using. Or you may show us your thoughts about how should work this location field which filled manually.

            With the best regards, Leonid

            • Hello Leonid. In fact in my case, dating site, the location is really a crucial point, that's why I must absolutely make it mandatory and accurate because the research is essentially done on this point.
              So I will say that the Google API has some negatives for me

              1. Lack of precision of the research, Belgium is a small country composed of 11 provinces, Google does not locate unfortunately by provinces, but by regions.
              2. Can not make field mandatory.
              3. Limited number of queries per day, often on my site dolphin the "ZIP Search" module stops working because I have exceeded the number of queries every day.
              4. Addiction to google for a crucial point ... I do not like it.

              In addition, if for now my UNA site is currently in demonstration, I do not despair to migrate my site doplhin one day ...
              So, explain to me how I'm going to migrate my 16,000 dolphin accounts -> Una with a (hypotetical?) Migration script if the fields are text type on one side and google API on the other.
              So that's why, I wondered if it was not possible to include the traditional fields "Country", "City" zipcode "as they exist in Dolphin.
              It's not hard to do for you, and, I repeat, with standard fields, it would also open up possibilities for future third-party modules.
              Especially since you have already included the field "country" ... Do you understand my point of view better?

              • Do I really have to create his own fields or go do it yourself?

                • I come back to this question, I would like the fields "country", "state", "Post code (zip) is included as standard fields as is already the case for countries.
                  The current "Location" field is not suitable for profiles, because:
                  1. It can not be made mandatory
                  2. Location field is very imprecise for small countries like mine, google only separates two or three regions, we have 6 provinces / regions.
                  3. Many modules on the boonex market use these fields, and among others, many modzzz modules.
                  In addition, it will never sell modules based on a field that can not be made mandatory, and can not create them either if the fields are not standard.
                  Why do not you add these fields? Does not the one who does not need them disable it so complicated for you to add them?
                  They will be essential to all webmasters who need precision on their profiles. Thank you

                  if you are not convinced, visit at random 50 profiles here, you can not see that nobody has completed this field except for a few rare exceptions.

                  • When I was with Dolphin... I used this module for that. https://www.boonex.com/m/Dependent_Fields

                    I do not understand why UNA would use Google, they are EVIL! What's wrong with OpenStreetMap, it's open-source.

                    • Well thank you Nathan because there is no better example than the one you quote, it is the perfect illustration of what I said in all its aspects.
                      And the author of the module, AQB, says this:
                      "This mod allows you to create dependent fields. Did you ever dream that during join member able to select country and then in the next fieldstate from the list of states relevant to the country chosen above? That is what this mod allows. You can create infinite level of dependency.For example Country->State(Region)->City->School->Class. And after choosing field value in the parent field user will see in dependent fieldonly values that you've defined exactly for this value of parent field.And this mod applies to join page, profile edit page and search page."
                      And you're right, the privacy of the data takes for his rank with a Google location, especially in the case of profiles. blessed bread for this vampire of data. It really does not fit, which makes the 4th argument.

                      • The main reason for State and ZIP fields haven't been added as default set is because those tend to change frequently and need constant updates. That said, I can see how it can be an issue, and also concur that we need to implement openstreetmap.org as the default alternative to Google API, especially now that they've changed free quotas so drastically. 

                        SO, here we go - https://github.com/unaio/una/issues/1519 

                        • Ah! Super mega great! Thank you Andrew Boon !

                          • Sweet thanks Andrew

                            Login or Join to comment.