8/28/2025 3:29:25 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.
|
|
|
|
Dynamically Creating Teams - Good or Bad?
Posted: 06 Jan 09 12:43 PM
|
Hello everyone,
I have a custom mainview and I need to limit access to the the underlying table. Some records are to be accessible by all users, and others are to only be accessible by our HR team, a specific sales rep, and the rep's manager.
To reiterate, here are the access levels that are needed:
-Everyone - accessible by everyone
-Exclusive - accessible by HR Dept, Sales Rep, Sales Manager
The table already contains the SECCODEID field, so I just need to create teams and populate the SECCODEID field with the respective values. Of course, I can manually create the various teams to support our needs, but I'd much rather create the teams through code when needed, as to ensure proper member assignment, which brings me to my question.
Is anyone already doing this and if so, what challenges have you faced? We are not using remotes, so I'm not worried in that regard.
Also, if there is a way to hide these teams, that would be a plus, as I'd like to keep them out of the team list when users perform lookups by owner.
Thank you in advance for your feedback.
...Rob
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 9:03 AM
|
Well we aren't playing with this stuff on the fly.....and your caveat would be that you/SLX would have to store the SECCODEID to the database and then retrieve the record through the SLX SQL View....for each user accessing the database for every account examined.....which means nothing would work on the fly (like an F8 List View) for Field Level Security.
What we do is at run time, on the OnChange of the Opp or Account or whatever form.....is run through a set of rules based on who the user is, if they are a manager or not, what departmentS they are in, what UserText1 is in the USERPROFILE table, what Territory they are in, etc. and then hide or readonly controls on the form as needed. Doesn't give you the non visibity ability of Field Level Security in a Grid/F8 List View.....but at least those that shouldn't be typing into the Account Number or Sales Commission % fields can't......
In other words, you can't have 50 SECCODEID values for one ACCOUNT.
What we do is check for like a checkbox or account number on the Account.....if Account Number is greater then "" Then no one except HR Dept, Sales Rep, Sales Manager can touch these 22 fields.....
I haven't needed to play with SECRIGHTS table, but I suppose you could store the correct values in the right fields....dynamic team membership.
The Owner Lookup format is SLX controlled, so no hiding teams.....unless you made them the wrong SECtype????
Long winded answer.
Short Answer?
BAD
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 9:04 AM
|
Well we aren't playing with this stuff on the fly.....and your caveat would be that you/SLX would have to store the SECCODEID to the database and then retrieve the record through the SLX SQL View....for each user accessing the database for every account examined.....which means nothing would work on the fly (like an F8 List View) for Field Level Security.
What we do is at run time, on the OnChange of the Opp or Account or whatever form.....is run through a set of rules based on who the user is, if they are a manager or not, what departmentS they are in, what UserText1 is in the USERPROFILE table, what Territory they are in, etc. and then hide or readonly controls on the form as needed. Doesn't give you the non visibity ability of Field Level Security in a Grid/F8 List View.....but at least those that shouldn't be typing into the Account Number or Sales Commission % fields can't......
In other words, you can't have 50 SECCODEID values for one ACCOUNT.
What we do is check for like a checkbox or account number on the Account.....if Account Number is greater then "" Then no one except HR Dept, Sales Rep, Sales Manager can touch these 22 fields.....
I haven't needed to play with SECRIGHTS table, but I suppose you could store the correct values in the right fields....dynamic team membership.
The Owner Lookup format is SLX controlled, so no hiding teams.....unless you made them the wrong SECtype????
Long winded answer.
Short Answer?
BAD
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 3:55 PM
|
What version of SalesLogix is this for?
Could you achieve this layer of security via an Provider Extension?
I personally have a system in which we create Teams on the fly. The reason is that the users Share their data on an Adhoc basis with other users across the country.
In general, this works great for us, then again, we are using the Web Client (this was originally implemented on Web 6.2 and has been ported over to Web 7.2).
The idea is that if a user wants to share an Account record to another user (off course that isn't part of his default Security Team), we create a new Team based on his Base security team and add the Shared users.
Our algorithm has checks in place to ensure that we don't create duplicate groups and remove unused groups.
In our SLX Instance, we have several thousand users, and a huge number of these Sharing Teams. Overall, this hasn't had a negative impact on performance or security, but you would have to ensure that you understand how it could. Also, you need to make sure you understand how the data is stored on the SECCODE, SECRIGHTS AND SECCODEJOINS table.
That being said, based on your requirements, this solution isn't the best fit for you.
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 3:57 PM
|
RJ, thanks for your reply and the explanation of the solution you found.
The issue for me is that I need to provide limited visibility to the records in the table, so they don't show in query results or in the list view. The data is considered protected and is to only be viewed by specific sales reps, their manager, and our HR department.
I'm a little confused about the "50 SECCODEID values for one ACCOUNT". Either I'm missing something or maybe I wasn't clear in my original post. If I were to create the teams manually, I would just add the sales rep, their manager and the HR department. I would just rather have this handled by code to avoid the manual aspect. Once the team is created, I plan to assign the related SECCODEID to the records as needed. I’m doing this already in other tables, but in those cases, the teams were manually created, as there were only a couple different teams that were required.
I'm planning to actually start in on this tomorrow by using SLXProfiler to analyze the SQL statements related to team creation. I just hope all SQL scripts are visible and that I can properly determine how all the values are derived.
I'll keep you posted. In the meantime, I'm still open to feedback in this regard. |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 4:16 PM
|
Originally posted by Rob Bartram
I'm a little confused about the "50 SECCODEID values for one ACCOUNT". Either I'm missing something or maybe I wasn't clear in my original post. If I were to create the teams manually, I would just add the sales rep, their manager and the HR department. I would just rather have this handled by code to avoid the manual aspect. Once the team is created, I plan to assign the related SECCODEID to the records as needed. I’m doing this already in other tables, but in those cases, the teams were manually created, as there were only a couple different teams that were required.
|
|
You get ONE SeccodeId per Account/AccountID. So an Account is either visible for everyone or only the manager and the HR Department.
You don't get 2 or 3 or 50 SECCODEID's per Account. 1 only.
I don't care how many teams you have.....and how many accessid's per team.......one SecCodeID per Account.
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 4:19 PM
|
Raul, thanks for your reply and explaination.
We are running 7.2.2 Win client. I'm not sure what you mean by "based on your requirements, this solution isn't the best fit for you." It sounds perfect. What am I missing?
I didn't see anything exposed by the provider that supports team creation, but maybe I'm not looking in the right place. |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 4:46 PM
|
RJ,
I think I see where the confusion is coming in. I'm only intending to associate one SECCODEID to each record. This SECCODEID would be determined for each record based on the value of the record's status field.
If the status indicates that the record access is "open" for all users then I will set the SECCODEID to that of "Everyone". If the status indicates that the record access is to be "exclusive", then I will create a team, to which I'll add the HR Dept, sales rep, and the rep's manager as members. It is the SECODEID for this team that I will then assign to the record to limit access. I will of course, check for existance of the team, as not to recreate it.
Thanks again for your input, ...Rob |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 6:42 PM
|
Actually, I just re-read your statement and it seems that you may not need a dynamic solution.
You stated that you need the following access:
-Everyone - accessible by everyone
>> Use the System defined "Everyone" team.
-Exclusive - accessible by HR Dept, Sales Rep, Sales Manager
>> On each Sales Rep Security profile, include the HR Dpt and his Sales Manager.
I don't see really a need to dynamically create profiles based on this description.
Records accessible to all users should be owned by the "Everyone" team.
Restricted records would be owned by the Sales Rep. Because you have granted the HR dept and the Rep's manager to hi default security profile, this accomplishes the requirement for the "Exclusive" rule.
Now regarding your question, there are no APIs exposed to create Teams, you have to create the necessary records on the SECCODE, SECRIGHTS AND SECCODEJOINS tables.
Best regards,
Raul
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 8:04 PM
|
Teams may be stored in a collection....check the SLX Profiler as you access each TEam....this means that you can't create teams on the fly.
What you are not understanding is that the SLX OLE DB Provider goes out to the database, retrieves the SECCODEID that is IN the record, attaches and ACCESSID field to the end of the dataview that is coded by field as to its accessibility (RW, RO, No Access)....that is what's returned to the client....F8 List Views, Forms, etc.....you can't change this on the fly based on the status of the Account record or some other data values.....it's already stored in the record, read by SLX, the Security Profile is read, fields assigned accesibility.
You're putting the cart before the horse. Doesn't work that way.
I would use the Sales Reps SELF TEAM, add the HR Dept and the Reps manager as members......assign the self team to the base table and any 1:1 tables with SECCODEID fields. The assignment you can do through SQL or some Territory Management subsystem.....
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 10:10 PM
|
Raul,
I like your solution, but if I add the HR Dept to each sales rep's security profile, won't they then have access to all records (accounts and contacts) owned by the sales rep? |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 10:44 PM
|
RJ,
Isn't the SECCODEID/ACCESSID combination created when the recordset is returned by the provider? If so, then why couldn't the SECCODEID be changed on the record in the database and then the recordset be refreshed? Doesn't that address the issue you mentioned? I'm currently doing this in some custom deletion code I wrote, where instead of deleting the actual account record, I just remove access by changing the SECCODEID on the account and related tables to that of a retired account called "Purged Accounts". The only issue that I had to address was removing focus on the account record before changing the SECCODEID. And for that, I had to unfortunately use SendKeys, but that has been working without any trouble.
As In my reply to Raul, wouldn't adding the HR Dept to the SELF TEAM of the Sales Rep, give the HR Dept access to all records owned by the sales rep (i.e. Accounts and Contacts)?
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 10:54 PM
|
Missed that part.
Then...
Manually create a Team per each Sales Rep.
Grant access to those teams to HR and the Sales Manager.
Use those teams only for your Custom Entity/Main view.
No need to create dynamic groups, just the overhead to create a new Team for Each Sales Rep.
The maintenance overhead would probably be even lower (say if need to replace a Sales Manager) than if you add dynamic groups. |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 07 Jan 09 10:59 PM
|
You are not making any sense.
1. You go to an Account. SLX reads the SECCODEID. Runs the SQL....returns the ACCESSID. Run SLX Profiler and give me a count on the records / joined tables returned going to ONE Account.
2. Now you know what the Status is and want to change the SeccodeID while you are On the Account Record. So you write to the Active Account record and change the SeccodeID.....Do a refresh on the Account and reread the entire account and tabs again.
3. Then what, when you leave the account change it back to a certain SECCODEID?
4. Let's say 5 different user's go to the same account at the same time.....you're going to start writing SeccodeID's back and forth?
Not good.
Put the data in another database with another SQL Owner (like SYSDBB). you control where /when you get the data....including for groups.....use SQL Views....
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 08 Jan 09 6:57 AM
|
Sorry RJ, making sense would probably help. 
The SeccodeID would only be changed for a record when a record is added or when the status of a record is changed. The records in this table will mostly be created and updated by an external service, with some manual overriding by the HR Dept, sales rep, and/or sales mgr. All of whom will have access to the record, no matter what the status is.
The process will go something like this: A record will initially be created with "Exclusive" access and then after some time, become "Open" and accessible to everyone. This process will be controlled by an external service running after hours, but there will be occasions where the status of a record will be changed manually. In the event of a manual status change, only the HR Dept, sales rep, or sales mgr will be allowed to make such changes. All of whom will have access to the record, no matter what the status is.
The only problem I can see, is when the status of a record is changed from "Open" to "Exclusive" in the middle of the day, people not having exclusive access to the record will have to refresh the record set and/or I will have to validate that the record is still accessible when they try to access it. Going from "Exclusive" to "Open", will also require a refresh to any open record sets, as to include the now open record. Anyway, there will be email notices of any changes, in which I will include text encouraging a refresh.
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 08 Jan 09 8:27 AM
|
Raul: "Manually create a Team per each Sales Rep.
Grant access to those teams to HR and the Sales Manager."
Every user already has a Team.....the self team.....no need to manually create one? |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 08 Jan 09 8:32 AM
|
Now i get it......yea having Task Center, Knowledge Sync, or whatever convert the Accounts based on Status Change, etc. is a great idea....
People are refreshing Groups and records every few minutes anyway, I wouldn't worry about the refresh.....are you thinking that a user is going to sit on top of a single account so as to have 'access' to it.....knowing that they are going to lose access to it....or gain access to it?
And since you are going from Exclusive access to uncontrolled access, shouldn't be a worry.
Use the Self Team, add HR and Sales Manager, and VP Sales to it.......when a rep creates an account, that's the SECCODEID that gets stored to the Account record or your custom mainview tables....and of course any special 1:1 tables that have Field Level Security (FLS).
Later on, SECCODEID becomes 'SYST00000001' and everyone can grab on to all fields..... |
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 08 Jan 09 8:35 AM
|
RJ,
Based on his requirement, he needs a team per Sales Rep, but he doesn't want to modify the Base Security Team for each user because CAO permissions would be modified. So, I would say keep the standard profile for CAO and create a parallel team for each Sales Rep to address the security needs of this new Entity.
The whole point is to have 2 teams per Sales Rep.
- Their Standard profile to be used for Account, Contact and Opportunity Security.
- A Parallel team to be used for your new Main View/Entity.
So, for a User named Jon Doe, you end up with the following:
SeccodeDesc SeccodeType
Doe, Joe U (This is the Standard One)
Doe, Joe (HR) G (This is the One to be used for your new Main View)
So, no Accounts, Contacts or Opportunities would be associated with the "HR" team for Jon Doe.
Dynamically assigning the new Entity records to the "HR" team for Jon Doe isn't any different than doing so for the Account, just a simple Update Statement.
|
|
|
|
Re: Dynamically Creating Teams - Good or Bad?
Posted: 08 Jan 09 9:48 AM
|
RJ,
For further clarification, these records I'm talking about are in a custom table behind a custom mainview that I've created. It's a list of available "hot products" (and I don't mean stolen  ), of which one or two products are assigned to each sales reps. For a period of time, the sales rep have an exclusive right to sell their assigned "hot products" into their territory and after that time period expires, the products become open to all reps to sell. It may seem like this should fit in with the opportunity/product architecture that already exists, but without giving away our business model, it really doesn't.
Without going into all the details, basically these records are used to associate notes and activities with each "hot product", so at the end of the day, we can run a report showing specific selling activity related to each product. As far as refreshing the record sets, from a technical perspective, I'm already checking to verify that the "hot product" records are still available to the sales rep before saving any note/activity associations, so no issues there. I'll just make sure I throw a meaningful msgbox to the user when they try to associate a record that is no longer available. They will also be getting an email anyway, so I think it will be managable.
Unfortunately, the SELF TEAM will not work as that would give our HR Dept access to all accounts and contacts owned by the sales rep.
I think I have a good handle on it now, I'll post back when done.
Thank you for your input.
...Rob
|
|
|
|
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!
|
|
|
|
|
|
|
|