10-15-2009 04:23 AM
We have added an account extension table called cstAccount.
When a user has readOnly access to accounts the normal account fields are readOnly.
The fields in cstAccount are not.
We edited the ReadOnly profile, set all fields to readWrite, saved and changed back to ReadOnly to make sure the blob updates.
But still all fields in cstAccount are readWrite.
What can I do to make sure this works correct?
This is a web only implementation so I can not test with the LAN Client.
10-15-2009 08:45 AM
Have you checked:
a - RESYNCTABLEDEFS for the secure flag ?
b - SECTABLEDEFS to make sure the FIELDINDEX and SEQCODE(s) are ok for the extension table?
c - The datablobs in SECPROFILE for ALL records are ok (all the same length and are the correct length for the MAX(FIELDINDEX) ?
10-15-2009 10:14 AM
I ran into this recently. The Security Profiles don't apply to the web. If the fields need to be read only for some users and exditable for others, you'll need to create a code snippet that obtains the current userid, reads some value linked to it (userinfo.department is easy to get to), then set the ReadOnly property on all the controls.
10-15-2009 10:57 AM
Yep.... Unfortunately we end up w/a custom solution for FLS that will prove to be a problem in the short and long run.
When discussing data "security" I typically describe it as follows:
A - If using SECCODEID alone - it's RLS - Row or Record Level Security
B - If using SECCODEID and SECPROFILE(s) it's Field Level Security
So, The web does not really have FLS "builtin" like Windows/LAN since it does not access SECPROFILES for field (R/W, R/O, N/A) security.
10-15-2009 11:52 AM
Actually, that is not true.
Since 7.5.1 the web client does implement field level security using the information in SECPROFILE (which is cached on the web server), the current user, and the row/entity you are accessing. In fact, you can check what the access for a property is yourself by using the Sage.Platform.Security.IFieldLevelSecurityService service from the WorkItem Services collection. Through this service you can tell if an entity type is secured (EntityIsSecured) or check what the access is for a property (GetAccessForProperty). Generally, you don't deal with these details yourself though as it is called indirectly for you when you bind to an entity or access an entity's properties.
So, maybe we have a defect somewhere we need to uncover. There is a known defect where SECPROFILE data is incorrect that is being addressed in 7.5.2 and a 7.5.1 hot fix, but if you are confident that is not the issue, we can look elsewhere.
Since the code to apply FLS exist in a few different places, can you be more specific about where you are reviewing the access for your table/properties.
Are you looking at a list view, detail view, grid, or in code?
10-15-2009 01:47 PM
Here's what I did...
1) In Administrator, created a new Security Profile for users who will be working in Leads only, and should not be able to have access to Accounts at all. The entire account table was set to "No Access." Assigned a user to that profile.
2) In SLX Web logged in as that user, Accounts owned by Everyone and the Team the user is a member of can still be seen on Account list views, opened in Account Detail, edited and edits are saved.
3) In LAN logged in as that user, no account records are found (as expected).
If this is the issue addressed in HF and 5.7.2, let me know.
10-15-2009 02:57 PM
I believe the web client is probably functioning as designed in the case you described.
The point of confusion is that it does not matter what profile is assigned to your user. This is just a default.
Since field level security is applied at the column AND row level, what matters is the profile that is assigned to your user for the owner/team that owns the record you are trying to access.
Say you are accessing a record owned by team Midwest.
You can see what profile will be applied in Admin.exe by looking at the Midwest team in the Teams view.
Find the team member [user] you are interested in under the Midwest team.
This node shows you what profile will be applied when accessing records owned by Midwest.
You can see this information mirrored in the SECRIGHTS table, which is used at runtime for determining access.
SECCODEID is the owner of the record you want to access.
ACCESSID is the Id of the user trying to access the record.
PROFILEID is the foreign key to SECPROFILE for the profile to be used for determining access.
If you look in Admin.exe, you won't find (to the best of my knowledge) a way to set the profile for a user for the everyone owner.
If you look at SECRIGHTS for the everyone owner (select * from secrights where seccodeid = 'SYST00000001'), you will find that the profile used is always R/W, not the user's default profile.
This means any user accessing a record owned by everyone will ALWAYS get R/W access.
If you want to restrict access to certain columns on all rows for some users, you can't have 'everyone' be the owner on records on those tables since you can't set the profile that gets assigned for these restricted users for the everyone owner.
As for the LAN client behavior, what you mentioned was rows not being returned, which is row level security, not FLS, so I'm not sure what you were checking.
But keep in mind, security is not always applied consistently or correctly in the LAN client.
10-15-2009 03:08 PM
Everyone ownership is not a "true team" like other teams (unfortunately) and no matter what profile a user has assigned to them, the "everyone" seccodeid factor/owner is what drives the access. It's always (supposed) to be that way.
RLS access first (controlled by SECCODEID)
FLS access second.. IF SECCODEID <> 'SYST00000001'
Then (7.5.x) Web does use FLS "properly" if SECCODEID is not 'SYST00000001' - right?
(I was aware of the blob length problem years ago...)
10-15-2009 05:12 PM
The web does not special case for any seccodes. It is data driven off of SECPROFILE and SECRIGHTS. The admin just always generates R/W access records for 'SYST00000001' and there's no apparent way to change that. I suppose you could manually change the profileID in SECRIGHTS, but I would suspect making certain security changes might cause your changes to get wiped out and regenerated.
Did you ever report the SECPROFILE blob issue? That's not a good problem to have for so long.
10-15-2009 11:46 PM
First of all, thanks for this amount of feedback.
To clear things up a little, here are the steps I did and the issue I am seeing with SLX 7.5.1 HF 30.
1. In Admin created a table called cstAccount
Added some fiels to it
2. Went into AA added this table as an entity (extension entity for account)
3. Created some new detail forms for the data and put some of them onto the account detail form.
4. Crated a Team called BPM and assigned some users.
5. Set the profile of one user to readOnly.
6. Under Manage/Field level security profiles I edited the readOnly profile and set all the fileds in cstAccount to readOnly.
Opened up the webClient with an account owned by BPM.
What I now see is:
1. All fields from the account table are readOnly (As expected)
2. All fields from the cstAccount table are ReadWrite (not expected)
It seems that FLS is working in the web Client for standard talbes, but in this case not for my custom one.
Keep in mind, I only tested ReadOnly not NoAccess.
Does this clear things up?
If you have any questions, please let me know as the customer realy needs this feature.