Home | Forums | Contact | Search | Syndication  
 
 [login] [create account]   Sunday, August 24, 2025 
 
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!
 Architect Forums - SalesLogix Scripting & Customization
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.
Forums RSS Feed


 Back to Forum List | Back to SalesLogix Scripting & Customization | New ThreadView:  Search:  
 Author  Thread: Documenting changes
Carl
Posts: 11
 
Documenting changes Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 01 Jul 08 9:37 AM
Hiya,

I had a quick look to see if this has been asked before. Does any have any recommendations for documenting SLX customisations?

We have nothing in place here and our BP didn't give us any suggestions when they installed the system.

I can be a bit haphazard when doing customisations, getting them finished and then thinking ermmm what did I actually change. I've got an idea what sort of information should be documented, but I know I'll miss something important without some advice.

Also, do any of you ask the users to document changes they want and what sort of info would you ask them to provide ?

Thanks

Carl
[Reply][Quote]
Mike Spragg
Posts: 1226
Top 10 forum poster: 1226 posts
 
Re: Documenting changes Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 02 Jul 08 3:32 AM
The best thing to do is document in the code *and* produce a bundle of your changes (you can do this whilst building the project). If you are going in directly, modifying things, then (if you don't want to create bundles) you should create a separate code-form document that describes what you did, why etc. If you choose not to document anything - then, that's up to you ! But, if you ever have to share this with a colleague - they won't be too impressed !
[Reply][Quote]
Alexander Pfingstl
Posts: 43
 
Re: Documenting changes Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 02 Jul 08 5:44 AM
Hi,
What we do is write 'Begin of custom code at the beginning and 'End of custom code
at the end of our customisations.
When we need to update, we can search the forms scripts for this key words and find what we have changed.
This seems to work good for us.
Hope this helps!
[Reply][Quote]
Bob (RJ)Ledger
Posts: 1103
Top 10 forum poster: 1103 posts
 
Re: Documenting changes Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 02 Jul 08 6:20 AM
Like Mike & Alexander, we also:
a - Build an comment our projects (then create a bundle for off-line storage)
b - clearly identify the beginning/end of custtomization

We also identify temporary OOTB bug fixes as such too.
--
RJLedger - rjlSystems
"...Customer First..."
[Reply][Quote]
Dan Carvin
Posts: 227
 
Re: Documenting changes Your last visit to this thread was on 1/1/1970 12:00:00 AM
Posted: 02 Jul 08 10:17 AM
I like to keep an Excel spreadsheet that lists each plugin, the controls added/modified and a description of the change. This was especially useful in highly customized legacy systems where locating the code responsible for a specific behavoir can quite time-consuming. Searching the spreadsheet brings you right to the correct plugin.

[Reply][Quote]
 Page 1 of 1 
  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!
 

 
 slxdeveloper.com is brought to you courtesy of Ryan Farley & Customer FX Corporation.
 This site, and all contents herein, are Copyright © 2025 Customer FX Corporation. The information and opinions expressed here are not endorsed by Sage Software.

code of conduct | Subscribe to the slxdeveloper.com Latest Article RSS feed
   
 
page cache (param): 8/24/2025 7:10:07 AM