If you see this page in error or believe you should not have access to it, please contact management right away.
This part of the web site deals with policies and procedures.
Arts Management Systems' data and Customer's data is to be considered sensitive at all times and treated with the utmost care. This is especially true when it comes to data relating to PCI compliance and credit card information. There is also, in general terms, no need to have customer data transferred to our custody, especially with sensitive data in it.
It is Arts Management Systems policy that Employees:
![]() |
Standard practice requires removal of all card data before a database transfer is to occur (if a database needs to be transferred to AMS in the first place) |
-T fCreditCardsEncrypted parameters with pg_dump to ensure no such data is transmitted.
eg:the default parameters in the support script exclude any encrypted card data. other files can be added if they are large (other candidates are transactions, web logs and/or eblasts)
pg_dump -F c -v -T fCreditCardsEncrypted datbase > /path/to/backup.backup
![]() |
There are NO permitted exceptions that allow credit card data to be transferred out of the customer network at any time. The BackupTM_SUPPORT script must be used to create a backup that excludes encrypted card data before sending via secure https. |
Recognizing that employees may use Arts Management computers from time to time for non-related Arts Management business; this document outlines Arts Management’s position on the Acceptable Use of Computers Employees need adhere to during the performance of their duties.
It is Arts Management Systems policy that Employees:
It is often easier to understand acceptable use by identifying inappropriate use. The following list, while not exhaustive, exemplifies some unacceptable uses:
March 2006 – Does this mean we can not download music?
(Responded by Doug) If you have an iPod, iTunes or similar tool to store electronic music, then AMS views putting your own personal music on it as an acceptable use and it is up to you to manage their licenses to use your own music.
March 2006 – What do you mean by “Use of Network for Political Activity”?
(Responded by Doug) This is a tough question and it really goes to the purpose of the company network. It is primarily for company business and political activity really isn’t that.
So, for a completely crazy example, imagine somebody setting up a political web site for the Marijuana Party inside the router (AMS Network) that attracted millions of hits a second and overwhelmed things. AMS doesn’t think that would be quite appropriate as it would affect support, phone line quality, etc. It may also have a moral effect on the company.
Making a donation to a political party via the network - can't see a problem with that - its just a commerce thing.
Now, on the other hand, it doesn't mean political activity is out of the question. I personally believe that everybody should contribute back to the community in their own way. I choose to volunteer at StoryBook Theatre, my wife chooses to volunteer at school that the kids are at. If you, or someone chooses to volunteer for a political party - that great.
What the policy also states is that if you think this is a non-work task you want to do - lets say supporting a political campaign and doing e-mailers for them - then the right thing to do is first ask to have permission to use AMS resources for that. It is good for both the employee and AMS. Why? Because then everybody acknowledges that something is happening.
When I worked at Esso some 20 years back, they had a Permitted Use Policy on company resources. At that time the Internet and email really was nothing - didn't exist. (I sound like a dinosaur). But they did have policies on using company photocopiers. If you wanted to use it for personal things, you were supposed to ask permission. And, people did. My boss was big into the boy scouts - he had permission to do stuff for them, including time off. I was doing Storybook Theatre and I had permission to do the monthly minutes on the photocopier. That way, the boss knew where all his paper was going.
Acceptable use isn't no – it means acceptable, permitted, or planned use that is reasonable above board and consistent with good company stewardship. I think AMS should be quite happy to support extra curricular activities providing they are not to a detriment to the company’s purpose – provided permission is given. That’s a win for everybody.
March 2006 – Will I be able to use Personal Software on My Computer?
(Responded by Darwin) For personal software that is licensed to AMS, yourself and/or affiliated individuals, there should be no problems to install the software and use it on your work or home computer as long as the software’s main purpose is not listed or referred to in the Unacceptable Use section of this policy. With all software purchases, it is best to review the specific software license that came with the software to see if they have any specific licensing requirements when using their software and that you are in compliance with their listed licensing requirements.
Also, if the software is purchased or downloaded by an employee for personal use, permission should be sought to use it on a company machine. If your personal software does not affect the network, the machines intended use, or contravene the accepted use policy, it will more than likely be approved.
Bereavement leave enables employees to take time off work to deal with the death of a family member.
It is the policy of Arts Management Systems that Employees are entitled to be absent from work for bereavement up to 3 days, of which 2 days will be with pay. Additional paid leave is at the discretion of management approval.
Bereavement leave, sometimes called funeral leave, is time off work to help employees mourn the death of relatives or close friends, without fear of job loss. Bereavement leave normally serves two purposes, giving an employee time to attend a funeral service (i.e. fulfilling ceremonial obligations) and to mourn the loss of a loved one.
Employees may not be dismissed, suspended, laid off or demoted when on bereavement leave.
The province of Alberta does not legislate specific Employment Standards Code for bereavement leave. In jurisdictions without this legislated bereavement leave, the decision to grant time off or not is left to the employer.
How long can employees be off on bereavement leave?
Although the Province of Alberta does not legislate specific bereavement leave under The Employment Standards Code, most jurisdictions and workplaces allows employees to take up to 3 days as bereavement leave to deal with the death of a family member as unpaid bereavement leave. In jurisdictions without this legislated bereavement leave, the decision to grant time off or not is left to the employer. AMS is following the standard bereavement time of 3 days of which the first 2 days are with pay.
Does bereavement leave need to be taken as consecutive days?
No. Bereavement leave time does not need to be consecutive days and AMS acknowledges that the the days taken for bereavement may vary depending on each employee's unique situation.
Who can take bereavement leave?
All employees without exception.
Are employees required to be paid while on bereavement leave?
No, the legislation only requires an employer to provide time off and allow an employee to return to their job when the leave has ended. Employers are not required to pay wages during the leave. Employers can at their own discretion, give greater benefits than those provided for in the legislation.
Is an employee entitled to be paid for bereavement leave?
Yes, provided the employee has been continuously employed for at least 30 consecutive days. Employees who have been employed for less then 30 consecutive days are still entitled to take bereavement leave as unpaid leave.
Can an employee continue to work and be paid for bereavement leave at the same time?
No. Bereavement leave is a benefit that should not be seen a method to incur additional paid wages; it is time provided to the employee to take time away from work to help mourn the death of relatives or close friends without fear of job loss.
Must an employee take bereavement leave?
No. AMS acknowledges that each employee is unique and may not desire to take bereavement leave. However management does reserve the right to request that the employee take time for bereavement if it is determined that the employee showing signs of (but not limited to):
Who are considered family members?
Family is defined very broadly for Employment Standards’ purposes.
What must employees who take bereavement leave tell their employer?
Employees must tell their employer, as soon as possible, which days they will need off. Employers can request reasonable verification that the leave is needed.
What is reasonable verification?
Employers can request reasonable verification of the need for the leave. Reasonable verification for bereavement leave might be an obituary from a local newspaper or medical death certificate.
Can employees take part of a day as bereavement leave?
When an employee takes part of a day for bereavement leave, the employer may count that as a full day of the leave. Employers do not have to accommodate an employee taking the leave in part days, as long as they allow the employee to take the leave.
Can employees be fired or laid off because they take bereavement leave?
No. Employers cannot terminate or lay off employees because they have taken or are planning to take a leave.
What happens when the leave ends?
Employees must be allowed to return to their job, or a comparable job with the same or greater benefits and pay, when they return from leave. Employers may not discriminate or attempt to punish employees for taking a leave.
What happens to the employment history and benefits while an employee is on leave?
While employees are on paid/unpaid leave the employment is deemed to be continuous. When employees return from the leave they are still entitled to any benefits they had before the leave, and their years of service include the time away on the leave.
Is bereavement leave an annual entitlement?
The entitlement to bereavement leave is not an annual entitlement. If an employee suffers more than one death in the family in one year, the employee would be entitled to bereavement leave for each of those deaths.
Is bereavement leave combined in the event of multiple deaths?
The entitlement to bereavement leave is not combined in the event of multiple deaths. If an employee suffers more than one death in the family in a single incident, the employee would be entitled to bereavement leave for each of those deaths as if they occurred separately.
Is bereavement leave additional to regular scheduled days off or preplanned vacation days?
No. Bereavement leave covers only scheduled working days. If the death occurred during an employee's vacation, bereavement leave would not apply.
Can other employees donate their vacation time to another employee for bereavement leave?
In most cases, yes. Employees must inform AMS management, as soon as possible, if they intend to use a portion of their vacation days as a donation to another co-worker. It is at the discretion of AMS management to accept this donation or not. Management will verify that the employee donating the vacation days has adequate vacation time to donate along with enough remaining available vacation days for the donating employee's personal use.
Recognizing that employees may use Arts Management computers from time to time for non-related Arts Management business; this document outlines Arts Management’s position on the Network Security Employees need adhere to during the performance of their duties.
It is Arts Management Systems policy that Employees:
There are no general questions at this time.
Overtime and Days in Lieu compensates employees when they are required to work in excess of the limits defined in the Employment Standards Code.
It is the policy of Arts Management Systems that allows Employees overtime hours to be banked and later taken off with pay, hour for hour, during regular work hours. Overtime hours can be banked for a period of 3 months. Banked time not taken within the 3 month period may be paid out at time-and-a-half.
In Alberta, under the Employment Standards Code, overtime is treated on a daily and/or weekly status. Overtime must be paid to all employees (regardless if they are paid a weekly, monthly, or annual salary except if they are exempt) on hours worked in excess of eight hours a day or 44 hours per week, whichever is greater (the higher of the two numbers is overtime hours worked in the week). The overtime rate is 1.5 times an employee’s regular rate of pay unless the employer and employee have entered into an overtime agreement.
If a General Holiday (Public/Statutory Holiday) is worked
Hours worked on a general holiday and paid at 1.5 times the regular wage are not used in computing either daily or weekly overtime. However, when employees do not qualify for the general holiday or if they are given another work day off with pay in lieu of working on the general holiday, the hours are counted for the purpose of calculation overtime.
If training happens on a Saturday only for a weekend stayover, is the Saturday recognized as a potential Banked Time in Lieu?
Yes. The Saturday will be available to be recognized as potential overtime. Because no training was done on Sunday, Sunday is not available to be recognized as potential overtime.
Do I have to work overtime at night to complete a task for the client?
AMS views its clients as professionals. Our clients expect us to be professionals when we are either in the office or onsite. The goal is to make the client successful. When the client succeeds, you will succeed, and by default, AMS will succeed. AMS strongly recommends that you evaluate your time when onsite and use ‘wasted time’ or ‘idle time’ when onsite to compete tasks in order to avoid being in a situation where overtime may become required.
If there are tasks such as map building, data conversion preparation, event building, season subscription preparation, etc. where the task could be done by the client, explain to the client that in order to stay on schedule, human resources/time needs to be allocated to complete the task. The client can determine if they have the available resources to complete the task in the required timeframe or if they need to authorize AMS to complete the task on their behalf (i.e. back in Calgary’s office, or in the hotel room at night). When the client determines that they need the assistance of AMS, it is an easy acceptance process for them to acknowledge that overtime is required and that they will be invoiced for it.
If the client does not authorize the overtime and the uncompleted task impacts the scheduled agenda, work with the client to rework the scheduled agenda to accommodate the uncompleted task into the next days schedule. Reorganize either the remaining training topics for the remaining time period, or mutually agree on training topics that can be removed from the training agenda.
Arts Management Systems Ltd, is committed to a healthy, harassment-free work environment for all our employees. Arts Management Systems Ltd. has developed a company-wide policy intended to prevent harassment of any type, including sexual harassment, of its employees, customers and clients and to deal quickly and effectively with any incident that might occur.
Harassment that is covered under the Alberta Human Rights Act occurs when an employee is subjected to unwelcome verbal or physical conduct because of race, religious beliefs, colour, gender, gender identity, gender expression, physical disability, mental disability, age, ancestry, place of origin, marital status, source of income, family status or sexual orientation. Alberta human rights law prohibits workplace harassment based on these grounds. Harassment that is not linked to one of these protected grounds is not covered under the Act. The behaviour need not be intentional in order to be considered harassment.
Examples of harassment that will not be tolerated in Arts Management Systems Ltd. are: verbal or physical abuse, threats, derogatory remarks, jokes, innuendo or taunts related to any employee's race, religious beliefs, colour, gender, gender identity, gender expression, physical disability, mental disability, age, ancestry, place of origin, marital status, source of income, family status or sexual orientation. Arts Management Systems Ltd. also will not tolerate the display of pornographic, racist or offensive signs or images; offensive jokes based on race, gender or other grounds protected under the Act that result in awkwardness or embarrassment; and unwelcome invitations or requests, whether indirect or explicit.
The Alberta Human Rights Act prohibits discrimination based on the ground of gender. Protection from sexual harassment is included under the ground of gender. Unwanted sexual advances, unwanted requests for sexual favours, and other unwanted verbal or physical conduct of a sexual nature constitute sexual harassment when:
submission to such conduct is made either explicitly or implicitly a term or condition of an individual's employment; or submission to, or rejection of, such conduct by an individual affects that individual's employment.
Sexual harassment can include such things as pinching, patting, rubbing or leering, "dirty" jokes, pictures or pornographic materials, comments, suggestions, innuendoes, requests or demands of a sexual nature. All harassment is offensive and in many cases it intimidates others. It will not be tolerated within our company.
How to proceed if you are being harassed
a. Department Manager (if possible) b. Director of Human Resources c. Union Representative
You also have the right to contact the Alberta Human Rights Commission to make a complaint of harassment that is based on any of the grounds protected from discrimination under the Alberta Human Rights Act. The protected grounds are: race, religious beliefs, colour, gender, gender identity, gender expression, physical disability, mental disability, age, ancestry, place of origin, marital status, source of income, family status and sexual orientation. You can also report any incident of assault that has occurred to the police.
Internal harassment complaint process
Once an internal complaint is received by Arts Management Systems Ltd., it will be kept strictly confidential. Appropriate action will be undertaken immediately to deal with the allegations. Action taken may include mediation. The Department Manager will interview you as well as the alleged harasser and any individuals who may be able to provide relevant information related to your allegations. All information collected will be kept in confidence. If appropriate, Arts Management Systems Ltd. will attempt to resolve the complaint by mediation. If mediation is not successful, an investigation will be undertaken by an investigator designated by Arts Management Systems Ltd. If the investigation reveals evidence to support the complaint of harassment, the harasser will be disciplined appropriately. Discipline may include suspension or dismissal, and the incident will be documented in the harasser's file. No documentation will be placed on the complainant's file when the complaint has been made in good faith, whether or not there was a finding of harassment. If the investigation fails to find evidence to support the complaint, there will be no documentation concerning the complaint placed in the file of the alleged harasser. Regardless of the outcome of a harassment complaint made in good faith, the employee lodging the complaint as well as anyone providing information will be protected from any form of retaliation by either co-workers or superiors. This includes dismissal, demotion, unwanted transfer, denial of opportunities within the company or harassment for having made a complaint or having provided evidence regarding the complaint.
Responsibility of management
It is the responsibility of a director, manager or any other person within this company who supervises one or more employees to take immediate and appropriate action to report or deal with incidents of harassment of any type, whether brought to their attention or personally observed. Under no circumstances should a complaint be dismissed or downplayed, nor should the complainant be told to deal with it personally.
Arts Management Systems Ltd. seeks to provide a safe, healthy and rewarding work environment for its employees, clients and customers. Harassment will not be tolerated within our company. If you feel that you are being harassed, contact us. We want to hear from you.
Sick leave enables employees to take time off work when ill.
It is the policy of Arts Management Systems that Employees are entitled to be sick or absentee from work due to illness up to 5 consecutive days with pay.
Sick leave enables employees to take time off work when ill. It is not intended for leave of family obligations although it may sometimes be used as such.
Employees may not be dismissed, suspended, laid off or demoted when on sick leave.
If an employee was absent from work for a scheduled shift and was paid sick pay by the employer for that day, can the employee be required to make up a shift?
Yes. Sick pay or any absenteeism is not wages and sick days do not constitute hours of work.
Artsman's Supplemental Unemployment Benefit Program is in place to comply with Service Canada's SUB program.
Employers can use a Supplemental Unemployment Benefit (SUB) plan to increase their employees’ weekly earnings when they are unemployed due to a temporary stoppage of work, training, illness, injury or quarantine.
Payments from SUB plans that are registered with Service Canada are not considered as earnings and are not deducted from EI benefits (pursuant to subsection 37(1) of the EI Regulations).
1. The plan covers the following group(s) of employees:
All full time employees with 1 year of service.
2. The plan will supplement EI benefits for periods of unemployment caused by illness.
3. Verification that the employees have applied for and are in receipt of EI benefits will be made before SUB payments are paid.
4. The SUB is payable at 95% of the employee's normal weekly earnings while the employee is serving the one-week EI waiting period.
5. Option B (automatic adjustment): The plan provides that the gross amount of EI benefit from this employment plus the SUB payment will equal 95% of the employee's normal weekly earnings.
6. The plan provides SUB payments for at least 4 weeks
With management approval, payments can be made longer than 4 weeks, depending on the situation.
7. The start date of the plan is:
May 10, 2021.
8. Service Canada - SUB Program will be informed in writing of any change to the plan within 30 days of the effective date of the change.
9. The plan is financed by the employer's general revenues.
10. SUB payments will not reduce any guaranteed annual remuneration, deferred remuneration, or severance pay.
11. This plan provides for an offset of EI benefits that may have to be repaid as part of the employee's income tax return. The weekly gross EI benefit from this employment, the SUB payments previously paid plus this offset amount will not exceed 95% of the employee's normal weekly earnings.
12. Should the SUB plan terminate, all remaining assets will revert to the employer, be used for SUB payments and/or be used for the administrative costs of the plan.
13. Employees do not have a right to SUB payments except during the period of unemployment specified in the plan.
Recognizing that employees may be required to incur office related expenses and to travel from time to time on Arts Management related business; this document outlines Arts Management’s position on the reimbursement of those expenses the Employee may incur during the performance of their duties.
It is the policy of Arts Management Systems that Employees will be reimbursed the actual cost of expenses, which have been wholly, exclusively and necessarily incurred in the performance of their duties.
There are no general questions at this time.
Vacation entitlement is granted with two purposes in mind. Firstly, a period of rest and relaxation benefits the employee both physically and mentally without loss of income; and secondly, vacation entitlement is a management tool for recognizing the longevity of service years of the employee.
It is the policy of Arts Management Systems that Employees are entitled to vacation with pay based on their job level, position and years of service.
The entitlement to vacations and vacation pay are intended to ensure that employees annually have a rest from work without loss of income.
The basic entitlement to annual vacations is as follows:
| Service | Vacation Time | Earning Rate |
| 12 months | 10 work days | 1 1/4 days |
| 5 years | 15 work days | 1 2/3 days |
| 10 years | 20 work days | 2 1/12 days |
| 15 years | 25 work days | 2 1/2 days |
| 20 years | 30 work days |
The above entitlements will apply in all cases unless superseded by contracted agreements at point of hire. All such contracted agreements must be reviewed with the Human Resources Department prior to commitment with the new employee.
Employees have a choice on how they receive payment for money that would be due during vacation
In all Canadian jurisdictions, it is the employer's prerogative to determine when each employee may take an annual vacation, within certain limits laid down by law. First, a vacation must be granted within a specified period after the date on which the employee becomes entitled to it. Second, it is required that employers provide a minimum at least two weeks of notice to their employees before they start their vacation. It is recommended vacation be scheduled at least 4 months in advance to ensure availability within the scheduling calendar. Obviously, such notice is not normally necessary where an employer and an employee agree on a mutually satisfactory vacation starting date.
The postponement of an annual vacation for a specified year of employment is expressly permitted, subject to certain conditions:
There are 9 statutory holidays that are observed by AMS per Alberta guidelines and 1 personal floater day, for a total of 10 days. November 11th (Remembrance Day) is a standard holiday and at the employee's option, this may be deferred to another day such as Boxing Day.
If a holiday falls on a non-workday then another day will be observed as the holiday - usually the preceding Friday or the following Monday. The Labour Standards Act leaves it up to the employer to decide.
The following days are observed as Statutory Holidays:
Other days that are not official Statutory Holidays, but could be observed by using your personal floater day:
Upon employee request, can vacation with pay be given prior to completing a full 12 months of employment?
Yes, if the employer agrees. Typically, at least 6 months of service must have been completed.
What if a general holiday falls within an employee's annual vacation?
If eligible for the general holiday, the employee is entitled to take off either the first scheduled working day after their vacation, or in agreement with the employer, another day before the next annual vacation (that would otherwise have been a work day for the employee).
If an employee has been paid vacation pay but not given vacation time, can they choose not to take vacation time?
No. Employers must give, and employees must take, the vacation time to which they are entitled. Where employees have already been paid vacation pay, this time off will be without pay.
If employment is terminated before the employee completes 12 months of employment, what vacation pay is owing?
Four per cent of the employee's wages earned during the period of employment.
If employment is terminated after the employee completes 12 months of employment, what vacation pay is owing?
When is vacation pay to be paid to an employee whose employment is terminated?
Arts Management Systems has a Private Cloud Network option to assist clients with hardware needs related to the Theatre Manager database and online sales.
Private Cloud Package provides the needs for:
When using the cloud, the venue is only responsible for providing workstations for the employee to use and sufficient internet bandwidth to access the data in the AMS cloud. Users can access their data from anywhere.
| Item | Notes | Responsibility | |
|---|---|---|---|
| 1.1 |
Consult with client and make sure that they are aware of their options for how they want to implement PCI compliance in the database. Options are one or more of the items below:
|
Sales | |
| 1.2 |
Make sure that their internet is of sufficient speed and robustness to accommodate web sales.
|
Sales/Support | |
| 1.3 | Identify if the migration is also including an upgrade in the version of Theatre Manager and/or migration of web pages. This will affect estimates | Sales | |
| 1.4 |
TLS Certificates:
|
Sales/Support | |
| 1.5 | If migrating to the AMS Cloud from an existing client, identify the prospective date for conversion, with alternates. | Sales | |
| 1.6 |
The client will lose the ability to sell tickets or make changes to their database for a period of time. If an guesstimate is needed, it can be derived as follows:
|
Sales/Support |
| Item | Notes | Responsible |
|---|---|---|
| 2.1 |
Create initial settings in AMS cloud Server Database. This involves:
|
Development |
| 2.2 |
Set up Web Sales
|
Development |
| 2.3 |
Setup main web server with routing/TLS
|
Support |
| 2.4 |
Setup Web Sales
|
Support |
| Item | Notes | Responsibility |
|---|---|---|
| 3.1 |
Initiate change of your external DNS record CNAME for tickets.myvenue.org to point to myvenue.hosted.artsman.com.
we will create the DNS record for myvenue.hosted.artsman.com |
Support |
| 3.2 |
Start the backup an migration process for the database
|
Support |
| 3.3 |
Load up the database
|
Development |
| 3.4 | Make sure that the database has a unique DB USER SUFFIX specified in system preferences. If building a training database, also make a unique one for it by clicking the 'test' database option. | Development |
| 3.5 |
Upgrade database to latest version - always done on our cloud computers.
This occurs automatically when Theatre Manager Server started on the Sites Web Sales VM |
Support/Development |
| 3.6 |
Make sure timezone is correct on the system preferences and then update all performances to make sure the performance date time is set correctly for the timezone. In PgAdmin, use:
set timezone 'xxxx'; Update F_PLAYBILL set PB_PERFORM_DATETIME = null returning PB_SEQ,PB_PERFORM_DATETIME |
Support/Development |
| 3.7 |
Test the AMS login procedures with the info that was saved in Daylite.
When it works internally:
|
Support |
| 3.8 |
Start and test web sales, including:
|
Support |
| 3.9 |
Test Client's email server settings by making sure you:
If the client uses Facility Management, make sure the scheduling email and pop/imap server work. |
Support |
| 3.10 | Test Reveal Setup - have one of the employees sign in and view their Reveal Dashboards and see that they can see/create graphs. | Support |
| 3.11 | If the client has built services that rely on the REST API for their main marketing site, make sure that they are working. | Support |
| Competitor | Sample Site | Comments Quirks or Additional Features | |||||
| Arts Man | tickets.artsman.com |
|
|||||
| AudienceView | calshakes.org | ||||||
| Choice Tickets | $1.50 fee $2.00 academic fee |
Kingsbury Hall | |||||
| OvationTix | colonytheatre.org |
|
|||||
| Patron Manager | orlandoshakes.org | ||||||
| Showare | mtroyal.ca | ||||||
| Spektrix | bardonthebeach.org | ||||||
| Tessitura | strazcenter.org | ||||||
| TicketFly | redbuttegarden.org | ||||||
| TopTix | vancouverfringe.com |
|
Providing exceptional customer support and developing trust with our customers is something that takes a long time to create, while at the same time is something that rapidly degrades without proper care and attention.
When we develop that trust and mutual understanding with our customers; all aspects of Arts Managements relationship with that customer improves, including sales, references, ease of answering future support questions, onsite training, etc.
Customer satisfaction is completely within the Support Team’s roles and responsibilities because they interact with the customer most often after the initial sale.
Provide prompt and accurate customer support the first time upholding to the corporate goals and image every time the client requires assistance, by using past experience, existing tools, and carefully proven methods.
The goal is excellent customer service. We will try to quantify it this way such that the initial response to:
Primary support represents the initial contact that a customer makes with our support team. Generally, the roles and responsibilities are
The purpose of second level support is to provide a developer level resource to the support team who can examine code for issues if necessary or provide a greater depth of experience based on understanding what is going on 'behind the scenes'.
The responsibility of second level support is:
Listen to the voice mail in quicktime and do the following with it:
The goal is that any question that could be answered more than once must be answered with reference to a web page so that procedures and processes are consistent throughout all support responses.
All staff members are responsible for:
When a new venue comes on board or there is a staff change at an organization, the responsibility of the primary support team is to update Daylite with new contact information and/or correct some existing information at the start of the support process.
Some issues will consume an inordinate amount of time and may or may not be chargeable back to the customers if they are asking us to do something that ordinarily they should be doing. Since the primary purpose of support is provide 'how to' answers, and most of these fall into 'do it for them', you may have to confirm with sales if is it to be charged back or not.
In all cases, time consuming issues are to be done after primary support items are dealt with unless given as a special project.
Examples are:
Prior to leaving the office, there is to be a turn-over process.
Remember: complete or turn over all cases prior to going on a protracted leave and advise your team of any peculiarities on the case
|
All Theatre Manager access passwords are required to be PCI compliant in Version 9 |
Be there ready to begin support at 8:00AM. Not 8:15AM, not 8:25AM.
Those on the easy coast might start a little earlier if arranged with management and support volume warrants it.
By around 4:30, we need to start the process of closing the support day - and at the same time deal with ongoing incoming requests. Above all, we want to make sure that we meet the overall goals of responding to voice mail within 1 hour/same business day and email within 4 hours.
Near the close of day, re-prioritize all support. At this time, the general expectations before closing up for the night are:
Some factors to consider when altering priority of support requests are below. If more than one applies, accumulate the effect. For example if a customer calls twice, is on after hours, and says that they cannot sell a ticket, then that is +5+5+10 -> so that makes it high priority
| Factors affecting Priority | Effect | Subsequent Action |
| Venues that cannot process a sale | +10 | Call the customer immediately |
| Any issue where data is not being stored in the database properly | +8 | Call Customer and then after validation of the issue, Contact Tier II Immediately. Any data issues are of prime importance. |
| People with after hours support that left a message overnight | +5 | Call the customer back and follow up response with email of link to web help, if applicable. |
| People who phone for support | +3 | Evaluate contents of voice mail and email response and/or call back | People who left an email after close of business the prior day | +2 |
| An extension to an existing support case with the same topic | +1 | if the customer is not seeing the answer being provided, call the customer. |
| People requesting status on existing Tier II reguest | +1 | attach new case (if there is one) to original case, determine status from Tier II and email the status to customer. |
| East coast support requests (mid afternoon only) | +1 | Give time zone priority over west coast for email responses |
| An extension to an existing support case with a new topic | neutral | Create a new case and evaluate as normal priority |
| People who send a support personal email to a personal email account | neutral | Create a case and treat in order entered. Inform customer that email was logged with the case number. |
| A new case concerining an item already elevated to Tier II support | -1 | attach new case as subcase of the original and email client that the information was attached to an existing case. |
| People who have been provided a workround but insist on a fix to Theatre Manager | -5 | bring to attention of management |
![]() |
There are NO permitted exceptions that allow credit card data to be transferred out of the customer network at any time. The BackupTM_SUPPORT script must be used to create a backup that excludes encrypted card data before sending via secure https. |

