Numeric field type
We had an old discussion about adding new type for a custom field - numbers:
http://forums.wildapricot.com/forums/308920-archive/suggestions/8834458-create-numeric-fields-7304
When we started our analysis work on this problem, we realized that we have no clear vision of what is underlying problem that our clients want to resolve with this new field type.
Most comments were about export into Excel, so it can properly recognize numbers. But from our point of view, export itself is a workaround to another problem - something is missing in Wild Apricot functionality and you try to substitute it with export. This means that adding new field type will not truly resolve initial problem, so at some level it's not a real system improvement and we usually try to avoid such system changes.
On the other hand, we might miss something important and Numeric field type can really be useful and fulfill some of an organization necessities (please, do not mix Numeric type with dates and other field types - for dates we can clearly see scenarios). For example, to validate user input when your members apply for membership (but in this case what in particular the field is about?)
So can you please help us:
1) We need your reasons and examples of why your particular organization would benefit from having Numeric field - ideally, not as a workaround of a bigger problem.
2) Do you need to have ability to search on this numbers like "less" or "greater" or "between"?
3) Do you need integer type, decimal or both?
4) Do you need special validation rules for the field like "cannot be less than..." or "not greater than"?
AdminApricot Kernel
(Product Manager, Wild Apricot)
shared this idea
This is on hold as of now. We analyzed and even prototyped a solution some time ago, but our priorities changed and now we’re focusing top-voted items – and this one has to wait its turn. But we will get back to it at some point, just cannot tell when yet.
19 comments
-
klm
commented
A current issue of mine is to search for zip codes within a specific range. Being able to all for between 21000 and 21200 is much easier than "starts with 210 or starts with 211 or starts with 212"
-
Barefootgal
commented
Understanding that this is on hold, but wanting to add my two cents... I have a number of clients that are chapters of a national association. In order to become a chapter member, you have to be a national member. So when someone fills out an application, we want to collect their national member number. As it stands now, they can just type "none" or "pending" or anything else. We need a field that can only accept numbers, not letters.
-
Rob
commented
We are an alumni group. Much of our communications is based on class year.
I'd like to be able to search for people who, for example:
-graduated before 1970
-after 2000
-between 2014 and 2017
-entered only a 2-digit date instead of 4-digit (field value <100) -
epadin
commented
Help! the Viper 640 Class Association is a group of boat owners who identify our boats by sail numbers. I have created a common field for sail numbers, but when creating a layout, the sail numbers are alpha and not numeric. As such, 23 is followed by not 24 but 230!
Please add the capability of a common field that is a numeric datapoint and please let me know when it's done so I can convert my data.
Yes, there are workarounds, but WA would be more effective for us were this possible.
Thanks,
Ed Padin
-
Malcolm de C
commented
We are a golf society and I am working with two other societies who use the Wild Apricot. For every member we capture his or her golf handicap, which takes two possible forms. Firstly, an exact handicap (1dp) and secondly, a playing handicap (0dp, rounded up). We need to able to sort on handicap and search for members in handicap ranges (or less than or more than). We cannot do this without a numeric field
Handicaps typically range between 0 (scratch) and 45 but as a further complication, which I don't expect Wild Apricot to address, a player who is better than scratch can have a 'plus' handicap (e.g. plus 2). I would be happy to accommodate this as a negative number, so, ideally, the numeric field should be able to accommodate a negative number for sorting purposes. -
Thanks for the reminders, Walt :)
-
Walt Bilofsky
commented
Today I am trying to add up the number of people at an event who are participating in three different activities.
Because there is no numeric field, some of them type "Two" instead of 2, so I have to change those so they will auto-sum in our hand-coded workaround.
If I export to a spreadsheet, even "2" comes in as text, so I can't add them up in the spreadsheet without a lot more work.
-
Walt Bilofsky
commented
I just started to draft an email blast to members in nearby zip codes.
Then I realized I could not do an Advanced Search to select them because the zip code is not a numeric field. :(
Your design example is for numeric field in registration forms. But I hope you will also provide it in contact and membership fields.
I think you will satisfy most of our needs with a simple integer field that accepts any number. And you already know my feeling that a partial solution now is better than a full solution later. :)
-
Stan Maupin
commented
Are you kidding......export is a workaround for another problem???? That may be YOUR view of export, but it is not other peoples UNLESS you plan to replace all other software and all other uses of data. So, if i want to produce graphs or tables of data i want to store in WA, i have to wait until you add an excell-like package to WA? Your view is focused on what works for you - keeping people dependent on WA - not what works for the customer. Tell me another major software program of any kind that does not have number fields.
-
I hear you, Walt.
-
Walt Bilofsky
commented
Evgeny -
I have a specific suggestion for action on this, and then a general comment.
Specific suggestion: We could use the extra charge field (not shown in your design) as a workaround numeric field, if you would just let us set the dollar amount to zero (and for extra credit, don't show the money calculation if it is zero).
I would rather have a workaround soon than a complete solution years from now.
General comment: You said "But from our point of view, export itself is a workaround to another problem - something is missing in Wild Apricot functionality and you try to substitute it with export. This means that adding new field type will not truly resolve initial problem, so at some level it's not a real system improvement and we usually try to avoid such system changes."
I suggest this is exactly the wrong thinking. WA is never going to do everything for everybody. And any improvement you make is going to take a lot of time. Please make it easier to work around the lack of features that you haven't had time to implement yet.
(Case in point: Listserv, where several small changes would get us most of this needed functionality, but instead we are still waiting.)
-
Walt Bilofsky
commented
Because WA's event registration lacks flexibility for multiple guests, we use numeric fields to specify the number of adults and children on a registration form (for pay-at-the-door events, of course; for prepay we use additional purchase).
We use numeric fields for year of birth, and would like to be able to search on this numeric value.
-
Walt Bilofsky
commented
The old thread had 13 votes. Hope they are still being counted. Any idea when this useful feature will make the roadmap?
-
Brandon Longley
commented
In response to your question, these are my reasons to wanting to be able to sort number fields.
I have an amount of financial information that I was able to consolidate from a relational database into a flat spreadsheet that can now be imported into Wild Apricot. This contains history for each contact such as the first date they became a member, amount of money they have contributed to memberships over the years, the number of years they contributed as a member before the date that Wild Apricot began being used. Etc.
This is an example of the data that I would be importing;
Member Since Last Date of Membership Years Contributed Membership Contributions Donation Contributions Last Donation Date In Volunteer System
1/07/1990 30/06/2014 19 $606 $0
NOSince there are over 12000 contacts in the legacy database from history we are only importing 500 or so, so there will be an archive which we're going to refer to in excel however it would be good to have easy to refer to details about the active contacts on Wild Apricot and be able to create advanced searches according to those details.
To be honest it is a workaround to empower users with the historical information, however it would be useful. Otherwise, I'm happy to just keep it as a flat reference with no sorting capabilities. I understand and that there are many more important things to be working on than a workaround for something that doesn't directly improve the current processes in WA.
For instance, I can see that this already exists to sort donations captured within WA.
I would rather that development be put towards functions that I really need like recurring donations.
-
jean sennett
commented
I'd like to see a numeric field type as well. Our group is a golf organization and some of our tournaments are open only to members with handicap indexes below a certain number or in specified ranges. With the handicap index in a text field I can't create the saved searches I need, such as all members with handicap index less than 15 or members with a handicap index between 4 and 8.
-
Brandon Longley
commented
I have been looking for a solution to migrate financial history into Wild Apricot and I have found an easy solution however it requires that one or two small features be implemented.
I would like the ability to create custom Common Fields, with the option of number formatting in addition to the current text formatting. I would also like the ability to create custom advanced searches using this number field as the criteria.
The reason for this is I am importing a bit of financial donation history for pre Wild Apricot and want to be able to use the fields to sort number amounts, namely currency.
For example, they are currently text fields and the only queries you can create are for text based queries, 'contains, is, does not contain, is, is not' etc.
With number formatting, we could create queries that use, 'is less than, greater than, equal.' etc.
What do you think Wild Apricots, or is this actually a thing and I've missed it?
Is this feasible?
-
Jarren Kinch
commented
My organization could use this and other validation. Some possible uses:
Phone numbers
Zip codes
Age
Member number (we are a state affiliate chapter of a larger national organization that our members must be a part of, and we need to know what their member number is)
I'd also like to see text validation, such as making sure that email addresses are valid, "other" text fields are only filled out when the "other" checkbox is selected, names are capitalized, and phone numbers are formatted correctly (###) ###-####. Some of these are just pet peeves, but they can make scanning info much easier and faster.
-
Thank you, this is exactly was I was trying to understand - your example of membership age is exactly what I was looking for to justify the change and understand context of the problem.
By the way, on our technical language we call what you have described as "input data validation" :)
-
Gordon
commented
I suspect that I was the one that originated this post years ago.
The request was to provide a field that requires numeric input. This means that any attempt to enter a character that is not in the 0-9 range is not allowed.
For instance, I could have an "Age" field in my member database. When people enter the age they are liable to enter "21" or "21 years" or "Too old". When I export this to Excel I may want to calculate an average age for my membership. With the current setup I cannot do this without going through the entire file and removing the non-numerics by hand.
I cannot see that specifying limits on the (greater than. less than. etc) would add significant value beyond plain numerics and would greatly complicate the setup.
To answer your questions specifically.
* So people don't enter alphabetics when we want numbers.
* Not if it delays implementation
* They should be able to enter 2.5, not sure if that's integer or decimal;
* Not if it delays implementation
