01-13-2010 04:59 AM
Both work if launched from a button on the Opp Detail form but not when in the WhenChange of the form or txtOpportunityID.
01-13-2010 07:15 AM
01-14-2010 03:42 AM
I've never done anything with provider extensions, and for some reason thought it's only available for SLX 7.x
How big of an effort would that be for someone who has done something similar?
Basically I need users to only be able to access an Opportunity if they are a member of an "All Access" team or if the Opp was created by a user from the same Division (UserInfo.Division).
01-14-2010 04:00 AM
01-14-2010 04:06 AM
Thanks for the responses guys!
The problem is I can't get the Application.BasicFunctions.SetCurrentOpportunityID or the MainViews.AddEx to work when launched from the WhenChange events of the Opportunity_Details form.
It works from other places (i.e. a button on the OppDetails) but not from the When Change.
I had a similar thing working years ago but not sure where and what version of SLX it was, and can't make it work on 6.2.6.
I was thinking maybe I need something like CurrentViewCancelShow to stop it from trying to open the opportunity it's "heading to" and then force to a different opp, but can't think of anything relevant.
01-14-2010 05:45 AM
Provider plugins are supported right thru 7.5.2.
What you want to do sounds fairly easy if you know a little bit about them (provider plugin).
We have built them in VB6, VB.Net, and C#.net. They are an unregistered COM object/dll.
Mike's approach should work as well.
What I like about a provider plugin is that it's not possible for any scripting to be able to bypass it.
01-14-2010 07:04 AM
I would prefer going with Mike's approach (SetCurrentOpportuntyID) but as I mentioned i can't make it work from within the WhenChange for some reason.
01-15-2010 09:32 AM
The SLX Provider will enforce security as long as the SeccodeID on the record is properly populated. But ACO (and Activity/History) tables have some specific client code that makes things a bit strange (override/change SeccodeID, usually to "fix" records to match Accounts).
From my experience, a Provider Plugin actually will NOT work in this case. Since Opps are tied to Accounts, there is actually SLX Client code that will change the SeccodeID to match the Account (one of the legacy ACO items).
Mike's suggestion is definitely the "quick and dirty way" but is not truly secure (OK as long as client is aware of limits). I don't have advice on making it work...
We have implemented custom security for Opps so that only Sales could see Opps (and related Activities/History) but anyone could see the Accounts. We've also implemented custom security that ANY table could be secured to a specific SeccodeID (so only professional services can see custom billing related to an Account for example). This even has an admin UI to make it simple to add/maintain security for an entire table without hard-coded SeccodeIDs in script.
This is true provider-level security since we are using the SeccodeID. However, we use SQL Triggers but with some "magic" script so sync and remotes will still work (credit to Todd Hardin who sorted out some of the foundation for a client). The Trigger simply "resets" the SeccodeID if the SLX Client "fixes" it to match the Account. We've been working on it for months and it even works with Outlook integration/Intellisync which is tricky with Activities related to an Opp.
Anyone who is interested can contact me - it's a little too involved to post here.
01-15-2010 01:04 PM
In this case it won't work because he's on 6.2.6 ;-)
However, I have built provider plugins that only allow the Account Manager to see his/her opportunities and/or contacts. It has nothing to do w/SECCODEID in those cases.
01-15-2010 03:12 PM
Thanks for the mention on that Chris. Glad to hear that approach is still working well. Hope to get down to Florida some time this year to see you guys.