When reviewing cases in the support log, they will be sorted in a natural action-item order. The version column indicates what version the user has in which the issue as noted. Priority indicates when it might be addressed. Developers will use the filter action to look for their own cases for specific development milestones.

You can also enter descriptions in this field such as ‘Gift Certificate’ to find all issues with those words in the title or the text of the case. See the FogBugz help for more details.

This is the general description of what is wrong. Depending on the source of the issue there may be step-by-step instructions to reproduce, or just a blab of text asking for something to work a certain way. If you don’t understand the description, get clarification from the submitter or the correspondent. The submitter is the person who created the task (‘opened by’). The correspondent is the email address of the customer who submitted or reported the issue.
Enter a longer description of the problem or issue at hand, including the steps to re-create the issue. If appropriate, including specific patron numbers, order numbers, ticket numbers (or ticket section/Row/Seat/Event/Performance), shows, shopping carts and attach screenshots using the 'Attach File' link at the bottom of the screen.
For new development tasks, or task transferred from support to development:

History of a bug is obtained simply by clicking on it. This tracks a chronological view of every change made to the task, who changed it, and comments relating to the change and why. It could be thought of as a ‘long email’ with a historical trail.
Sometimes, a client may submit multiple issues that may, in fact, be related. You can view them simply by running your mouse over the other cases sent by the correspondent.
If cases are deemed related, they should be filed as ‘sub-cases’ of the main case.
You can also see the entire history of the corespondent by clicking on the email. Click on the first half to see that person, click on the domain name to see everything from that domain (or company)

