11/22/2024 10:55:51 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss ADO specific questions for use with SalesLogix. View the code of conduct for posting guidelines.
|
|
|
|
Field level security profile questions
Posted: 10 Apr 06 3:29 PM
|
fiogf49gjkf0d Wondering someone out there has the answer to how the field level security definitions in the database actually work from the database level.
As I understand it, in the SECPROFILE table in SalesLogix is a column called PROFILEDATA which stores a series of coded letters that correspond to the provider level security level for a given field.
For instance for the default Read/Write profile the PROFILEDATA column begins with GGGGGGGGGGGGFGGG...
For the first character position, which has a "G" this denotes that a field is set to Read-Write access.
For the 13th charecter it has a leter "F" which denotes a different security level, I beleive in this case read-only, for a certain field.
My question is: Is there a way of determining which field in the database corresponds to each position in the PROFILEDATA string? |
|
|
|
Re: Field level security profile questions
Posted: 11 Apr 06 2:49 PM
|
fiogf49gjkf0d Maybe it is similar to how the fx_rowaccess() scalar function works in the SLX provider? This is similar in that it returns the security access level the current user has to the fields returned in the query.
The fx_rowaccess() function is a scalar function that is used inline and returns a 0-based byte array indicating the access level for each field, so for a select statement such as this:
select account, type, mainphone, someprivatefield, fx_rowaccess() from account where accountid = 'AXXXX0000001'
The resulting data from the query might look like this:
Abbott Ltd., Customer, 8005551212, null, 31303
Well that last one really would be a byte array, not just the digits, but the digits in the byte array would look like those. But they would indicate the following:
Account: Read/Write
Type: Read Only
MainPhone: ReadWrite
SomePrivateField: No Access
You basically have 3 values there:
0 = No Access
1 = Read Only
3 = Read/Write
However, whether or not that corresponds to the data in the PROFILEDATA somehow or not, I have no idea - but it is the only idea I had so I thought I would share it 
-Ryan |
|
|
|
Re: Field level security profile questions
Posted: 12 Apr 06 2:16 AM
|
fiogf49gjkf0d Kris, what are you trying to accomplish? If you are trying to determine at runtime what the FLS is for each column, fx_rowaccess() is your best bet. We can get you sample code for parsing the byte array if necessary.
Let us know what you are trying to do and I am sure we can help.
Timmus |
|
|
|
Re: Field level security profile questions
Posted: 12 Apr 06 9:48 AM
|
fiogf49gjkf0d Timmus and Ryan, thanks for the responses. I did know about the fx_rowaccess function. AFAIK that function gets its results from the from the data in SECPROFILE table.
I recently ran into an issue where I encounered some kind of corruption in a client database in this table. Normally the string contained in the PROFILEDATA column is around 2500 characters long, in this case theirs was significantly shorter. Only by copying in the SECPROFILE data from an eval database, was I able to "fix" their problem. However this meant losing their defined field level security.
The corruption in this table was causing all kinds of problems with data not being editable that should have been, and vice versa.
My hope is to be able to understand how this data is stored, so that if necassary it could be repaired.
I have asked Sage support about this, but they said it was a good question and that no one there knew the answer!
|
|
|
|
Re: Field level security profile questions
Posted: 12 Apr 06 11:48 AM
|
fiogf49gjkf0d If you edit an existing secprofile (such as the ones you pulled from the eval) the blob length will be corrected so that all the tables flagged as secured will be accounted for. This however, it is just the begginning of the fun, and maybe that is exactly what you are complainging about  , as you can not assume that any of the FLS profiles are correct. Since everything is ordinally based, it is very likely you have mismatched rights. So you have to go through every profile and reconfigure. PITA
Timmus
|
|
|
| |
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|