Can I set client's account data as table fields?

[tinfire]

Hi everyone. I am now exploring Form Tools and I'm amazed how many aspects it takes into account to have a form running smooth. A wonderful piece of software!
This is a 'how' question. I have made an internal form with a couple of users (clients) and want to filter the submissions - each user edits its own. I guess this should be accomplished by preparing a separate view for each user and putting a client map filter in it. Unfortunately, I cannot find a way to match the filter "core fields" with some submissions table field - no client data there.

How can I set client's account data (username, etc.) as table fields?

[Ben]

Hi tinfire,

Welcome to the forums!

haha, I never cease to be surprised at the ways in which this script is being used. What you described makes total sense, it's just that it wasn't expressly designed for it. But okay, let's try and figure it out.

I have made an internal form with a couple of users (clients) and want to filter the submissions - each user edits its own.... How can I set client's account data (username, etc.) as table fields?

So yes, the Client Map functionality is usually what you'll need to look at. Ordinarily, people use that in conjunction with an External form, then just include a hidden field containing a value that can be mapped to each client account when they log in, so each client sees different data depending on what info is in their account. This is cool because configuration is minimized: you need a single View, that's all.

But this obviously won't work in your case. So here's an alternative.

The Views now allow you to define default values for the submission field values. What you could do is create a new field in your form called "hidden_origin" or something like that. Create 2 Views, each defining a different value for that field: say, for client 1 have that field load up with "client1" and with client 2 have "client2". Don't bother adding that new field to a View - we don't want it to ever be editable - just initially set when the submission is first created.

So far so good: at this point, each submission will have one of those two values stored in the hidden_origin field depending on which View they were created with.

Next, map each View to a client so they can only see one or the other View.

Finally, create a Standard Filter to each View that limits the results to only show values with hidden_origin = "client1" or hidden_origin = "client2".

After all this is done, when each client logs in they'll see the same form but a different set of submissions. Anything one client creates will never be visible by the other.

Clear as mud?

- Ben

[tinfire]

Fast response! And is as clear as crystal, Ben! Thanks a lot.

I've tested your proposal for two clients and it works fine.

The solution for internal forms really needs separate view for each of the clients. I wondered how the external forms are OK with a single one (using the client's login procedure).

So yes, the Client Map functionality is usually what you'll need to look at. Ordinarily, people use that in conjunction with an External form, then just include a hidden field containing a value that can be mapped to each client account when they log in, so each client sees different data depending on what info is in their account. This is cool because configuration is minimized: you need a single View, that's all.

I'll try this later.
Thank you, Ben!