Replying to the originator (which could be a customer) means finding the last thread where the customer corresponded and replying to that with your resolution and the proposed version in which the fix will be released. Add any links to online help in theatremanagerhelp.com that are pertinent to the problems.
Start by selecting the category of issue that this will be, then use the following guidelines.
When a case has been created and assigned to you (perhaps by another person), you should also receive an automatic email with the case number and a link to the case so that you can find it quickly. If you reassign a case to another person, they will then get an email.
It is recommended that you have a separate 'case' folder in your email program and use 'mail rules' to move cases there automatically. Anything that is unread is, of course, new or has a change of state.
Mail will keep those threaded for convenience.

Prior to working on an issue, developers should ensure that an issue has been logged in the defect tracking tool. If an issue is not logged, then the developer should escalate the issue to management to confirm priority.
The defect tracking tool used by Arts Management Systems development is FogBugz. While this document is not meant to be a complete guide to using this tool, there is a list of common tasks a developer should know how to do in the FogBugz Tutorial.
System administration for FogBugz is handled by the Arts Management IT and Product Development Department. FogBugz is accessed via the web and signing in at mail.artsman.com/fogbugz/
All Arts Management personnel with access to FogBugz can submit issues into the defect tracking database. Customers submitting support requests arrive in the same database. Arts Management staff can directly convert a support request to a development issue if it is determined to be a program issue. If you do not have access to FogBugz, contact the Development Team to be issued an ID and Password.
Feature and change requests will also be submitted to the Product Design Team.
The issues reported from SQA will include refinements to existing issues, new issues caused by a break to existing code, and change requests.
Issues logged during user acceptance testing will have step-by-step instructions to recreate and sample data if necessary (see the section below entitled Secure Storage System).
Within a Target Release tasks should be accomplished based on severity. However, new features and change requests should be implemented prior to bug fixing.
Severity is assigned by the Development Manager
| 1 | Fix Immediately | Critical issue causes a system crash, data loss or corruption. The system becomes unstable or unusable. No workaround exists. Items of this nature should be fixed immediately in a patch release. |
| 2 | Fix next point release | Problem of a serious nature causes the software to operate in an unpredictable or detrimental manner with a serious adverse impact to the user. Major functionality is missing or broken. Workaround exists but is unacceptable. |
| 3 | Fix in point release if possible, incremental otherwise | A moderate problem causes system functionality to degrade with a moderate adverse impact to the user. Minor functionality is missing or broken. An acceptable workaround to the problem exists. |
| 4 | Fix next incremental release | The problem is not detrimental to the operation of the system. It is scheduled for correction in a future major release. |
| 5 | Fix if Time | The problem is not detrimental to the operation of the system and will be addressed for the proposed version if there is time. Can be deferred to any subsequent version |
| 6 | Undecided | Priority or severity has not been assigned yet |
| 7 | Rejected | Issue has been reported that has been determined as either not a bug, how the system operates, or has simply been rejected. |
The first step a developer should go through when faced with a new issue is to validate the issue. Put simply, this is deciding, if given what the user is trying to accomplish, is the software behaving in the way expected. It is typically at this stage that the developer will also do an “its different therefore it’s wrong” check. Given the long adoption cycle for Point Of Sale software, there are issues that will occasionally slip past the Product Management review process in which a user is effectively reporting that because a goal is achieved in a different means from a previous version, it is a bug.
If this is the expected behavior then the issue should be rejected and marked “works as designed”.
At this point the developer may also encounter an issue which works as designed, but the “bug” suggested in the issue is in fact a good idea for a feature that has not been implemented. At this point the developer should contact product management about the possibility of creating a new feature or a Change Request that incorporates the functionality indicated - and then make an entry in FogBugz to begin the change tracking process.
If it appears the software is behaving erratically it is important to try and recreate the fault. If the problem cannot be recreated or cannot be supported with logs by the developer or the business partners onsite it is most likely not an issue with the software, but an issue with the state of the platform the software was running on.
If the issue cannot be recreated and there are no logs to support it, the issue should be rejected and marked “can not reproduce”. The customer should be advised to enable auditing and logging for a time to see if the problem persists, and if additional data can be captured.
As our software deals with sensitive data all changes to the software should always trigger discussion as to the impact of the change on the security of the applications and the data relating to PCI PA-DSS compliance and a worksheet completed if it is determined that the code change may affect sensitive information.
In the case where the developer needs more information to proceed, the issue can be returned to the submitter with a request for more information.
When the solution for an issue will impact other parts of the application or the overall functionality of the application, the issue can be sent to the design group and marked “needs design”. The developer in most cases should include a summary of what the potential impact is going to be, to avoid having the designer try to replicate the work already done in investigation by the developer. Meetings and discussions with the designer may be needed to ensure clarity of what the issues are.
A technical specification is required for all significant new development. Other issues should be accompanied by a technical specification if the changes the issue required were significant enough to merit a functional design. A technical specification can also be required for other reasons, and your supervisor will advise you if one is required for a given task. A good general guideline is to ask yourself “Is this complex enough that another developer would have difficulty following what is going to be done without a document?”
A technical specification is generally not required for bug fixes.
There is no written in stone outline of what must go into a technical specification. There is a template for the specification located on the internal share point portal, but that is meant as a starting place. You should include enough detail in your technical specification so that if you were to no longer be available, another developer could successfully implement it.
The template for the technical specification is located on the Artsman file server in the TM Development/TM Design Documents folder and is called AMS Design Template.doc. Documents are to be named ‘yymmdd
The template is meant to be an example or a guideline to the way a technical specification might appear. Sections may be deleted as needed or rearranged as necessary.
Once a technical specification is complete you must have a peer review before implementing the proposed changes. This peer review is not to judge the quality of the developers work, but the quality of the proposed solution as well as its compatibility with other areas of the system. A proposal that might be absolutely perfect for one area can completely destroy functionality in another if it is not compatible.
The peer review need not be in person. Copies of the technical specification can be emailed to participants with revision tracking turned on and then reviewed as they come back one at a time.
A good technical specification review will include other developers that can critique the methods and code that are going to be used. Design and SQA can benefit from the information as well, but are not a required part of the review process.
Sensitive areas of the application including, but not necessarily limited to, any protected classes should have limited peer review. This review should include the developer and one member of the Architecture team.Optional elements
Peer Review
Methods
Persons involved
Security Concerns
While this document does not cover the use of our version control software extensively, Omnis Studio VCS does have a list of common tasks a developer should know how to do.
The development platform will be primarily Mac OSX using Omnis Studio and Python.
Compatibility testing for Windows will occur on the Mac under a Parallels Virtual Machine on Vista, Windows 7, Windows 8, Win 10, Win 2008 and Win 2012 server
Primary Development is done using:
There are a number of other tools that are used by developers for specific tasks. If you have doubt about using a tool consult your supervisor or one of the architects. Most source text editing is done with BBedit (eg for web pages and plist files)
All code and key are stored in as VCS, specifically the Omnis Studio VCS or the Git Repository.
There are documented coding guidelines that Arts Management Systems developers should follow.
Arts Management Systems developers are expected to stay current on issues and potential security vulnerabilities in the technology used in the Arts Management Systems product. Arts Management Systems architects will be responsible for monitoring these areas and escalating to management when an issue arises that needs to be addressed in a future product release.
In-code documentation is required for all new code as described in the coding practices.
There are a few areas of the application that are critical for the stability of the product. As such they are the responsibility of the senior developers and architects to maintain. These are called protected classes and you need to contact the architect if you need to work with them and have a mandatory code review after you change them.
With step through testing, you can quickly throw a lot of small tests at a bit of code. An example might be converting a number to text. Adjusting the input parameters and stepping over code to see the results can quickly test many different parameters.
NB: Make sure any testing uses only test cards and never use real credit cards in a non-production environment.
When altering any code that deals with credit card information, it is important that key tests are performed to ensure the software remains in PCI compliance. All security patches and system and software changes need to be tested before being deployed, including but not limited to testing for the following.
| PA-DSS | Requirement | Testing Procedure | What we do in Theatre Manager |
| 5.1.1.1 | Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) | Validation of all input (to prevent cross-site scripting, injection flaws, malicious file execution, etc.) | When using the Theatre Manager application, input validation for almost all fields is done through the specialzed protected class called oEditCheck which does specialized validation on inputs. Every text input field in the system will invoke a method from this class. Test your code in the 'evAfter' clauses to make sure that it does for all entry fields.
Since the Theatre Manager 'fat' client is a compliled application and not web based, much of this PCI requirement does not apply. The Theatre Manager commerce web server uses the same edit routines as the 'fat' client but has cleansing routines for parsing data prior to it hitting the edit routines. Refer to OWASP below. |
| 5.1.1.2 | Validation of proper error handling | Validation of proper error handling | particularly for credit card information, make sure that data is not diplayed back to an operator or customer that shows the entire PAN when errors occur. Refer to 5.1.1.5 for routines to display protected information appropriately. |
| 5.1.1.3 | Validation of secure cryptographic storage | Validation of secure cryptographic storage | all card information is updated in the database using a single protected classes called tfCreditCard.$reviseCreditCard. All access to cards is through that protected class and any use will ensure that cards are encrypted properly. However, after a test using credit cards, do an sql query on CD_CARD_NO to make sure nothing exists in clear text. |
| 5.1.1.4 | Validation of secure communications | Validation of secure communications | Card authorization occurs in via https and the merchant providerl. The protected classes oCCAuthorize handle all https communication and will not respond unless the merchant provider supports TLS 1.2 or later (high encryption) |
| 5.1.1.5 | Validation of proper role-based access control (RBAC) | Validation of proper role-based access control (RBAC) | Access to card information is managed in Theatre Manager through a protected class called oSecurity. All display of credit card information is done through another protected class called oEditCheck.$fetchCreditCard which converts all items for display using RBAC. |
For web based components (i.e oWebComxxx), ensure that OWASP vulnerabilities are also tested and verified per PA-DSS standards 5.2.1-5.2.10. This section in the PA-DSS document repeats the current top 10 OWASP vulnerabilities (circa 2010) and are repeated below. Make sure to test those as well as review OWASP to keep this section of the test requirements evergreen.
Above all, read the OWASP top 10 when developing a Web API because they explain clearly what things mean and strategies how to avoid.
| PA-DSS | Requirement | Testing Procedure | What we do in Theatre Manager |
| 5.2.1 | Cross-site scripting (XSS). | Cross-site scripting (XSS) (Validate all parameters before inclusion.) | Look at any incoming parameters for javascript and other characters and simply removes them. We have determined that there is no valid need to have words like <script> in a enterable fields like name or address. Refer to rtWebSales.cleanUpParameters |
5.2.2 |
Injection flaws, particularly SQL injection. Also consider LDAP and Xpath injection flaws, as well as other injection flaws. | Injection flaws, particularly SQL injection (Validate input to verify user data cannot modify meaning of commands and queries.) | none of the API's in any oWebComXXX accept SQL for input. Make sure each parameter is checked for existance and validity using oWebComBase.$getWebParameters. |
| 5.2.3 | Malicious file execution | Malicious file execution (Validate input to verify application does not accept filenames or files from users.) | ensure that oWebComXXXX does not accept file names and does not read the file system. All input is sanitized and merged into variables of fixed length (the nature of Omnis Studio) so buffer overflows are not possible. |
| 5.2.4 | Insecure direct object references. | Insecure direct object references (Do not expose internal object references to users.) | OWASP recommends use of API's to address this issue. Build a new oWebComXXX for each web function. |
| 5.2.5 | Cross-site request forgery (CSRF). | Cross-site request forgery (CSRF) (Do not rely on authorization credentials and tokens automatically submitted by browsers.) | TM puts tokens in the cookie that are unique per session and per request. |
| 5.2.6 | Information leakage and improper error handling | Information leakage and improper error handling (Do not leak information via error messages or other means.) | ensure all messages are read from a table (tmError.txt) and only provide user direction, not system state. |
| 5.2.7 | Broken authentication and session management | Broken authentication and session management (Properly authenticate users and protect account credentials and session tokens.) | use the build in tCookie function to read and write cookies. Cookies are 3DES encrypted and contain time information to know if the patron is going back or forward. Requests that cannot be decrypted and have stale information are discared before they get to the oWebComXXX |
| 5.2.8 | Insecure cryptographic storage | Insecure cryptographic storage (Prevent cryptographic flaws). | make sure all internal keys and pw are never clear text in variables. Always store encrypted and use decryption to get the true value. |
| 5.2.9 | Insecure communications | Insecure communications (Properly encrypt all authenticated and sensitive communications.) | Implemented using TLS for the entire web site. Specific tokens like cookies and CC data are AES256 encrypted within the TLS layer. Always test for this. |
| 5.2.10 | Failure to restrict URL access. | Failure to restrict URL access (Consistently enforce access control in presentation layer and business logic for all URLs.) | All access to the web components are throught an API call. These are routed through a single apache module that adds some tokens of its own and redirects the URL to a specific machine, changes the IP and crosses a firewall from the DMZ using NAT. There is never direct access to any oWebComXXX |
After you have checked in all your changes you should perform a clean build test. This is accomplished by renaming your local copy of the source, and getting the latest source from the branch you were working on. Then performing a build to ensure that the code still works.
The size and scope of the peer review process is dictated by the scope of code changes. Altering a line of code to fix an issue does not necessarily merit a code review. Introducing new functionality or altering the user experience of the product on the other hand should require a code review.
At a minimum your code needs to be reviewed by one of the senior developers. If your code changes impact more than a single area then an architect needs to review it. If your code impacts the database schema then an architect needs to review it. Any time there is a change to code that handles track data or credit card numbers; it needs to be reviewed by a senior developer.
Any time your code changes involve the use credit card data, encryption or decryption and/or any of the protected classes, these changes should be discussed with an architect before, and reviewed by an architect afterwards to ensure the highest level of adherence to coding best practices. The TM coding practices specifically addresses how sensitive data is to be dealt with in the Studio Code. OWASP practices specifically address tests for web objects.
A peer review can take many forms. For particularly important code, a 'hand inspection' of the code may be required. Normal code walkthroughs involve explaining the purpose of code segments and object classes. A hand inspection is when a second party actually steps through the new code to verify assumptions, parameters, values, comments and alter boundary conditions to simulate odd or unpredictable cases and attempt to identify unforseen defects.
The approval of a code review results in a the development build and forwarding to QA for testing. This also generates entries in the upcoming release notes which are build as each development release is built. An entry in the release notes constitutes approval of the development build.
As part of passing an issue to SQA for testing you should consider what you have done, and what impacts that will have on the environment and user interface of the application. As developers we often will do things like stopping and restarting a service, or registering a COM control, or installing 3rd party drivers, that the SQA testers will not just know to do. Document these steps that they will need to perform to ensure that development and testing cycles are not wasted. Make sure to attach the FogBugz case numbers for the issue being sent to SQA for testing.
In the defect tracking tool you can forward an issue and mark it ready to test. This will allow SQA to pick it up and begin testing.
While not a requirement it is recommended with any significant change that you follow up in person with the SQA testers that are testing your code. Answer any questions they have, address any concerns. We are all part of the same team and it is all of our jobs to release the best software we can.
The build for QA testing (i.e. any candidate for production release) will include building from the VCS. The option Build without Comments will be used to remove comments from any documentation in the applications.
Because of the way Omnis Studio is tokenized and structured and how the VCS operates, this will also have a supplementary effect of removing any commented test PAN’s and or other text based security information that may be present in the code.
The Studio VCS is used to help control and separate the Development, Test and Release functions.
![]() |
There are two ways to release Theatre Manager to customers.
|
The release process for Auto Deployment and Downloadable Installers is similar. There will always be:
When code has been designated for potential release:
In many cases, one or two beta sites are selected for final testing prior to full notification of a new version - depending on the nature of the changes.
Selection is based on a number of factors such as desire/need for the specific change. Most often this will be one of what is termed a QA tested Development Release.
It could also be a new site where there is a Senior Arts Management representative onsite to watch for any anomalies that were not discovered in the comprehensive testing process. The key in this situation is approximately 8 days of comprehensive observation of the entire application by a knowledgeable person.
If there is a significant number of changes for a prospective public release that are of a nature that warrants a beta program with mulitple venues; a call will be made for willing beta participants who have test servers and can test. This occurs after QA testing have determined that the version is a candidate for public release.
When an installer is deemed ready for public release, a number of steps need to occur:
in Startup_task method, set the following three items:
Auto Deployment builds require the Theatre Manager library be built without comments and to be locked except
For beta testing, test the library with the Theatre Manager runtime on your machine Once that is done, build a beta auto deployment package and release to developers.
The menu is Developer->Make AutoDeployment LBR's for 2ndGen
The following shows the constituent parts of the manifest file (json format) that needed to be edited for a release to. occur. If the manifest is not a completely valid JSON file, no release will occur.
A release should be done in four stages. It should be gradually released to:
The components of the JSON file are:
The backout steps are:
In the case of catastrophic condition, rebuild the previous version and release it as the 'next' point release. In effect, we make the prior release into the future release so that customers can upgrade and roll forward to the future release (which is really a prior release)
There is ample documentation on
Various Git tools provide ample ways of diff-ing changes in versions, seeing who made the change (blame) etc.

