8/29/2025 7:30:28 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 writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Hiding Data
Posted: 24 Jun 09 11:57 AM
|
I'm looking for suggestions on how to hide opportunities, activities and contacts from all users except for ADMIN and a defined team of users. We are using SalesLogix 6.2.6 client (expecting to upgrade to 7.5 later this year). Currently, the only built-in security mechanisms we use are the flags that identify whether or not a user is permitted to create a new account, contact, opportunity, etc. All of our users are currently permitted to view all of the data in the system. However, we would like to somehow flag some opportunity, activity and contact records so that they are not accessible by the general user community due to sensitive information. We will need a way for a defined team of users to access these records and set/unset the flag to hide/show the records from the general user community.
The other complication is that we have invested significant effort in developing external tools that interface with the SalesLogix database. If a record is flagged as hidden, these external tools will need to have access to the flag so that they can hide the records as well.
|
|
|
|
Re: Hiding Data
Posted: 24 Jun 09 12:32 PM
|
SalesLogix has built in mechanism to deal with Data access.
From your description, seems as if you are looking to create a team with a selected set of users, and then making your data owned by that team to restrict access to it by other users.
On top of that, you could use Field Level Security to further restrict who can Modify the data.
Also, for the Calendar there is Calendar Security that keeps users from accessing other user's calendar, this may be a more tricky part to control on a per Activity basis, but it will depend on your needs.
Also, if your external tools were built on top of the SLX OLEDB Provider (or even the SLAPI), security would carry over as well (off course, as long as not login in as ADMIN without Impersonation). |
|
|
|
Re: Hiding Data
Posted: 24 Jun 09 12:53 PM
|
Are seccodeids involved when making the data be owned by the team? I'm not very familiar with seccodeids.
Most of our users access the data through the external tools. We have a very small population of users who login to the SalesLogix client, although that will change if we can implement this security change. The external tools all access the database directly through SQL without going through the SLX OLEDB provider or SLAPI. We have a single database without any replication. |
|
|
|
Re: Hiding Data
Posted: 25 Jun 09 2:31 AM
|
Originally posted by careed76
Are seccodeids involved when making the data be owned by the team? I'm not very familiar with seccodeids.
Most of our users access the data through the external tools. We have a very small population of users who login to the SalesLogix client, although that will change if we can implement this security change. The external tools all access the database directly through SQL without going through the SLX OLEDB provider or SLAPI. We have a single database without any replication. |
|
Yes, SecCodeID identifies the team which owns a particular record. You could build code in your external apps to read the SecCodeIDs and show/hide appropriately - remembering that teams can be nested. In-built SLX security will not be applied automatically, as you have bypassed it by not using the SLX OLEDB Provider. |
|
|
|
Re: Hiding Data
Posted: 25 Jun 09 5:08 AM
|
Yeap, SeccodeIDs and Profile IDs.
A SeccodeID referrs to a Security Team. Within that Team you could have several roles (e.g. Owner, ReadWrite or ReadOnly).
If a User belongs to a Team that owns a given record, then he will be able to view it. And depending on his role (if using Field Level Security) he/she may be able to change the data.
In general, the approach is simple, although it could get complex if you start Nesting Teams and Departments within other Teams (or Departments).
I would suggest you check the Help Files on the SLX Administrator for further Info, it may not have all the answers, but will expand a bit more on these concepts. |
|
|
|
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!
|
|
|
|
|
|
|
|