Code that deals with credit card data is primarily focused in credit card authorization, payment, season subscription areas, but is not limited to them.

Developers should be aware if they are modifying anything that can impact or change what we do with sensitive customer data, a senior developer must review it. Keep the PA-DSS guidelines in mind when developing in these areas is key, and you can review the Theatre Manager install documentation under PCI compliance.

	A change that may affect credit card processing needs to be reviewed carefully and is subject to the rules of Versioning Methodology
	When testing credit card functions, never use real card data, whether from customer or personal. We have test accounts and test credit card numbers that can be used to verify functions or issues reported by the user in the credit card area.

The following classes in the VCS are under the protection of the Senior Architect any potential changes to these classes need to be run by them first. These are the key base classes that affect credit card sales, refunds, exchanges, or storage of the credit card data.

• Any class with a name that starts with oCCAuthorize
• Any changes to the tfCreditCard table class that stores and encrypts data in the database.
• Any file, schema and table classes for ‘Merchant Setup’ such as fMerchant, sfMerchant, and tfMerchant
• Any changes to the wMerchant window

Theatre Manager uses some custom components written in C++ that are fundamental to the operation of the application because of how we use them to extend Omnis Studio. These are:

• Theatre Map - for displaying pictures on the screen. Changes to this library are handled through a test library that exposes all functions and methods.
• TMObjs - to improve performance on a small number of string related functions. Changes to this code are tested through an automated test library. See the systems architect.
• oWrite - a word processor purchased from Brainy Data.
oGantt - the gantt chart display tool purchased from Brainy Data.

When a new eternal component is available, all developers will use the latest version on their test platform while coding to uncover adverse effects for sufficient enough time as determined by the senior architect. Regression testing will also be performed prior to release by SQA.

The following super-class objects are important to the stability and function of the applications. Any changes to these require prior consultation and peer level review before and after changes are made:

• tableBase – the base table class for all database i/o
• any class that starts with ‘wModeless’ (wModeless, wModelessList, wModelessEntry, etc) – these are the 4 or 5 key windows that control and manage all GUI interaction and record i/o.
• any class that starts with ‘reportBase’ as they look after reports
• the oQuery and oQueryGroup objects as they are used to pass around an SQL query between objects.
• oStringFields - which handles specialized string manipulation
• oEditCheck - which handles special validation for certain kinds of data
• the oSecurity object that handles the Role Based Access Control

When testing any of the web objects and api’s, pay particular attention to validation of incoming parameters for any of the vulnerabilities mentioned in OWASP. Refer to the OWASP online documentation (especially the current top 10 list) and how Theatre Manager addresses those as part of your coding and testing the web components.

The object pertinent to web listeners are:

• Anything that starts with 'oWebCom' - each of which represents a unique API to the database from the web
• wWebSales - which is the GUI interface to the web component
• rtWebSales - which is the remote task started every time an end user sends a URL to the apache server.

  The web sales listener can only respond to traffic sent to it via the nginx module.

• cWebSales - the broker for transferring messages to/from the interface and any instance of a web object that was created