Team control on Opps

[DanCarvin]

Quick question for a customer using 7.5.1 LAN:

The customer has a set of Account records they'd like to be visible to everyone.   We can set the Owner/SECCODE to "Everyone" - no problem.    But they want to control access to Opportunities for certain users - a user should be able to view/edit some opportunities but not others.  The goal is for both security and a desire to limit remote database size.   

With scripting I can change the Opportunity SECCODE to to a Team to allow only users who are members of that team.  I don't see a problem with this as long as the user has access to the Account record as well as the Opp record.    Are there gotcha's I'm not aware of that happen when the Opp SECCODE is different that the Account's? 

[jkuehlthau]

I think you risk messing up what Opportunities get sent to and updated on the remote databases as sync is based on Account.Seccodeid.

I have previously used a script that would make the entire Opportunity entity read only for most users.  It looped through all controlls on all forms and set them to read only.  Ryan Farley has posted code here: http://www.slxdeveloper.com/page.aspx?id=35&articleid=70

You might be able to use it to make the data invisible as well.

[dennissekulic]

You're definitely right about that one jkuehlthau.  I tried the same type of sync team security profile and it was too ridiculous to maintain properly.  I ended up causing my test remote to not sync what I needed properly.

Your best bet is to read only everything if you want to clamp down on security.  At least this way the user does not lose visibility on the account in the end.

[tmontgomery]

On a separate note which is not relevant to the issue, if you want to personalize your response click on the username hyperlink (in this case jkuehlthau) and the user's name is returned (Justin Kuehlthau). The page also returns recent posts and tags by the user

[RJLedger]

Dan,

 a simple provider plugin can restrict access to records.

For example:

  If several users are on a given team "A"

AND

  If a set of accounts are owned by Team "A"

THEN

  All users on Team "A" will see all opportunities associated with those accounts

IF you want to only allow the Account Manager to see their own Opportunities and NOT allow anyone else on Team "A" to see those opportunities

THEN

  a simple provider plugin can handle it without doing any custom scripting, etc. 

[DanCarvin]

I've done some testing to set the opportunity.seccodeid to an ID different from the account.seccodeid using some pretty basic SLX LAN scripting logic.   The users can all see the Account record (it is owned by Everyone), but not opportunities set to Teams they aren't a member of.    So far, none of the opportunity.seccodeid's have sponantiously changed back to the account.seccodeid.    I test remote I cut included all of the opportunity records (when viewed in Query Analyzer), but only those set to the user's Team or Everyone appear in the application.

Is there something in 7.5.1+ that would change the opportunity.seccodeid that I haven't tested?

Would a provider plugin prevent records the user doesn't have access to from going into the remote?   It is better the the solution I have?

The SLX Developer Reference is a bit vague on how to create & deploy Provider customizations. Are there examples somewhere I can look at?

[ToddHardin]

Hi Dan -

The only two things I can think of that would change the Opportunity.SecCodeID value are: Editing the Account.SecCodeID via the user interface (LAN) or using the Territory re-alignment feature in the LAN.

Note that in the Web, updating the Account.Owner object via any mechanism will result in the AccountSUmmary, Contact, and Opportunity SECCODEID values being updated to match the Account.

To consider - any Activity or History record (History includes completed activities, Notes, and DB Change audit info) that is linked to an Opportunity will appear on the Account's Activity and History tabs even when the Opportunity has been restricted for the current user by SECCODEID. Same story for Attachments linked to an Opportunity. Depending on how secure you want Opportunities to be, you may need to consider adding SECCODEID to the Activity table and History table.  Caution - if you add SECCODEID to Activity and History tables - you need to implement logic to set the SECCODEID to match the linked Opportunity.SecCodeId value.  Next, you should consider the case where someone needs to edit the Opportunity.SecCodeId value - you must keep the linked Activity, History, and Attachment records .SecCodeId value consistent with the Opportunity.SecCodeID value.

This can be handled more elegantly in the Web than in the LAN. I've implemented a solution in the LAN on SLX v6.2 or maybe v7.0 that made use of DB Triggers to keep SecCodeIDs synchronized in the scenarios above.

My advice would be to thoroughly test any solution you create, including testing synchronization and effects on remote DBs before pushing an advanced  custom security solution out to a production implementation.

[apfingstl]

hello,

As Todd said, this are the two scenarios where the SeccodeID will change back to the one of the account.

In my understanding a provider plugin can change this in the way you want it to be.

You can write your own provider plugins and you need to perhaps disable standard ones.

Be careful with sql triggers, as changes done by them will not sync out to remotes as they are not using the saleslogix provider.

Alexander

[RJLedger]

If you use a provider plugin you can block access using a different field - say accountmanagerid.

I have a working example.