difference between TABLE and TABLEDATA

Hello, Perhaps is it a silly question, but i don’t really understand the difference between “TABLE” and “TABLE DATA” in role permissions. Regards, JM Lessi

Table data is data container. Table is object (Trigers, func.) container. In C/SIDE you can’t access Table data without table. But using Cfront or ODBC you can access table data. So in C/SIDE you using Table, in external application you using ODBC or Cfront to access Table data.

The following is from a Navision support document describing how Permissions are set: Table - This is the Table Objects themselves, the definition of the tables, the keys, and the trigger codes. TableData - This refers to the data stored in the tables. This is what gives you permission to read or write the data in the database. Dave Studebaker das@libertyforever.com Liberty Grove Software A Navision Services Partner

Thank’s for your answer, i understand the difference, but i don’t know why these definitions don’t appear on the French Doc. Best Regards. JM Lessi

How can I set a field in a table data to be read-only for a role ID and the field to be modified for another role ID. Thanks in advance.

Hey S.K. you will have no possibility to mark a field in a table as read-only. Either you set the complete table in the access-group as read-only or not. But you can prevent a user from changing the contents by setting the field in the form as uneditable. Okay, the user can still enter data manually into the table, but the “usual access” is denied. Stefan Weinreich Billing Analyst

Hi Stefan, Any idea of how I can use filter in Security Filter of Table Data? Any example? TQ.

Hey S.K. sorry, i don’t know what you mean with “security filter”. We use the German DE2.50-version, but there is no similar field or a field which could be meant by “security field”. Stefan Weinreich Billing Analyst

Oops…I’m using Navision Attain 3.01B

Hi S.K., though it’s not really related to the title of the post…

quote:


How can I set a field in a table data to be read-only for a role ID and the field to be modified for another role ID.


On the field definition you can only set the property if a field is editable or not, but you can not specify that some user may or may not update it. If you want this to happen you have to code it on the form. For example, define a new role in the permissions, e.g. ‘Edit-Field’, with no specific permissions, then you add the following code to the form, which contains the field(s) you want to include. Permissions.RESET; Permissions.SETRANGE(“User ID”, USERID); Permissions.SETFILTER(“Group ID”,‘Edit-Field’); IF NOT Permissions.FIND(’-’) THEN BEGIN CurrForm.Field1.EDITABLE := FALSE; CurrForm.Field2.EDITABLE := FALSE; … END Remark: I use it in Financials 2.60 not in Attain… Hope that helps Nils

quote:


Originally posted by skchong: Hi Stefan, Any idea of how I can use filter in Security Filter of Table Data? Any example? TQ.


Well to answer your question the security filter table data enables another layer of security to the navision security feature. it filters for a particular set of records that the user can use or specify. but unfortunately, this is only enabled for SQL option, not for Navision Database. at least, that is what i read from somewhere, but i have not used it personally.

quote:


Originally posted by StefanWeinreich: Hey S.K. you will have no possibility to mark a field in a table as read-only. Either you set the complete table in the access-group as read-only or not. But you can prevent a user from changing the contents by setting the field in the form as uneditable. Okay, the user can still enter data manually into the table, but the “usual access” is denied. Stefan Weinreich Billing Analyst


Actually, you can program a Table in the OnValidate trigger for the field to do a lookup on the USERID. I’ve written security modifications that do this, read the “Member Of” table to look at what Roles are assigned to the user. Then, if you have a specific Role that someone setting User Security can use that will be read in code and prevent the user from making the modification to the field. Now, the problem I had in my modifications was to hide specific fields from specific users, and that unfortunately has to be done at FORM level. Regards! Kristopher Webb Kelar Corporation, Canada

quote:


Originally posted by jordi79: Well to answer your question the security filter table data enables another layer of security to the navision security feature. it filters for a particular set of records that the user can use or specify. but unfortunately, this is only enabled for SQL option, not for Navision Database. at least, that is what i read from somewhere, but i have not used it personally.


There is another way to filter out specific records in the Navision database by way of coding. It (unfortunately) must be done at FORM level. You place a record filter based on USERID or any other criteria you’d like to us. The way you keep a user from overriding the filter using the standard filter buttons on the toolbar is to set the filter in a separate FILTERGROUP. The standard filter buttons only affect FILTERGROUP(0) by default, so you change the FILTERGROUP setting to a new value (like 4), set your filter, then reset back to FILTERGROUP(0) before the end of the trigger. The user accessing the form cannot modify the filter set in FILTERGROUP(4) after this code. A sort of psudo-security. Regards! Kristopher Webb Kelar Corporation, Canada

It is possible to prevent certain users from editing specific fields. This is, for example, done in Form 25 in the field “Due Date”. The form itself is editable, but the majority of the fields are NOT editable. However, the TableBox has the property InlineEditable set to Yes, and the Due Date field has the property set to Yes. Tee actual validation on who is allowed to modify the Due Date field is controlled from Codeunit 103. So the permission on who can edit the Due Date field in the Customer Entries table can be controlling by implementing or denying permissions for a Role to Codeunit 103 Lars Strøm Valsted ------------------------- Software development today is a race between the programmers trying to make better and more foolproof programs, and the universe trying to make bigger idiots. So far the universe is winning.