Steven H. Blackwell Posted January 5, 2009 Posted January 5, 2009 One of the more interesting new features in the just released FileMaker® Pro 10 allows users to manage the Table View screens that can display FileMaker Pro data. Users have the capability to remove or to add fields to the screen to a view, all without affecting the underlying layout that drives the view. In some instances, however, developers may wish to constrain this practice. So, here are four ways that the Modify Table View capability can be blocked in any given file. 1. Disallow the layout’s being sent to table view by toggling the appropriate check box in layout setup for each layout. 2. Hide and lock the status area. Both steps must be taken; simply choosing either hide or lock is insufficient. 3. In the Privilege Set for the active Account, set the menu available options to Editing Only. 4. In the Privilege Set for the active Account, set the menu available options to Minimum. Custom menu options do not control Modify Table View. Steven
Anyjoe2000 Posted March 12, 2010 Posted March 12, 2010 I have a real love hate relationship with this feature. I can’t remember how many times at the last Devcon someone talked about Empowering the users and stop locking the task bar. How about empowering the developer to do that? I understand that field security should be controlled by accounts and privileges (now manage security) but this is really outside the security scope as not all fields are user data fields. Many fields are used by the solution internally and users need to have permission to access the fields though they will never appear on a layout. Also most of these fields use a naming convention geared towards the developer as does the table occurrences and only confuse a client. This to me detracts from the end users experience that this function seems to be trying to create. Because the basic functionality is good that can be addressed with two simple changes that I was hoping to see in 11. 1) The modify button should be a standard menu item that developers can remove from the layout using custom menus. 2) The developer should be able to “turn off” the little green plus button on the Modify Table View dialog box for any given layout. With those two things this would be a wonderful tool to allow a developer to empower clients to easily create custom excel exports and reports. A developer could include all the relevant fields on the table view layout then uncheck some of the fields to create a default field group that would be a starting place for the client. The client can then use the modify field view to add or remove any of the fields on the layout. While I’m on the subject the export functions could use the same type of developer control so that system fields can be removed from the list. They have little or no value to the client and are just mucking things up and confusing people. Something like a system field check box in manage databases should do the trick.
Steven H. Blackwell Posted March 12, 2010 Author Posted March 12, 2010 I don't disagree with any of this really. Please communicate your thoughts to FMI as well. Steven
David Jondreau Posted March 12, 2010 Posted March 12, 2010 I don't disagree either. This is the way it is now though, and who knows if it's going to change? In order to give users a usable interface with the native Sort[], Export[], Import[] etc, I use natural naming for fields. My TOG naming convention hasn't followed and users have dealt with it. Now though, I think I will be creating user table occurence groups to base user layouts on. I also think it would be nice to manage permissions from within the field definitions. That would make it much simpler to deal with the complexity of RLA.
Steven H. Blackwell Posted March 12, 2010 Author Posted March 12, 2010 I also think it would be nice to manage permissions from within the field definitions. I disagree. And we made a conscious decision not to do this. Steven
Steven H. Blackwell Posted March 13, 2010 Author Posted March 13, 2010 Security and permissions needed to be walled off completely from all other schema. This area is the only one that absolutely requires a [Full Access] Account to access and manage in all its aspects. Steven
weag Posted December 11, 2013 Posted December 11, 2013 Hello, Could you please advise me how to enable table view for a non-FullAcess Web user in Filemaker 13. The checkbox seems to be ignored in the layout setup. Thank you. -Wendy
Recommended Posts
This topic is 4011 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now