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!
|
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 23 Apr 09 11:01 AM
|
Give them the Admin password and have them log in as Admin.
On a side note. Are you Nuts??? Are these users CERTIFIED to Develop in SalesLogix? Do they truly know what they are doing?
Hey I wonder what happens if I
cn.ExecuteSQL "DELETE FROM ACCOUNT"
kewl, let's try it.....
|
|
|
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 23 Apr 09 11:58 AM
|
| What would be the business benefit to give users that level of access? It's one thing to have maybe a small team of admins who work together, but giving end users development access sounds like a recipe for disaster. Aside from RJ's delete senario, the database could be filled with custom tables, poor usage of indexes, editing or deleting of plug-ins, causing development 'wars'. |
|
|
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 23 Apr 09 6:57 PM
|
They need Architect installed on their PCs - or they need TS access to a machine which has it installed.
Development with a non-ADMIN account - not tried it. I imagine pain though - the user will not be able to test their customisations without releasing them - every time a change is made. |
|
|
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 23 Apr 09 9:45 PM
|
You are referring to Administrative Roles - which allow users controlled access to certain administrative functions - if they log in to the SLX Administrator client as themselves and not as ADMIN.
There is no corresponding 'Developer Roles' functionality which controls access within Architect, so I am afraid that the answer is no.
Phil |
|
|
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 24 Apr 09 8:34 AM
|
Well here is your definitive answer.
1. NEVER ever develop in your Production Database. Did I state NEVER? If you can come up with any reason to develop directly in the database you are FIRED.
2. Establish 3 databases with three different ADMIN passwords:
Production
Quality Assurance (Staging)
Development
These three databases can be anywhere in the world....including putting the development database on a home computer, sales laptop, India, etc.
3. Only give this Developer User access to the Development database, and maybe Staging. Your requirement to not allow the Development User ADMIN access to the Production SLX database is 100% met.
4. Develop in the Development database. The developer user creates Project Based Bundles for testing in the Stage environment. The Admin Admin (or possibly the Developer User) installs the bundle into Staging and then tests the functionality against the Project Specification and the Developer Design Doc and the TEST plan developed by the Developer User that shows that the functionality meets both the Design Doc and the Project Specification. No Spec, No Design Doc, No Test Plan, then NO Bundle Installation. Period.
5. One the Test Plan has been run and the bundle is approved by QA and the User Champion/committee....then and only then is the Bundle promoted and installed to Production....at night, when no one else can be bumped off by the SQL OLE DB Provider when it hiccups on the Plugin Release release.
Capiche?
|
|
|
| |
| |
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 24 Apr 09 9:45 AM
|
Ya' vol! Herr Kommandant!
(sorry, just had to) 
BTW: I agree completely with Marc that it should be added to the Implementation guide and while you're at it, add it to the official SLX developer course material!!!
John G. |
|
|
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 25 Apr 09 7:46 AM
|
Agree 1000% w/RJSamp on this subject.
Having been a former CIO (and implemented SalesLogix at that company).. plus all the years as an independent SalesLogix developer as well as the founder/owner of a SalesLogix partnership based on Services/development...
My experience has shown me this:
A - SalesLogix is NOT a multi-user development environment - even the new web can be very complkex to setup for multi-user development.
B - Don't expect the changes needed for multi-user SalesLogix development to show up anytime soon - if ever - as part of the product.
C - Every "developer" has his/her own development setup w/nobody else having access to that user's setup
D - Make someone "king" of the system to perform the final merge of changes to create the final bundle set(s).
E - Have a procedure so that every developer refreshes his/her own development environment from production frequently. If you are doing a lot of work.. weekly.
F - Have a final test environment where ONE person controls it and all changes go thru that person for final testing. Snapshot (this is where VM's come in handy..) before loading a new bundle set for testing. If the test(s) fail.. roll back to the snapshot and kick it back to the original developer and make sure all know. Once things pass, the person who owns the final test system pushes the changes to production w/the original develoer available in case a last minute bug shows up because something chnaged. Then refresh test from production.
Sounds like a lot of work?.. Yes it is because writing code is SIMPLE.. managing the process is complex.
--
RJLedger - www.rjlSystems.net |
|
|
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 27 Apr 09 7:12 AM
|
I noticed the below question which I didn't see an answer to yet. The question was
My issue relates to how I, as a Security Administrator to know who made changes in the plug-ins.
After installing Architect on the developer's workstation you can do the following which will help you identify who creates/modifies a plug-in in Architect.
1) Start Architect
2) From the "Tools" menu select "Options..."
3) Make sure the "General" tab is selected
4) In the "Author" field enter the developer's name. I find it is best to use the developer's network login name
5) Click "OK"
You must understand that this only allows you to identify who last saved the plug-in from the Architect. As RJ stated, SLX is not a multi-user development environment. What I just showed you will only allow you to identify who was working on what which I think answers your question for the moment.
There is no way to control who has access to any one plug-in at any point in time. Just to give you an example, a very bad example when using one development database: It is possible for three people to have the same plug-in open at the same time, modifying it and saving it!!! VERY BAD because the only version that will be saved is the last saved version! Each developer could have their own development database, but if they are working on the same thing you're going to run into problems. There is no way to merge plug-ins or anything, so if one developer has changed one part of a plug-in and the other developer changes another part there is no way to combine the two.
To quote RJLedger once more, "writing code is SIMPLE.. managing the process is complex."
Good luck!
John G.
|
|
|
| |
|
Re: SalesLogix Architect - Give Users Access To Programming
Posted: 13 May 09 2:57 PM
|
As a tangent to this thread, anyone have a great tool for obfuscating data in the dev environment? Currently sitting at just under 400 tables on v7.2.1; that's a lot o' scrubbing! 
We have tried the old ID as name, clear other fields as needed routine, but very hard to test business logic with that kind of data.
Michael |
|
|
|