Posts: 11
Threads: 3
Joined: May 2009
Reputation:
0
OK, I've got a very demanging client who would like to use FT2 as a centralized database for all his own clients. The problem I'm facing right now is that he would like that each registered client would be allowed to view and modify only a subset of the single entry related to that same client, while all the other entries are hidden.
So for instance:
Full form A ID1,2,3... -> Administrator can edit and view
Subset form A ID1 -> Client 1 can edit and view
Subset form A ID2 -> Client 2 can edit and view
Subset form A ID3 -> Client 3 can edit and view
As the clients to add are more than a few (about 200) is there a way to speed up the process, maybe assigning an ID-based filter directly to each client? The "long" way is to add a custom view for each client and then apply the ID filter to each of these views. But that is quite impractical for a huge number of clients.
Any help would be greatly appreciated!
Diego
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Hi Diego,
Thanks for your post - and sorry I didn't respond earlier. I read over your post a couple of times but never got round to responding. Sorry!
Let me just make sure I understand what you need. I've received a number of similar requests to expand the way you can assign Views to clients, to prevent you from having to manually create Views for each client. It sounds like that's what you need, but just so I'm totally clear let me go over it.
So you have about 200 clients, each of which need to view a specific subset of the form data. Is this subset a particular set of submissions, form fields or both?
In terms of the UI, how would you like it to work? So when you create a new client, how would you map that client to your data subset? e.g. would there be a new field in the Add Client page that said "use View X", or would there be something in the View itself (where?) that would dynamically assign itself to the client based on ID, name or something else.
Please let me know your thoughts on this - be as specific as possible, too!
Also - just so you know what I've been thinking about. There's an existing "Extended Client Fields" module that lets you define whatever additional client fields you want. Maybe we could use that in conjunction with Views to help?
I'm just thinking in terms of how it should work from the user-interface perspective. My job is to make it as simple but as powerful/flexible as possible.
Thanks!
- Ben
Posts: 11
Threads: 3
Joined: May 2009
Reputation:
0
Jun 29th, 2009, 6:51 AM
(This post was last modified: Jun 29th, 2009, 7:03 AM by Bryn.)
(Jun 27th, 2009, 10:52 AM)Ben Wrote: So you have about 200 clients, each of which need to view a specific subset of the form data. Is this subset a particular set of submissions, form fields or both?
In my case, there are about 200 companies that have posted data related to their employees and of course each one should must be able to see and edit only their own data, and not the ones related to other companies. They all use the same subset of submission - each one made by the same number of fields. The general admin can see the full set of fields, because my client need to add a full series of data that are "hidden" by the companies using the same system.
(Jun 27th, 2009, 10:52 AM)Ben Wrote: In terms of the UI, how would you like it to work? So when you create a new client, how would you map that client to your data subset? e.g. would there be a new field in the Add Client page that said "use View X", or would there be something in the View itself (where?) that would dynamically assign itself to the client based on ID, name or something else.
I believe the easiest and most practical way would be adding a column to FT "Database" tab/edit page from where a user can tick each field that need to be viewable/editable by the client related to that form. Alternatively, a single field where the admin can write all the DB column names that should be viewable/editable by the client. And in the FT main client edit page, another tickable field where the admin can choose to activate the "reducted client data set", so that each client may be configured to view only a reduced set of its own data (and nothing else on the same database), maybe checking that this function is activated if client name on the FT interface = client name on one of the fields in the form database.
Hope this helps!
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Hi Bryn,
Thanks for the feedback - interesting stuff!
Yes, I can certainly see how the solution you outlined would work for your situation. However, I'm a little reluctant to pursue this particular solution. Here's why: Views were designed to do a lot of what you already need. They give you a great deal of control over constructing subsets of the form data you can control what fields appear, in what order and which are editable. So the fact that this functionality already exists, I wouldn't want to add a second place (the Database tab) that would offer similar functionality. I think overall this would lead to more confusion... better to keep it in one place.
But we're definitely getting closer to a working solution - I really appreciate the feedback!
- Ben
Posts: 11
Threads: 3
Joined: May 2009
Reputation:
0
I definitely agree with your point of view - to keep everything consistent and under control it would be better to add those options into Views.
However, as *right now* I'm working on that project that would strongly need those new functions, do you have any idea when (if ever) we can see them added to a new beta?
Thanks!
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Jul 11th, 2009, 10:05 AM
(This post was last modified: Jul 11th, 2009, 10:06 AM by Ben.)
Fair question - but impossible to answer! I'm focussing on getting the Form Tools Wordpress plugin finished right now, then I'll turn to other stuff.
In all honesty, it's probably going to be several months before I work on this feature... sorry - wish I could fit it in sooner, but I have so very little time...
Keep pestering me about it, though - it'll make sure it doesn't get dropped in favour of other stuff first.
- Ben
Posts: 11
Threads: 3
Joined: May 2009
Reputation:
0
(Jul 11th, 2009, 10:05 AM)Ben Wrote: feature... sorry - wish I could fit it in sooner, but I have so very little time...
Keep pestering me about it, though - it'll make sure it doesn't get dropped in favour of other stuff first. Now that almost 2 months have passed since I started this thread, maybe it's the right time to ask you if there are any news on this feature... In any case, thanks for your help!
Posts: 11
Threads: 3
Joined: May 2009
Reputation:
0
Sep 6th, 2009, 11:32 PM
Ahem... Another month has passed since my latest reminder. I hope you will find the time to add this function soon!
Posts: 2,456
Threads: 39
Joined: Dec 2008
Reputation:
6
Haha I *do* appreciate the pestering. Makes it hard to forget......
Oh man, I can just picture this thread in another few of months... lots of "ahem!" / "bump!" comments...
Thanks for the reminder.
- Ben
Posts: 11
Threads: 3
Joined: May 2009
Reputation:
0
Other 2 months have passed since my latest message on this thread... Any news on the possible addition of that "filters applied to users" function to FT ?
|