Agghhh.. FILTERS!

[FoundByDesign]

Is there any way to move the "Filters" back to the Edit Client page? The new setup requires me to add a client, then add a View, create a filter and THEN I can apply that view/filter to the Client.

My basic plan is to use one Form, each submitted with a unique User Id number (which will be the same as the client's login) so they can only view/edit the submissions that match the ID. With 1.x I could easily add a filter per client by adding the new Client, granting permission to the form and then editing the client... simply choose the form and create the filter! Done!

I would love to use 2.x, but for my use it appears to have complicated things! Is there any way to move this around? Am I the only one that is missing this?

[Ben]

Hey!

Sorry you're running into trouble! But I'm afraid the short answer is no, the filters can't be moved back to the clients page. Associating the filters with the Views rather than the client gives you so much more control, I wouldn't want to move it back. The functionality it affords by

Plus of course, you only need to define a particular View once. Previously, when you assigned a filter to a particular client, it would have to be done for EVERY client. Now you just assign the View to the client (which can often be done by just setting the View to "public").

I guess I don't fully understand how this is such a problem for you. First off, how often are you creating clients? Does each client have their own unique filter, or do some clients have the same filter?

Are you maybe manually creating each View each time? If so, bear in mind you can create new Views based on existing ones by picking the View in the dropdown list on the main Views page. So it seems like these are the only steps required for your task:
1. Pick an existing View from the available Views dropdown and click the "Create New View" button,
2. On the "main" tab, change the View name and assign the client,
3. On the "filters" tab, enter your filter.

Let me know if this is no help - I'd like to better understand your scenario!

- Ben

[FoundByDesign]

Hey!

Sorry you're running into trouble! But I'm afraid the short answer is no, the filters can't be moved back to the clients page. Associating the filters with the Views rather than the client gives you so much more control, I wouldn't want to move it back. The functionality it affords by

Plus of course, you only need to define a particular View once. Previously, when you assigned a filter to a particular client, it would have to be done for EVERY client. Now you just assign the View to the client (which can often be done by just setting the View to "public").

I guess I don't fully understand how this is such a problem for you. First off, how often are you creating clients? Does each client have their own unique filter, or do some clients have the same filter?

Are you maybe manually creating each View each time? If so, bear in mind you can create new Views based on existing ones by picking the View in the dropdown list on the main Views page. So it seems like these are the only steps required for your task:
1. Pick an existing View from the available Views dropdown and click the "Create New View" button,
2. On the "main" tab, change the View name and assign the client,
3. On the "filters" tab, enter your filter.

Let me know if this is no help - I'd like to better understand your scenario!

- Ben

First off, let me say no one has ever told me no in a nicer way! lol

So here is my scenario...

I am using FormTools to create a application service for my clients. However, I am using one install and one form for simplicity sake, with a unique code identifying the client's submissions. This happens to be the client's username (which I am assigning as a number and have prevented the ability to modify - see other post about that mod) and this code is hidden in the fields.

This means that I need a unique view/filter for each client based solely on their username. While I have not yet determined a way to hard code this into the program itself (that would be awesome if I could!), the ability to quickly add the client and the filter saves me trouble and time.

For the time being, I have gone back to version 1.5.1. I will watch as 2.0 grows and matures and see if my needs are better suited in future versions.

Thanks,
Ed


ps... I am hoping to be adding clients VERY regularly soon! Wish me well in that aspect!

[Ben]

Heya,

Thanks for the clarification! Interesting case... It seems like what would be ideal would be if the Filters feature could be more dynamic; e.g. you could feed a variable into the filter itself, which would (or could) be different for each user, depending on their values. Hmm... neat!

So, for example, a dynamic filter would be defined something like this:
Field: FIELD A
Operator: Equals
Value: {$client_id}

The "{$client_id}" string would be converted to the appropriate value for each client, which would then automatically limit the results based on the client's own ID. Assuming that the client ID was included in the original form submission, you'd only need to define a single View for all clients which would, well, kick ass.

My only reluctance to implement something like this is that it seems so very custom and would really only help 0.1% of Form Tools users... on that note, can you think of any other cases an approach like this would help? I like the idea, I'd just like to think of some more uses for it & I'm drawing a blank.

- Ben

[FoundByDesign]

I think this would be applicable to a larger audience than you think. While I only plan one form to be used by a large number of cleints, I see other opportunities where others may have several forms with multiple users that can only view specific items. Otherwise the idea of filters and views would be useless anyway.

Besides, I bet with the dynamic option, people WILL find a way to use it! Afterall, years ago most poeple didn't see a need for dynamic websites and look at us today! lol

If you can point me in the right direction, I'd be willing to help where I can in the development. But I must admit I am not as familiar with your code as I'd prefer to be at this point.

Ed

[piecealava]

Ben,
This is keeping me at formtools 1.5 also... It's actually the backbone of how i'm using form tools.

Could you shed some light on how I could go about setting up this dynamic filter you were speaking of....

PHP Code:

Field: FIELD A
Operator: Equals
Value: {$client_id} 


it sounds like exactly what I need, but I have no idea where to start!

Thanks again for all of your great work!

[brad]

Ben - this is similar to the function I want to achieve, so that the form submitter can only view results for their submissions only. In a way creating a filter = $username ??

[futuremedia]

this is the way i use form tools as well, i also can't upgrade to 2.0 with out a lot of work and losing more features (that i would use) than i would gain. i assumed most people were using this method!
let me explain how i'm using it and offer two use cases as examples of why it is an efficient way to go about things.

-example-
to simplify things a little let's say we are a franchise like kinkos, bob goes to the kinkos website and finds his local store, these individual stores represent clients in FT.
bob sends a contact form from from the seattle store, it has a hidden field, 'store' with the value 'seattle'.
FT has a single contact form and the clients are filtered by the store field.
seattle and new york can see their own contact forms and corporate can see them all with an unfiltered account.
when a new franchise signs up it only takes a single step, creating a client account to get them going. to get the same functionality in 2.0 you have to create a client a view and an email that is based on the view for each new franchise. not a huge deal, but i have to do the same when i upgrade - we have 150ish franchises. that means 450 steps instead of 150.

-use cases-
say i want to add a new field to my forms - in 1.0 i just update the form and email with the new field. in 2.0 i update the form, 150 views and 150 emails.
in 1.0 if i want to change the displayed columns i make one change. in 2.0 i make 150.

these are sort of production line problems, i have other forms that have fewer clients that these new fangled features would benefit. the high volume widely dispersed production line forms are the ones that generate leads that actually bring in money though. there isn't another way to achieve the same results as simply, at least not that i can figure out.
being able to put a 'client variable' in the view filter would be a perfect solution. the emails also would need to have a 'client email variable'. then a single view and a single email would be able to do the work of 150 each.

in reality these aren't just contact pages, each is a full blown web site with half a dozen forms each. all of the forms on these sites work the same way. think production line.

[Ben]

Hey FutureMedia,

Thanks for your post! The explicit example and use-case really helped me make sense of it. This is clearly an issue that presents an real problem for some users, so sure, I'll add this feature.

What I'm going to do is this:
- Add a new section (optional, and hidden by default) called "Dynamic Client Filters" (or something less verbose...) at the bottom of the Edit View -> Filters tab. This section will look and function in a very similar way to the existing filters table where you can add your filters. Except in this new section, the final column will contain a dropdown of all client account fields. This will also contain any extended client fields, added via the Extended Client Fields module. You can then map the form fields to the client fields.

I'm hoping that this will also help mitigate the extra work involved in the use-case you mentioned. It should allow you to create far less Views - only one, in fact - so editing the Views to add / remove a field is considerably less work.

My one concern at this point is that Views that use these new "dynamic client filters" won't be able to be used outside of Form Tools, e.g. via the API in your webpages. These Views will now require a logged in user. Not sure how to handle that... anyway, something more for me to consider.

However, I MUST finish up this "Hooks Manager" module I'm working on first. I promised it to a user many months ago.

- Ben

[Ben]

Alright, I'm finally getting to turn to this feature next. Just a heads up.

- Ben