The Main is the head branch. It is where all new development is done. It is also the first place you should fix when patching an issue.
HotFix branches are created at the time of release. The latest branch is forked and new development continues in latest while issues that are reported are fixed in HotFix.


Check the recursive checkbox, and when the Build tree check box appears check it as well. Click OK to begin the get process.
It is possible to build prior revisions of the code based on labels. Labels are applied to each major release and the Build Manager will perform that task when a release is done.
Classes can be deleted or marked deleted in the VCS when they are no longer required or referenced. For that reason, it is recommended on a periodic basis (eg when a major release is completed, or you have finished a project), to check in all code and then rebuild the library.


On the checkout window, indicate:

The name of the class is to be given a name according to the naming conventions in the coding practices.

If you decide to discard the class before checking it in, simply delete it. If you check it in and discover that you no longer want it or need it, the it must also be deleted from the VCS.
When checking in, make sure that you:

| Area | Person |
| Architecture and product design | Dave McKeone |
| Ensuring changes meet PA-DSS and secure coding practices followed. | Doug Easterbrook |
| keeping up to date with changes in PA-DSS guidelines | Doug Easterbrook/Dave McKeone |
| Ensuring vendor personnel with PA-DSS responsibilities receive training | Doug Easterbrook/Dave McKeone |
| Following PCI guidelines for development processes | all developers |
| Following PCI installation guide and training customers in PCI requirements | Training and support staff. |
This document explains Arts Management Systems Software Development Life Cycle. This document is not intended to be all inclusive but rather a high level outline of our processes. Detailed processes are described in associated ‘living’ documents. This document is for internal use only and is not to be distributed.
Wikipedia presents 3 basic methodologies for software development as illustrated in this picture. There is another interesting description of other methodologies and variations on www.noop.nl if it is of interest.
The nature of Omnis Studio as a development tool lends best to the prototyping methodology which is more recently known as Agile Development
From Wikipidia, agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.
| Individuals and interactions | over processes and tools |
| Working software | over comprehensive documentation |
| Customer collaboration | over contract negotiation |
| Responding to change | over following a plan |
Source: Wikipidia
A common criticism of the waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.
Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early and continually improving it and/or adding further functionality throughout the life of the project. If a project being delivered under Waterfall is cancelled at any point up to the end, there is often nothing to show for it beyond a huge resources bill. With Agile, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.
Using agile development, Arts Management Systems strives to be in the position of being able to release a new version at any time to respond to clients in an 'agile' manner. By definition, this means that small, incremental units of work are done at one time, checked in, QA'd and set aside for release. It involves coordination amongst the teams to defines what is working, and what is not, isolate the scope and do a build only on what we determine to be working, even if it does not meet the full intended scope. After all, some working software for the customer is better than none.
That being said, releases are generally of 3 types:
There are a number of development methodologies that can be used in agile development such as Extreme Programming or Scrum. The particular process that we use the most is the Agile Unified Process although, by definition, agile programming can draw from various methodologies as the need dictates.
The links will take you to the implementation of the process in our product development process
The Agile UP is based on the following philosophies:
The Agile Unified Process distinguishes between two types of iterations. A Development Release Iteration results in a deployment to the Quality Assurance and/or Demo area. A Production Release Iteration results in a deployment to the Production area.
A development release iteration is tested manually and/or with automated software tests checked into the VCS and built for QA who verify it works as designed. Any development release iteration can be sent to a customer after QA testing but is not advertised and may not have release notes.
A succession of the development releases, that becomes the Production Release will have release notes, implementation notes, documented interactions, etc. as per the examples in Version Release Notes

