09-01-2011 04:44 AM
Is it possible in 7.5.3 to hide some fields using the secured actions?
Does the field level security available in LAN can be use in Web ? If Yes How ?
Thanks in advance
09-07-2011 02:21 PM
Secured Actions cannot be used directly to do this. You would have to do this in code with a check on Role/Secured action.
Field Level Security works great for this. If it's a standard SLX table with Seccodeid in it, then it would just work. You just need to edit the field level security profile in the LAN Admin to reflect the configuration you want. If it's a custom table, then that requires a bit more work. You need to be sure that your table has a SeccodeId field (that get's appropriatly updated), and you will need to be sure that your Table has SECURE set to 'T' in RESYNCTABLEDEFS, and your table/fields in SECTABLEDEFS have a value for FIELDOFFSET greater than zero (not 100% sure this is required, but it doesn't hurt - I just set it equal to the index). This will make your table show up in the table tree in Manage Fieldlevel Security Profiles.
09-09-2011 01:17 AM
Thanks for your reply , I'll try your solution and I'll give you a feedback.
Below a link with the same information you gave me :
09-12-2011 12:33 PM
Back in the old days......
FIELDOFFSET was the postion in the SECPROFILES blob bitmap for each field to be offset....so the 2400th FIELDOFFSET would be in the 800th byte of the blob....
Setting FieldOffsets willynilly to the FIELDINDEX value is a little scary for me.....there being no 5600th / 3 blob position in SECPROFILES for example.....
Are you sure about this??? And your post says nothing either way about FLS on 1:M tables which would be a little scary for me as well as this isn't supported?
09-12-2011 12:55 PM
Funny thing with "on-to-many" tables in the Web client is that they're really no diferent than any other table/entity. Field level security is evaluated with any table that has seccodeid in it, and a profile exists for that field. We use field level security in our one-to-many tables all the time (we maintain the value for Seccodeid ourselves to be certain it's set propperly). Keep in mind, however, that these are entites created in AA. The same may not be true for imported tables (Activity, History, Address for example), and I don't think it would work in the LAN client.
As for the FieldOffset value, I've used this method for a long time without any iusse. That said, it's probably best to simply take the current max fieldoffset value and add +1 to it. But it's still possible to run into the same issue if you think about it.
Sounds like you probably know more about the implications of FieldOffset than I do, so would be good if you could contribute your best method for setting this.
09-13-2011 06:08 AM
I've converted over to the web.....and am starting to get over my fears of always using SLX to issue Sync Tefs, generate a unique 12 char string (I'll bet you don't know what table this key value is from: "ZIPCODE90210"..... stored procs against a database are much faster than VBscript through the LAN Sync engine....
hey, if Field level security works for 1:many tables on the SLX Web I'm all for it.....
[you do realize that using SECCODEID and FLS is 4-10 times slower than a native connection.....]