FORUMS


The Form Tools forums are no longer active, but the old posts have been archived here. Please see the Help page on how to get help / report issues.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Issue with views & filters
#1
Let's say I want to create an internal support form for all of my clients but I want them to see only whatever support info they submit. Once created, I would edit the views so some field on the form would = the same input from some field from their account form. I would make the form available for all clients to see.

Unless I'm doing something wrong, it's not working the way I'd like it to. By selecting a view filter where field = field, the support form submissions box shows up but the "add new" form doesn't show up for the client. When I remove the field = field, the client can see the form and also all of the submissions from all other clients but I don't want this client to see them.

What's needed is a field that's automatically populated with some info from the client's account. Currently, ID is the only unique identifier for a particular client and can't be changed unless the client's account is deleted. A different unique id could also be created through the add-account-field module and it'll show up where field = field in views. If this field is added to the internal support form, it's still useless because the client can enter anything he wants into the field and won't be able to see his submissions (but another client might). So what's needed here are 3 things:

-The ability to see the form even though no submissions have been made.
-A field that's populated with a unique identifier from the client's account that'll be used where field = field in views for whatever form and its submissions we'd want the client to see.
-The field must be "readonly" so it may be visible but can't be changed by the client, either that or just hidden (I know FT has similar controls over form fields).

Being able to create a form with populated fields based on the user's account info would be very helpful. If one were to create a form to be used for some type of communication between client and admin, admin would need to know who's sending the info. It would be convenient for the client if he didn't have to fill out his info every time he wants to communicate with admin.

I think what this may involve is a system based on relationships. If I were to set up the support form to work for every client based on the clients' unique id, they should be able to log into their accounts and see the form as if it's customized specifically for themselves. The only way to do this is if the form itself connects to the database and pulls data from the row containing the client's id. Is it possible to create {$placeholders} for field values similar to those FT has available for email? Would the placeholders be related to the client account so when he logs in and sees the form, his name, his email, his phone, etc shows up on his form?

Thanks!
Reply
#2
I think what I may end up doing for the time being is create a new page, name it "Support" and add it as a client menu item, clone the html code that makes up the current support form I've created and paste it into the new page, and then copy the MySQL code from the account page (or create new) and toss it into the new Support page and code it so the fields will be populated, pass a unique identifier that can be set up in views/filters and then copy the same form action from the original support form.

By theory, this should work just fine and the submissions would appear within the form database named "Support", the client would have access to his submitted info only, and a fresh form populated with his info will appear by clicking on the "Support" link from the menu. But an unpopulated form will also appear under the Support submissions table > Add New, which might be a problem so I may need to look at views to see if this particular form (not the submissions table) can be excluded somehow from client views. Any suggestions would be helpful... I just haven't found a single day containing 48 hours worth of time to work on this yet...


Alternatively, the client doesn't really even need to see or keep a record of his own support submissions so I could set the views so Admin only can see them and this would eliminate the unpopulated form problem...

Or I could just look through open-source Support applications and see if there's some way that I could integrate it in with formtools... (probably making this more complex than it really needs to be)

The bottom line is that I want to make this work because FT has the ultimate potential to function as a fully-featured back office for my clients. I love its simplicity when compared to advanced CMS systems such as Joomla, Drupal, & PHP Nuke. With some modification, it even has the potential to be a simple CRM which would be much easier to manage than vTiger and SugarCRM.
Reply
#3
Yes, the argument of the plant has fluctuated for the mid of the payments for the field. The actual usages are ensured to https://www.resumesplanet.com/resume_help.php for the residential elements. The part is filled for the citizens. The change is ensured for the mode of the parts. Skills are invited to the room for the citizens.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)