To generate a Certificate Signing Request (CSR), you will need to create a key pair for your server. These two items are a digital certificate key pair and cannot be separated. If you lose your public/private key file or your password and generate a new one, your TLS Certificate will no longer match. You will have to request a new TLS Certificate and may be charged by the TLS Issuing company to do this.
The server.key file (first part of the "key pair" files) has now have been created in the /Library/TLS folder. This RSA private key file is a digital file that will be used to decrypt messages sent to Apache. It has a public component which is distributed (via the Certificate file) which allows people to encrypt those messages to Apache.
A public/private key pair has now been created. The private key (server.key) is stored locally on the server machine and is used for decryption. The public portion, in the form of a Certificate Signing Request (server.csr), will be for certificate enrollment.
The server.csr file (second part of the "key pair" files) has now have been created in the /Library/TLS folder.
The /Library/TLS folder now contains the necessary starting files for the TLS Certificate. The next step is to submit the CSR file for certificate creation.
To submit the request for TLS Certificate Creation, you will need the Certificate Signing Request (CSR) file called server.crt created from the previous step.












![]() |
Geotrust TLS certificates are no longer used - refer to Name Cheap TLS Certificates instead. |
Select Validity Period (1 year, 2 years, 3 years, etc) based on what the client purchased in their signed Letter of Confirmation (LoC). Wait for the window to reload before proceeding.
Select Initial Order or Renewal. If renewal is selected, they MUST BE renewing a previous TLS Certificate that was issued from GeoTrust.
In most cases, select No, I can't take advantage of this offer. Select Yes in the case where we would be renewing an existing tickets.myvenue.org TLS Certificate that was originally issued from another Certificate provider other then GeoTrust.
Leave this field empty.
Copy the entire contents of server.csr file (including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST tag lines) into Certificate Signing Request field.
Adding to this field will increase the cost of the TLS Certificate.
Review information on the page for accuracy.
Enter in Site Administrator contact information from the clients information as per instructions
Enter in Technical Contact information as:
First Name: David
Last Name: McKeonoe
Title: Director of Development
email: as per current email
Phone Number: 403-536-1214
Select Approval Email address from the clients information as per instructions
Review information on the page for accuracy.
Inform the AMS Installer or the client contact that the TLS Certificate has been submitted and is now awaiting for their approval.
The approval of the TLS Certificate is performed by the client. The client is required to reply to the email sent to them by Comodo in order to continue with the process.
The process for approving the TLS Certificate for creation is as follows:![]() |
The final email may arrive anywhere from 10 minutes to 12 hours after email #2 was accepted by the client (Approval Email Address) depending upon the next processing cycle by Comodo. |
If the 2nd email is NOT received by the client at the Approval Email Address, it may be caused by that email account is not working correctly. Test to see if the email account they have provided to use for the Approval Email Address is able to receive 'normal' emails.
After AMS has received the TLS certificate email from Comodo that contains the Web Server Certificate and the Intermediate-CA Certificate, AMS will make the TLS certificate files to put it into the Theatre Manager Server on the Web Server for the client. The following steps outline how to create the remaining files that will complete the TLS certificate installation.
Location: Desktop
Filename: server.crt
Line Breaks: Unix (LF)
The Theatre Manager Server checks for updated approximately every 30 minutes. During this process it also looks for new TLS Certificate files. Placing the TLS Certificate files in the correct location on the server will ensure the next time the Theatre Manager Server checks for updates it pulls down the new TLS Certificate. This works successfully as long as the client is not blocking the connection or has automatic updates turned off.
Once the TLS certificate files have been places and Nginx restarted, the certificate can be tested.
Use Qualys TLS Certificate Test to test the TLS Certificate.
This would the https://tickets.yourvenue.com/TheatreManager/1/login&event=0.
This should be done after the site has finished loading. A box will appear indicating the status of the TLS Certificate.





