Loading...
 
Features / Usability

Features / Usability


Looking for a way to construct a form for users to fill in

posts: 210

Hi,

I am looking for a way to construct a wiki page that ordinary users (anonymous) can fill in in order to support the org that runs the Tiki.

Therefore I need a couple of checkboxes (for the amount to be donated, for instance), one free numerical field (also for donations) and some free text fields like name & address.

Then I need some structured fields like Zip and IBAN.

In the first, easy, version this shall lead to a button that simply calls a mailto with the values pre-filled, directed at the org. So in essence a digital twin of a form printed in a magazine.

In the second, more sophisticated version these data shall be stored in the DB. Trackers seem to be a solution, but this would violate the PCI DSS directive (it is a violation to store credit card information of persons in the same database as the base data like names & addresses).

Calculating the check digits of IBAN (3rd and 4th digit) to eliminate typos by the user would also be helpful, or detecting wronly formatted Zip codes.

posts: 55

Hi hman,

I just did a similar thing (custom mailform). You will have to use trackers. This thread ([solved] How to use "Contact us" feature? Activated - and now?) gives you a lot of hints and links you'll need to understand how it works. There are many possibilities with the field types, I'm sure you'll find what you need. However, I don't know how to solve the PCI DSS problem - the rest should be doable I guess.

posts: 210
FootlooseTraveller wrote:

Hi hman,

I just did a similar thing (custom mailform). You will have to use trackers. This thread ([solved] How to use "Contact us" feature? Activated - and now?) gives you a lot of hints and links you'll need to understand how it works. There are many possibilities with the field types, I'm sure you'll find what you need. However, I don't know how to solve the PCI DSS problem - the rest should be doable I guess.


Thanks, I will read your link. For the PCI DSS problem I believe the only solution is either organizational, so an org must process card information very quickly and delete card information, that it keeps on record somewhere else, or a feature request from Tiki devs to enable Tiki to have some trackers run on a separate DB...

hman


posts: 8503 Israel
hman wrote:
I am looking for a way to construct a wiki page that ordinary users (anonymous) can fill in in order to support the org that runs the Tiki.


I don't see an easy way to solve the "PCI DSS problem".
Or you do the full monty or you use a third party company that do it.

I have a Tiki23 using tracker forms (order, subscription) with an URL to a third party company that do the transaction and return me a success confirmation. Of course it cost something but they do everything needed to comply legislation and produce digital invoices.

Another alternative is to embed a Paypal (Donate) button.


posts: 55
Maybe you could use a second tiki with a separate database and in the process of your order, forward to the other tiki to process credit card info and forward back to the first tiki to finish the process... just a thought...

posts: 210

There is a problem with the use of trackers for a form: The order of the fields seem somewhat "ordered" by random. Even if you meticously create tracker elements in the correct order (that is: The order of the form) the results get ordered by some other, obscure, criterion. It is not the ID of the elements. As primary keys I would have expected that all reports etc., unless specified otherwise, be ordered by ID. But they aren't.

Since MySQL does not store creation timestamps for table rows (and tracker elements are rows) creation date/time is not relevant (this can also be ruled out by painstakingly taking care of creating all elements in the correct order, even then the results seem randomly "ordered".

At the moment I cannot spare to time to dig that deep into Tiki's source code to find the precise SELECT that lies underneath. I consider this to be a bug, and it's a bug that renders trackers unusable for more complex forms.

posts: 3656 United States

If you're using the Tracker plugin to display the form, by default the fields are listed in order of the field IDs. You can easily override this by using the sort and fields parameters.

For even more flexibility in designing a tracker form, take a look at Pretty Trackers — you can fully customize the tracker form however you want.

HTH,

- Rick | My Tiki Blog | My Tiki UserPage

Why be a dummy? Get smarty! TikiForSmarties.com
Tiki for Smarties, your source for the best (and only) Tiki books, guides, and tutorials.
posts: 210
Rick Sapir / Tiki for Smarties wrote:
If you're using the Tracker plugin to display the form, by default the fields are listed in order of the field IDs. You can easily override this by using the sort and fields parameters.


Thanks, Rick.

But there are some problems. First: The default seems not to be by element ID. In fact, not even the tracker admin view does that. Sorting by element ID is set, but still tiki-admin_tracker_fields.php?trackerId=ID displays all field in a random order, which makes form design a tough job.

I tried to analyze what exactly the order is. It is not the order of field creation time, I could reproduce this by erasing the tracker and recreating it piece by piece in strictly the correct order. Also, in theory time creation couldn't be the reason, as MySQL does not store creation timestamps for records. I could not find any other order that is used. It's not numeric, it's not alphanumeric, so in lack of a better description I have to call it "random".

This tracker has 18 fields, so the order is of the essence. For instance, there have to be more than one field to store user consent (By law, consent to billing has to be separate from consent to membership, and consent must have date/time as entered by the user). If the order is broken, the form becomes useless.

Also, the records created in this way cannot be viewed with built-in tools like tiki-view_tracker.php: Same problem, seemingly random ordering of fields.

posts: 210
Bernard Sfez / Tiki Specialist wrote:

I think the order the tracker fields are displayed is the same as the tracker list view (it was at some point).

Try to move up and down (save, empty cache, force refresh browser) and check.


Yes - but tracker list view also presents the fields of trackers in a seemingly random order! Even though default order is set to "by ID", "ascending". It just does not sort as instructed. Reproducibly. Several times I erased the entire tracker, and repopulated it one by one. This works as expected up until (if I recall correctly) the 14th field.

When you enter tracker fields one by one, they will get incremental IDs, so tracker list view MUST display them in the order they were entered. At some point when entering them, the order breaks. Every time (and always at the same field - so the content of that field's definition obviously plays some role, but I could figure out what that role could possibly be).