A broken red arrow means the server chain is not correct. This is the chain added to the .crt file after the certificate. It is either not being read or is not up to date.
The TLS certificate associated with the ticketing site may not always be the only TLS certiificate in the network. The TLS certificate in Nginx may have installed correctly without error or warnings. The web pages appear correctly within the network. However, when attempting to access the site externally, the web pages do not display. The web site looks like it may be pointing to IIS or another application. The network setup will appear correct and everything on the Web Server machine is running. Reviewing a test of the TLS Certificate does not display the Comodo Logo.
In this situation an TLS may be built into the router. The IT person will need to locate the TLS Certificate and disable it.
When visiting the ticketing site the address starts with http rather then https. The style sheets are missing and the buttons do not appear.
This is caused by a missing S from https in the Web Server URL field under the Director tab of Setup >> Company Preferences.
When accessing the ticketing site using http rather then https the Web Pages are not displayed. The ticketing site is replaced by another website, application or login. The link will not redirect to https automatically but rather needs to be altered to include the S.
Port 443 governs https by default. Port 80 is reserved for http. Some organizations use port 80 for other applications such as web mail. In cases like this all direct links to the ticketing site will need to start with https.
If using this construct, at the end of the loop, you must do a 'set current list' as a guard action and the setting of the list must be in a reversible block.


Also indicate if this method should never be over-ridden except in rare cases, could be overridden, or should be overridden.

This is one of the most important setup steps when creating new data base fields.
Schemas are to be documented in three places.
First, all database schemas will have a Studio ‘File’ class like the example below. The description in this area is for programmer assistance. It will show as tooltips to describe the field when looking it up for coding purposes.

Most file classes have a corresponding schema class. The schema class is what actually is used to describe the database fields and interact with the database. The field names, types, subtypes, and descriptions should be copied from the file class. This is also for programmer tool-tip quick documentation

Once the file and schema classes have been defined, customer friendly field names are to be placed into the data dictionary. This is accessed off the Developer Menu->Data Dictionary.
Customer friendly descriptions are to be defined, along with a number of other data attributes as follows:


Within the 'oCodetables' class, there are a number of getters that will load up any one of the tables into your object.
| Class Type | Prefix | Notes |
| Code | c |
|
| File | f or F |
|
| Menu | m |
|
| Object | o |
|
| Query* | q |
|
| Remote Task | rt | |
| Report | r | |
| Schema | s |
|
| Table* | t |
|
| Task | none |
|
| Toolbar | T_ | |
| Window | w |
|
*Query class names should match the corresponding table class. E.g. tClient and qClient.
However, if is a parameter, local, or instance var that is meant to track a cope of a database SEQ key, then call it what it is. eg pM_SEQ means that the parameter we expect is an M_SEQ key. This helps with variable assignment.
All database names will be named using underscores and in UPPER_CASE to make an obvious differentiation between the database and other task/class/instance/local variables.
Scope / Type |
Prefix | Convention |
Task |
t |
|
Class |
c |
|
Instance |
i |
|
Local |
none | Developer preference, prefer myVariable rather than MyVariable. |
Parameter |
p |
|
Constant |
k |
|
The architects will monitor the VCS activity on these classes by running checkin/checkout reports for any violations of this policy.
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.
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 object pertinent to web listeners are:
![]() |
The web sales listener can only respond to traffic sent to it via the nginx module. |
If any site reports a threat that may affect security, a project will be created in Fogbugz to deal with testing where it impacts Theatre Manager.
May need to clear some values left behind if you've copied them over from the primary outlet:
update fTaxRates set tr_tax1_ca_seq=0, tr_tax2_ca_seq=0, tr_tax3_ca_seq=0,
tr_tax1_def_ca_seq=0, tr_tax2_def_ca_seq=0, tr_tax3_def_ca_seq=0
where tr_d_dept_seq=2
update fFeeTypes set fee_amount=0, fee_active=TRUE, fee_auto_calculate=FALSE,
fee_tr_Seq=0, fee_ca_Seq=0, fee_pb_seq_list=''
where fee_d_dept_seq=2
An employee needs to be first added to the database as a patron, then it can be activated as an employee. Using the Patron Import process, it will do both steps at the same time. Refer to either information provided by the client as part of the data import for the listing of employees, or refer to the company's website for a listing of the current Staff Members.
Remember, within the data to be imported, it should contain a listing of employees who are currently working at the venue and has worked in the past. Do we import past employees? Yes we should. This way we can tag historical ticket sales, membership sales, donation sales to those employees if that reference is within the data. Just as historical data is important, having a listing of historical employees shows the completeness of data importing that Arts Management provides. It goes towards the 'extra step' that we do. Having employees imported during data conversion also allows the onsite trainer to 'move quicker' during the initial training as everyone has their own login ID, and less time is spent setting up employees on the first day when the goal is to introduce them to the application rather then 'how to setup employees'. This also avoids the initial discussions of user access and who gets what privileges - at least until later.
Employee Initials are important. If they are not provided in the import data, they will be created based on the employee first, middle and last name. If possible, define them within the import spreadsheet.
After importing the employees, it is recommended to review the initials and make them unique for each employee. This is not mandatory, however it does allow for more easy identification between the employees throughout Theatre Manager.
All employees import will be created with a user access level set as a 'Normal User
Initial password will be set as Tickets@123
Import Column Template: MKT_FIELD_1,gPatronType,E_INITIALS,C_FIRST_NAME,C_INITIAL,C_LAST_NAME,C_TITLE,gEmailWork,gPhoneWork,C_COMPANY,AD_ADDRESS1,AD_CITY,AD_PROVINCE,AD_POSTAL_CODE,AD_COUNTRY
Defaults: gPatronType = Staff Member
Gather a listing of the various venue maps, physical locations, number of seats within each venue, and for reserved seating, a seating chart - clearing showing the different sections, row and seat names.
The venue map is something that will need to be created in Theatre Manager manually. As part of the import, refer to the client's website for a venue icon for TicketTrove along with a venue description that can be used.
The Best Seat Search - provide a default to allow the most choices for the patron. When the trainer is onsite, they can have the client review the seating options and make the necessary changes required.
Import Column Template: Logical Seat,Door,Section Name,Row Number,Seat Number,Price Codes,Seat Code,Seat Priority,Best Avail Area,Best Avail Index,Seat Note Use?,Seat Note,Seat View
For the Best Seat #, just number then sequential from top to bottom. When the trainer is onsite, they can have the client review the seating chart to determine exactly how they want the seats to be numbered for sale and make the necessary changes required.
G/L Account Columns: gType,CA_FULL_ACCT,CA_EXTERNAL_ACCT,CA_DESCRIPTION,CA_POSTING,CA_LEVEL
CA_FULL_ACCT = account number WITHOUT any dashes in it. If you add formatting to this field, the record will not be imported. Easiest to just import the CA_EXTERNAL_ACCT as a formatted field, and the import routine will set the CA_FULL_ACCT for you.Account Types (gType)
Account Setting (CA_POSTING)
Reporting Level (CA_LEVEL)
Unless specified, the External Account Number will default to the Account Number
Gather a listing of the events and performances.
Event and Performance Columns: P_PLAY_YEAR,P_SHOW_CODE,PB_SHOW_CODE,P_PLAY_TITLE,PB_SERIES_CODE,PB_PERF_NOTES,PB_PERFORM_DATE,PB_PERFORM_TIME,gSalesMethod,gTax1Account,gAccount,gTaxRate,P_VE_SEQ,P_TM_SEQ,P_ACTIVE
To help create the Event Number for the Event Code, refer to the previous event code in the list: