ams

The following pages are private and confidential to Arts Management Systems and should only be available to employees who are logged in and able to change any of the support pages.

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.

Human Resource's Policies

AMS & Customer Data Policy

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.

 

AMS & Customer Data Policy

It is Arts Management Systems policy that Employees:

  • At no time will customer data be transferred into our custody without the explicit knowledge and agreement of the customer.
  • Do not transmit any database containing encrypted sensitive credit card data outside the customers network and never to AMS premises.
  • Try to solve all problems without any data ever having to leave the client’s servers, even if it means loading their production database into a separate test database on their servers for purposes of diagnostics.
  • Collect only data required to solve the problem and reproduce it such as order number, patron number, ticket number, cart #, dates, etc.
  • Data placed on our servers for Tier II support will be stored in a restricted location until such time as the problem resolution process begins.
  • Do not keep any data given to you for diagnostic purposes for longer than is absolutely necessary.
    • On a Mac, this is done by putting the file in the trash and using ‘File->Secure Erase’
    • On a PC, a tool like Eraser is to be use to securely delete.

 

General

  • Arts Management Systems hereinafter called “AMS”.

 

Revision History

  • June 2010
  • Aug 2016
  • Sep 2019

Gathering Sample Data

Very few support cases require transfer of customer data into AMS's custody to resolve a problem. Further, and with limited exception, there is never a reason for the development team to actually need specific card numbers in order to do any testing because we have our own test numbers and test merchant accounts.

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)
The general steps are:

Testing @ Customer Site

  • Make a backup of the customer's database using the BackupTM_SUPPORT backup script. This automatically implements the postgresql database dump flags below.
  • load the backup database that exhibits the error onto the customers server as a 'test' database so that production is not affected.
  • Perform one last test on the test database at the customer site to ensure the problem still exists

Testing in Tier II Development Environment

  • Make a SUPPORT backup using BackupTM_SUPPORT which
    • Dumps the backup database under a separate name (that end in _SUPPORT) on the backup folder
    • This uses the

      -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

  • Use the link https://backups.artsman.com and enter the appropriate credentials as per the web page image to the right. This will migrate the _SUPPORT database to a secure location on private server via https using latest high transport layer encryption available (currently TLS 1.3)
  • Inform Tier II when the database has uploaded and they will resolve the case and remove the data.

Exceptions for Credit Card Data

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.

Acceptable Use Policy

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.

 

Acceptable Use Policy

It is Arts Management Systems policy that Employees:

  • Adhere to safe computing practices when using the Intranet, Internet, Email, IM, FTP, web and other related communication tools;
  • Use their company computer for work related to Arts Management Systems in performance of their duties;
  • Obtain specific approval for non-work related uses or for an exception to any item mentioned in this policy; and
  • Prevent others from contravening the Acceptable Use Policy.

 

General

  • Arts Management Systems hereinafter called “AMS”.
  • AMS spends considerable resources to implement and maintain a corporate network of computers, routers, telephony, VPNs, data services, corporate information, and application portfolio’s (hereinafter called “assets”) for the benefit of the company and its employees. It is the intent of the company to safeguard those assets and ensure that the company adheres to copyright and fair trade practice.
  • AMS employees are encouraged to take full advantage of this network (Intranet), including the Internet access to the World Wide Web, subscription-based information resources, newsgroups, list-servs, bulletin boards, threaded discussions, Telnet and FTP resources to maintain a knowledge base suitable for the successful performance of their duties.

 

Revision History

  • March 2006

Personal Responsibility

  • It is the responsibility of the employee to take all reasonable steps to ensure compliance with the conditions set out in this document, and to ensure that only acceptable use of AMS computers and related communication occurs.
  • The employee is responsible at all times for the proper use of any computer(s) and other related equipment provided to the employee by AMS.
  • The employee is responsible for safeguarding the assets of the company by following the acceptable use policies.
  • The employee is responsible for safeguarding any assets of our customers while connected to their networks.

Compliance

  • Compliance is required from all AMS employees and/or affiliated individuals that connect to any AMS network behind the corporate firewall and to the Internet.
  • AMS employees are responsible for any guest access to the network and their respective compliance.

Unacceptable Use

It is often easier to understand acceptable use by identifying inappropriate use. The following list, while not exhaustive, exemplifies some unacceptable uses:

Creation or Transmission

  • The creation or transmission of any material in violation of any local, provincial, state, or federal law. We must be cognizant that we deal with customers around the world and that laws may vary from one jurisdiction to another.
  • The creation or transmission of material, which is designed or likely to cause annoyance, inconvenience or needless anxiety.
  • The creation or transmission of defamatory material.
  • The creation or transmission of material protected by trade secrets or privacy laws.
  • The transmission of purchased software that would contravene any license agreements imposed on AMS by our Vendors.
  • The creation or transmission of any offensive, obscene or indecent images, data or other material, or any data capable of being resolved into obscene or indecent images or material.
    •  

      Communication

      • The use of profanity, obscenity or other language that may be offensive to another user.
      • Repeated, unsolicited and/or unwanted communication of an intrusive nature is strictly prohibited. Continuing to send e-mail messages or other communications to an individual or organization after being asked to stop is not acceptable.
      • Representation on a Blog, list-serv, or similar IM comment posting venue, to express strong, misleading, or libelous views, which may or may not represent the views of AMS, its employees and/or affiliated individuals.
        •  

          Network

          • Any form of vandalism, including but not limited to, damaging computers, computer systems, or networks, and/or disrupting the operation of the network.
          • Creating and/or placing a computer virus on the network, or working in such a manner that may make it easy for a virus to infect the corporate network.
          • Use of the network for financial gain, commercial activity, or illegal activity. (e.g. hacking, spam)
          • Use of the network for political activity.
          • Use of the network to access pornographic or obscene material.
          • Deliberate unauthorized access to facilities, services, or customer networks accessible via the AMS network.
          • Opening of ‘holes’ in the network to provide unauthorized access to other individuals without consent.
          • Use of another person’s account without consent (System Administrators have implicit permission to manage the all aspects of the network which may include account access).
            •  

              Downloading

              • Copying and/or downloading commercial software or other material in violation of any local, provincial, state, or federal copyright laws. (e.g. downloading music from non law-abiding websites)
                •  

                  Miscellaneous

                  • Wasting employee effort or networked resources, including time and the effort of employees involved in the support and maintenance of those systems.
                  • Corrupting or destroying another employee or user’s data.
                  • Violating the privacy of other employees or users.
                  • Disrupting the work of other employees or users.
                  • Using the AMS network in a way that denies network service to other users.
                  • Continuous use of networking software or hardware after AMS has requested that it be removed because it is deemed inappropriate use and/or causes disruption to the correct functioning of the AMS network and its associated computers.
                  • Disabling of any networking corporate software or hardware used to safeguard, monitor and maintain correct functioning of the AMS network and it’s associated computers.

    Access to Outside Networks

    • AMS follows the acceptable use policies of our Internet Service Provider’s (ISP) used by each employee to access the Internet. AMS also regards any breach of their Acceptable Use Policy as unacceptable use.
    • Where the AMS network is being used to access another network (e.g. a client’s network), any breach of the client’s Acceptable Use Policy is regarded as unacceptable use of AMS.

    Withdrawal of Service

    • Where necessary, some service(s) may be withdrawn from the employee where a violation of the Acceptable Use Policy has occurred and/or persists despite appropriate notification.
    • Restoration of service(s) will only be made when AMS is satisfied that a future breach of the Acceptable Use Policy will not occur and/or steps have been taken to correct the item causing unacceptable use.

    Legal and Statutory

    • AMS and its employees perform all best efforts to assist any Authorities where required by law in the investigation of any breach of our network and unauthorized access to our corporate assets by outside individuals and/or organizations.
    • When an internal violation of the Acceptable Use Policy is illegal or unlawful, or results in loss or damage to AMS, its employees and/or affiliated individuals, AMS assets or the assets of third parties accessible via the AMS network, the matter may be referred for legal action and/or termination of employment.

    General Questions

    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 Policy

    Bereavement leave enables employees to take time off work to deal with the death of a family member.

     

    Bereavement Leave Policy

    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.

     

    Definition

    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.

     

    General

    • Arts Management Systems hereinafter called “AMS”.

     

    Revision History

    • October 2013

    Coverage

    • Generally, bereavement leave will not require a medical death certificate or other proof of death, but may be requested at AMS’s discretion.
    • Although the majority of all collective agreements and jurisdictions provide bereavement leave as completely unpaid leave, AMS will provide:
      • Bereavement leave up to 2 days will be paid leave.
      • Bereavement leave after 2 days will be unpaid leave.
    • Given adequate notice, AMS may allow an employee additional time off to accommodate specific circumstances such as:
      • Extended travel distance considerations according to the relative proximity of the deceased to the employee
      • Preparation for funeral services
      • Co-ordination activities for dependent persons
      • Respect of cultural and religious considerations where expectations around mourning may require additional time
      Such additional time off will subsequently be made up at a time mutually agreeable to AMS and the employee.
    • Extended bereavement leave beyond the standard 3 days is available and may be requested by the employee to be taken as vacation or an unpaid extended leave of absence.
    • Paid bereavement leave after 2 days of absenteeism, is at the discretion of AMS.

    General Questions

    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):

    • Making poor decisions / impaired decision-making
    • Inability to concentrate
    • Lack of motivation, decreased productivity
    • Supervised or supervising ineffectively
    • Confusion, memory lapses
    • Anxiety, crying or other emotional responses
    • Social withdrawal
    • High absenteeism or injury rate
    • Compromising workplace safety
    AMS also realizes that employees may still be in shock and unable to acknowledge the reality of their situation. Grieving is a process that may take weeks, months or even years. If management determines that additional bereavement time is required for the employee, it is at AMS's discretion if any additional time that extends over the first 2 days will be taken as paid or unpaid leave.

     

    Who are considered family members?

    Family is defined very broadly for Employment Standards’ purposes.

    • Spouse or common-law partner
    • Parents or guardians of the employee and his or her spouse or common-law partner
    • In-laws of the employee and his or her spouse or common-law partner
    • Siblings
    • Children
    • Grandparents and grandchildren of the employee and his or her spouse or common-law partner
    • Children of the employee's spouse or common-law partner
    • And, anyone who lives with the employee as a member of his or her family
    "Common-law partner" means a person who has been cohabiting with an individual in a conjugal relationship for at least one year, or who had been so cohabiting with the individual for at least one year immediately before the individual's death. The definition of the "family member" also includes those who are not related, but whom the employee considers to be like a close relative. In these situations, it is up to AMS's discretion in the final determination if those who are not related shall be treated as a close relative.

     

    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.

    Network Security Policy

    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.

     

    Network Security Policy

    It is Arts Management Systems policy that Employees:

    • Adhere to safe computing practices when using the Intranet, Internet, Email, IM, FTP, web and other related communication tools;
    • Use the company network for work related to Arts Management Systems in performance of their duties;
    • Obtain specific approval for non-work related uses or for an exception to any item mentioned in this policy; and
    • Prevent others from contravening the Network Security Policy.
    • Ensure the Firewall is enabled on their computer
    • Use Company authorized hardware for their network connections
    • Use a VPN at all times to access company servers

     

    General

    • Arts Management Systems hereinafter called “AMS”.
    • AMS spends considerable resources to implement and maintain a corporate network of computers, routers, telephony, VPNs, data services, corporate information, and application portfolio’s (hereinafter called “assets”) for the benefit of the company and its employees. It is the intent of the company to safeguard those assets and ensure that the company adheres to copyright and fair trade practice.
    • AMS employees are encouraged to take full advantage of this network (Intranet), including the Internet access to the World Wide Web, subscription-based information resources, newsgroups, list-servs, bulletin boards, threaded discussions, Telnet and FTP resources to maintain a knowledge base suitable for the successful performance of their duties.

     

    Revision History

    • April 2006
    • Aug 2020

    Security Implementing

    There are a number of phishing attacks and reports of stolen laptops, etc. Doug (in early 2006) lost his iPod and thank goodness it didn't have any data on it. So in the interest of corporate security, we're looking at implementing:
    • a firmware patch so that you need a password to get a machine started and booted
    • implementation of passwords on start up (we are all there anyway)
    • implementation of passwords on wake from sleep mode
    • implementation of some 'phone home' software where if your machine wakes up in an unknown IP address, it sends an email to a specified email address to let us know where it is should somebody else "borrow" your laptop without you knowing.

    Data Security

    Refer to the Data Policy

    Tools

    • There are a number of tools that AMS has for just doing stuff and manipulating data such as BBEdit, Microsoft Excel, and what have you, or tools for connecting to clients such as Timbuktu, Remote Desktop, Team Viewer and VNC. AMS would like to make sure everybody has the full complement of tools available... just in case they are needed.

    General Maintenance

    • AMS also wants to do diagnostics on each computer to make sure its ok. This includes Diskwarrior to fix the desktop, Apples' repair permissions to correct some permission setting that seems to happen to log files and plists (and affect some software updates coming in) and, making sure that latest software updates are run.
    • Clearing out system logs that have grown. I just removed some stuff and got back half gigabyte of system logs. These are in /var/logs, /library/logs ~/library/logs
    • Updating bluetooth firmware
    • Updating any other software

    Routers & Wireless Connections

    To be documented.

    General Questions

    There are no general questions at this time.

    Overtime & Days in Lieu Policy

    Overtime and Days in Lieu compensates employees when they are required to work in excess of the limits defined in the Employment Standards Code.

     

    Overtime & Days in Lieu Policy

    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.

     

    Definition

    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.

     

    General

    • Arts Management Systems hereinafter called “AMS”.
    • AMS and its employee’s are entering into an overtime agreement.
    • The Code requires an overtime agreement to be in writing. Employers must give employees who are covered by an overtime agreement a copy of the agreement.
    • AMS’s employees are all viewed as professionals. With professionals, AMS’s employee’s need to be prepared for each client’s onsite visit. Time spent by employees preparing for client training sessions is not view or recognized as overtime within this agreement.
    • AMS views this rules as guidelines and wants to be fair to the employees for the hours that they work.

     

    Revision History

    • January 2010

    What is Overtime?

    • All employees, including those who are paid a weekly, monthly, or annual salary, are inclined to have paid overtime pay for overtime hours they work unless they have entered into an overtime agreement.
    • Overtime hours are to be calculated both on a daily and on a weekly basis. The higher of the two numbers is overtime hours worked in the week.
    • Except as noted below, overtime is all hours worked in excess of:
      • eight hours a day, or
      • 44 hours a week.

    Overtime Agreement

    Hourly Part-Time or Casual Employees

    • Hourly Part-Time or Casual employees will be paid out for all overtime hours worked at a rate of 1.5 times the employee's regular rate of pay.
    • Hourly Part-Time or Casual employees are not applicable for banking overtime as Banked Time in Lieu.

    Commission Paid Employees

    • Employees who are paid exclusively by incentive pay such as commission, piecework or a similar method, are not applicable for banking overtime as Banked Time in Lieu.

    Salary Paid Employees

    This agreement allows overtime hours to be banked and later taken off with pay, hour for hour, during regular work hours. This agreement relates to all overtime pay.
    • Overtime hours are calculated the same way under an overtime agreement, as it would be if overtime pay is to be paid at time-and-a-half.
    • Only overtime, which has been authorized and pre-approved by the department manager or designate, will be recognized as Banked Time in Lieu.
    • Banked Time in Lieu must be taken within three months of the end of the pay period in which the overtime was earned.
    • Banked Time in Lieu that is not taken at the end of the 3 Banked month time period, the overtime hours will be lost and will not be paid out at time-and-a-half.
    • Daily and weekly schedules may vary from time to time, and diversification in work schedules may be required to meet changing operational needs. Employees may be requested to work overtime during periods of unexpected and/or unavoidable workloads. Where possible, reasonable notice will be given under these circumstances.
    • Time taken off in lieu of overtime pay is equal to the actual number of overtime hours worked, at the employee's regular rate of pay.
    • In compliance with Employment Standards, employees in management positions are not eligible for overtime compensation.
    • On termination of employment, any outstanding overtime, which has previously been approved, will be paid out and included in the employee's final pay.

    Travel Time

    • In most cases when airplane travel is required, travel time starts approximately 1.0 hour prior to domestic flights and 2.0 hours for international flights. Travel time will stop approximately 1.0 hour after arriving at the destination.
    • There will be travel time that is less then a full day and there will be time that is more then a full day. At most, a single travel day is earned as Banked Time in Lieu on either side of an onsite trip. As single travel day is used as a guideline for over a time period the over/under should average out.
    • Travel time to and from the airport when leaving your place of residence, is not eligible for overtime compensation.
    • Travel time on weekends is eligible for overtime compensation.
    • Travel time on a regular weekday where you were scheduled to work, is deemed part of your regular work week.

    Weekend Stayovers

    • Overtime will only be recognized if time on the weekend was used for training purposes. If training was not scheduled to occur over the weekend day(s), then no overtime will be recognized for the Weekend day(s).
    • Weekend days where there is no scheduled training activities, are treated as regular weekend days off.

    Work Requested by Client

    • While onsite, a client may request that AMS perform work on their behalf during the installation, training, and/or upgrade process. If AMS is requested to perform work, then this work will be invoiced back to the client for it would not (in most cases), be part of the pre-arranged agreement for onsite activities between AMS and client.
    • All overtime that is accepted and confirmed completed by the client, will be recognized as overtime. An overtime sheet will be required to be completed, signed by the client, and provided to the department manager or designate upon completion of the work. When the completed and signed overtime sheet has been received by the department manager or designate, then the overtime will be added to the Banked Time in Lieu.
    • Failure to provide a completed overtime sheet to the department manager or designate, will forfeit the overtime hours.

    Requests to Use Banked Days in Lieu

    • Requests to take time off in lieu will be considered by the department manager or designate, and approved based on current operational needs.
    • In most conditions, the day will need to be a mutually agreeable date between the department managers or designate. If a mutually agreeable date cannot be determined, a date will be chosen and assigned at AMS’s discretion.

    How is Overtime Paid?

    Hourly Part-Time or Casual Employees

    • Overtime will be paid at the rate of 1.5 times the employee's regular wage rate.

    Commission Paid Employees

    • Employees, who are paid exclusively by incentive pay such as commission, piecework or a similar method, have no established rate of pay. Therefore, for the purpose of calculating overtime entitlements, the wage rate is deemed to be the minimum wage.
    • If the incentive pay is less than what would have been earned applying the minimum wage, the employer must top up the incentive pay earnings to match minimum wage.
    • Overtime will be paid at the rate of 1.5 times the minimum wage rate.

    Salary Paid Employees

    • If an employee is paid by a combination of salary and incentive pay, and the salary is greater than minimum wage, the salary establishes the hourly rate for the purpose of calculating overtime entitlements.

    General Questions

    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.

    Sexual Harassment Policy

    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.

    Definition of harassment

    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.

    Definition of Sexual Harassment

    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.

    1. How to proceed if you are being harassed

      • If it is possible, tell the harasser that their behaviour is unwelcome and ask them to stop.
      • Keep a record of incidents (date, times, locations, possible witnesses, what happened, your response). You do not have to have a record of events in order to make a complaint, but a record can strengthen your case and help you remember details over time.
      • Make a complaint. If, after asking the harasser to stop their behaviour, the harassment continues, report the problem to one of the following individuals:

      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.

    2. 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.

    3. 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.

    Alberta Human Rights Sexual Harassment Guidelines

    Sickness & Absenteeism Policy

    Sick leave enables employees to take time off work when ill.

     

    Sickness & Absenteeism Policy

    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.

     

    Definition

    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.

     

    General

    • Arts Management Systems hereinafter called “AMS”.

     

    Revision History

    • January 2010

    Coverage

    • Generally, sick leave of less then 5 days will not require a medical certificate, but may be requested at AMS’s discretion.
    • Sick leave after 5 days will be unpaid sick leave.
    • Paid sick days after 5 consecutive days of absenteeism, is at AMS’s discretion. In times of sickness, AMS will support the employee and will require a doctor’s note describing the condition and diagnosis treatment.
    • AMS may allow their employees to use part of their sick leave for certain family obligations. This requires management approval before sick leave or absenteeism occurs.
    • Given adequate notice, AMS will allow an employee time off to accommodate unavoidable personal business appointments, including medical and dental appointments for dependent persons. Such time off will subsequently be made up at a time mutually agreeable to AMS and the employee.
    • If the employee needs to take a longer sick leave because of health reasons, he/she may be entitled to take longer unpaid sick leave. He/she may then be eligible for Employment Insurance sickness benefits or benefits from other compensation plans for work-related illness or injury.

    Recommendations

    • AMS strongly recommends that employees have short-term and long-term health benefits. If requested, AMS will provide a list of contacts to consult with if you request such information for benefit plans. By no means are you required to use the services of these contacts, rather they can be provided as a starting point into finding a short-term and long-term health benefits package that suites your specific needs and requirements.
    • AMS will be here to support the employee in times of illness for their attempts to obtain any 3rd party insurance payments that may qualify to supplement lost income due to sickness that is not covered under this policy.

    Banked Sick Time

    • AMS does not maintain a monthly credit system to track unused and used banked sick time. With this in mind, AMS does not allow employees to bank sick time.

    General Questions

    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.

    Supplemental Unemployment Benefit (SUB) Program

    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).

    Reference: https://www.canada.ca/en/employment-social-development/programs/ei/ei-list/ei-employers-supplemental-unemployment-benefit.html

    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.

    Travel & Expense Policy

    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.

     

    Reimbursement Policy

    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.

     

    Definition

     

    General

    • Arts Management Systems hereinafter called “AMS”.
    • Expenses must be ordinary and necessary.
    • Employee will be expected to pay for their own expenses while carrying out the duties of employment.
    • Reimbursement for incurred expenses will follow after an Expense Statement has been submitted.

     

    Revision History

    • February 2006
    • September 2001
    • June 1995

    Personal Expenses

    • Only expenses related to AMS business are covered by this policy and expenses of a personal nature will not be reimbursed.
    • Expenses for a spouse or other individual accompanying the employee will not be reimbursed, however special consideration may be given with prior approval.

    Personal Automobile

    • When appropriate, the Employee may be requested to use a personal automobile for travel purposes.
    • AMS will reimburse any out of pocket expenses for such travel but will not pay mileage. AMS will assist the Employee claim for such mileage as a valid tax deduction from the Government.
    • Travel to and from the airport will not be reimbursed, however parking at the airport will be paid.
    • In general, local trips by an Employee are not claimable, but where an Employee makes frequent trips in the normal performance of their duties, special consideration may be given with prior approval.

    Company Automobile

    • AMS does not have a Company Automobile.

    Places of Work

    General

    • The Employee’s place of work will be based out of their personal residence.

     

    Equipment and Supplies

      AMS will pay for telephone, fax, Internet access, and other required office supplies pertinent to the business of AMS.
    • AMS will supply required computers and associated equipment necessary to perform work related duties.
    • Providing the necessary Property and Theft Insurance coverage of AMS company equipment at your home or during your travels, will be the responsibility of AMS. Within reason, all necessary precautions will be taken on behalf of the Employee to safe guard AMS company equipment.

     

    Office Space

    • AMS will not pay for rent, lease, repairs & maintenance, cleaning materials, utilities such as heating and lighting, capital cost allowance, property taxes, house insurance, mortgage interest, or other similar costs to use this portion of their personal residence. AMS will assist the Employee claim for such expenses as a valid tax deduction from the Government.

    Travel Expenses

    General

    • When traveling beyond the city of Calgary (or normal place of residence) when required to perform Work in another city, AMS considers those to be travel expenses.
    • Travel expenses are the ordinary and necessary expenses of traveling away from home for your business, profession, or job.
    • To minimize costs for the client, AMS will reimburse costs associated with adding car rental insurance coverage for SEF20 (Loss of Use), SEF25 (Collision), and/or SEF27 (Legal Liability for Damage to Non-Owned Automobile) or similar Endorsements to your personal automobile policy.

     

    Airfare and Hotel

    • AMS will attempt to prepay airfare and hotel. In some situations, the Client may prepay for airfare and hotel expenses.
    • The Employee understands that a Client of AMS may stipulate travel conditions and the Employee will endeavor to respect the Client’s requests.
    • If airfare and hotel are unable to be prepaid by AMS or the Client, the Employee understands that they may be required to provide payment for such expenses.

     

    Car Rental

    • Car rental and associated expenses such as rental insurance, parking fees, bridge & road tolls, and gasoline.
    • Work-related running costs for a car owned or leased by somebody else – a borrowed car.
    • Fares for taxis or other types of transportation between the airport or train station and your hotel, the hotel and the work location, and from one customer to another.
    • Expenses for using the Employee’s personal car are covered in Personal Automobile.

     

    Incidentals

    • Reasonable small expenditures where it is either impractical or impossible to acquire receipts may be claimed. Such expenditures would include such items as meter parking, coin telephone, subway tokens, reasonable gratuities for baggage assistance, etc.
    • While receipts are not required, such actual expenditures must be itemized for each travel day.

     

    Cash Advances

    • In general, travel advances will not be given to Employees, however special consideration may be given with prior approval.
    • Costs will be reimbursed in advance of travel for expenses incurred in order to obtain discounts e.g. airline tickets purchased in advance in order to obtain discounted pricing.
    • In the event a trip, for which a cash advance was provided, is cancelled, a refund of the cash advance may be immediately requested.
    • Unused portions of Cash Advances should be returned along with the completed expenses form.
    • Further advances will not be granted if previous advances have not been accounted for or repaid.

     

    Other

    • Meals, out of province (state and/or country) travel emergency medical insurance premiums, and other required living expenses within reason.
    • Tips you pay for services related to any of these expenses.
    • Proof of cost of obtaining foreign currency.

    Mobile Phones

    • AMS will not reimburse employees for the use of their own equipment except for the cost of business calls necessarily incurred while carrying out their duties, and where detailed evidence of the costs is submitted.

    Corporate Credit Cards

    • AMS does not provide a corporate credit card to its Employees.
    • If a separate credit card is required to keep track of work related expenses, or an increase in credit limit is required, AMS will assist the Employee with documentation required from the Bank or other such lenders.
    • With prior approval from AMS, AMS may suggest each Employee get a personal USA Visa for company travel in the USA. AMS's accounting department will add those credit cards to the web banking capabilities so that the outstanding balances can be paid directly should the need arise. AMS will assist the Employee with documentation required from the Bank or other such lenders in obtaining a personal USA Visa.

    Reimbursement of Expenses

    • The Employee will provide proof of payment for incurred expenses to AMS, before AMS will reimburse the Employee for such expenses.
    • Expense Statements submitted between 15th and end of month will be paid with the next payroll at the 15th. Expense Statements submitted between 1st and 15th of the month may make the 15th. If company travel is heavy, there could be an extra cheque run at the end of the month. Extenuating circumstances may occur if Doug (who has signing authority of the cheques) is ever out of town for a month.
    • The Reimbursement Payment is not late until any deadline is upon us. If this affects any personal financial planning, it is the Employee’s responsibility to make appropriate arrangements. It is best that there is no dependency on early payment from AMS to meet personal financial obligations.
    • For all expenses not submitted to AMS for repayment, and if those expenses are applicable to local and current tax laws, the Employee may claim for such incurred expenses as a valid Employment Expense tax deductions from the Government.

    General Questions

    There are no general questions at this time.

    Vacations & Vacation Pay Policy

    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.

     

    Vacation Policy

    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.

     

    General

    • Arts Management Systems hereinafter called “AMS”.

     

    Revision History

    • January 2010

    Entitlement

    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:

    1. The employee must be a full time employee;
    2. The employee must have completed at least 6 months of continuous employment.
    3. Vacation can be used after the first year of accumulating time off, unless by prior management permission.
    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.

    • An employee, who has started employment prior to the 15th of the month, will receive full vacation credit for that month.
    • Employees are eligible to take their vacation effective immediately the month it has been allocated to them.
    • Vacations must be taken sometime in the 12 months after the employee becomes entitled to the vacation.
    • For a new employee within their first year of continuous employment, the employee may borrow 1 week (5 days) from their 1st year ahead.
    • Employees may carry over 1 week (5 days) of their current allowed vacation time into the next period, for up to 3 months. All other vacation must be taken in the year earned (unless specific management approval is given) and if not taken, is forfeit. The company believes vacation should be taken each year and does not allow hoarding.
    • Vacations will be given in one unbroken period unless the employee requests to take their vacations in shorter periods. This is permissible so long as those periods are at least one day long.
    • If a mutually acceptable time for the employee's vacation cannot be found, the employer can decide on the time. However, the employee must receive at least two weeks notice in writing of the start date of their vacation. The employee must take their vacation at that time.

      Vacation Pay Calculation

      Monthly Salary Employees

      • Monthly salaried employees receive their regular rate of pay while they are on vacation. It is not additional funds.

      Hourly Wage and Casual Employees

      • All other employees receive vacation pay as a percentage of wages (four percent) for the year for which vacation was given.
      • "Wages" includes any previously paid vacation pay, but does not include overtime earnings, general holiday pay, pay in lieu of a notice of termination or an unearned bonus.
      • "Year for which vacation is given" refers to the year immediately before the employee becomes entitled to the vacation.

      What is not included in the calculation of vacation pay?

      • Overtime pay, general holiday pay and termination pay.
      • Unearned bonuses.
      • Expenses or allowances.
      • Tips or other gratuities.

      Timeliness of Vacation Pay Payment

      Employees have a choice on how they receive payment for money that would be due during vacation

      1. Paid during the regular payday. This is the default.
      2. Payment of the salary that would be due just prior to beginning of vacation. This option may be used upon employee request.

      Vacation Pay Disbursement

      • Vacation pay may be disbursed on the regular payday, during the vacation time period, or immediately following a vacation, but only where it would not be practical to make the payment earlier. In the case of Alberta, employees can instead request to receive their vacation pay at least one day before starting a vacation.
      • If vacation pay has not previously been paid out and the employee requests it, it must be paid in a lump sum at least one day before the employee's vacation. In any event if prior payment is not practical , the vacation pay must be given to the employee no later than the next regular payday after the vacation begins.
      • Where an annual vacation is fragmented, only a portion of vacation pay must be paid before each period of vacation. This also applies if an employee does not take vacation in complete weeks.
      • If the employee chooses to receive their vacation pay payment in a lump sum prior to commencement of their vacation period, the employee must provide the employer (at minimum) 1 months notice before the starting date of the vacation period.
      • Employees who do not request vacation payment prior to commencement of their vacation period or fail to meet the advance notice requirement to this request, vacation pay will be disbursed on the regular payday.

      Scheduling of Vacations

      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.

      • AMS encourages employees to take minimum vacations at 5 days to receive full benefit from the time away from work.
      • Although discouraged, with prior consent under extenuating circumstances, employees may be able to take 1/2 day vacations.
      • AMS will help their employees by allowing them sufficient flexibility to:
        1.    a) break their leave up into shorter periods take vacation at the same time as their spouse.
        2.    b) take annual leave during the summer when children are at home.
        3.    c) This measure enables employees to divide up vacation time in a way that best suits them.
      • AMS has the final say when vacation can be taken.

      Division of Vacation Time

      • In Alberta, employers must allow their employees to take their annual vacation with pay in one unbroken period.
      • Nevertheless, vacations may sometimes be divided into shorter periods. The decision on whether or not to split a vacation is left at the employee’s discretion, although obtaining the employer’s consent is a prerequisite. The employer may refuse such a request.

      Waiver of Vacation

      • Waiver of Vacation specifically allow employees to forego their annual vacation in exchange for pay in lieu. In general, this request will be refused unless the employee can provide sufficient information to the employer that the proper rest and relaxation that benefits the employee both physically and mentally will be maintained to avoid any adverse effects to the employee’s ability to perform his/her responsibilities.
      • If the employee has more then 2 weeks vacation, the unused portion over 2 weeks could be considered for waiver as long as the employee has previously taken or plans on taking the 2 weeks vacation.
      • In all cases, the decision to waive a vacation must be agreed to by both the employee concerned and the employer.

      Postponement of Vacation

      The postponement of an annual vacation for a specified year of employment is expressly permitted, subject to certain conditions:

      • A written agreement to postpone a vacation must be signed by the employee affected and the employer to be effective.
      • If an employer postpones or cancels an employee’s previously scheduled annual vacation, the employer will reimburse the employee affected any vacation-related expenses that cannot be recovered through other means (e.g., non-refundable deposits, penalties and pre-paid expenses).

      Statutory Holidays

      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:

      • New Year's Day (January 1)
        •    New Year's Day is the closest thing to being the world's only truly global public holiday, often celebrated with fireworks at the stroke of midnight as the new year starts.
      • Family Day (February - approx 3rd Monday)
        •    Family Day was originally created to give people time to spend with their families but it also provides a day off between New Years Day and Good Friday as they are approximately three months apart. Common Family Day activities include skating, playing hockey, snowboarding/skiing and going to various winter festivals.
      • Good Friday (April - approx 3rd Friday)
        •    Good Friday marks the death of Jesus Christ according to the Christian religion. It is a fundamental part of Christianity along with the resurrection of Jesus on Easter Monday. Many agree that this is a more important holiday than Christmas because it is the ultimate proof that Jesus is the son of God beacuse he came back from death.
      • Victoria Day (May - approx 3rd Monday)
        •    Victoria Day is a Canadian statutory holiday celebrated on the Monday preceding May 24. It honours Queen Victoria's birthday.
      • Canada Day (July 1)
        •    Canada Day celebrates the birthday of Canada. On July 1, 1867 Canada became a new federation with its own constution by signing the Constitution Act (formerly known as the British North America Act).
        •    Canada Day is usually observed on July 1st but if that's a Sunday then Monday will be given as a day off. If it's a Saturday then normally Friday becomes the day off.
      • Labour Day (September - 1st Monday)
        •    This holiday officially celebrates workers and the labour union movement.
      • Thanksgiving (October - 2nd Monday)
        •    The original idea is to give thanks for the past harvest season but for many Canadian families the tradition has shifted and the focus is now to eat a large turkey dinner and get together with family. Apple cider and pumpkins are a must for any traditional thanksgiving celebration as well as turkey stuffing and pumpking pie. The first time Thanksgiving was held in Canada was in 1872 to celebrate the recovery of the Prince of Wales from a serious illness. After 1879 celebrations were held every year but not always in October - it used to be observed around Armistice Day in November.
      • Remembrance Day (November 11 - this may be deferred at the employee's option)
        •    On remembrance day members of the armed forces (soldiers, sailors and airmen) are commemorated. The other common name for this day is Armistice Day which marks the date and time when armies stopped fighting World War I. on November 11th at 11am in 1918 (the eleventh hour of the eleventh day of the eleventh month). Some 100,000 Canadian soldiers died in the First and Second World Wars.
      • Christmas Day (December 25)
        •    For centuries, Christian writers accepted that Christmas was the actual date on which Jesus was born.

      Other days that are not official Statutory Holidays, but could be observed by using your personal floater day:

      • Easter Monday (April - the Monday following Easter Sunday)
        •    Easter Monday is celebrated as a holiday in some largely Christian cultures, especially Roman Catholic and Eastern Orthodox cultures. It is customarily a day for visiting family and friends.
      • Civic Holiday (August - 1st Monday)
        •    The Civic Holiday is celebrated on the first Monday of August. The Civic Holiday is commonly referred to as the August Long Weekend. It is probably the busiest day on highways as tens of thousands of families go camping, to cottages etc this weekend.
      • Boxing Day (December 26)
        •    The tradition has long included giving money and other gifts to those who were needy and in service positions. The European tradition has been dated to the Middle Ages, but the exact origin is unknown and there are some claims that it goes back to the late Roman/early Christian era; metal boxes placed outside churches were used to collect special offerings tied to the Feast of Saint Stephen.
        •    Boxing Day is primarily known as a shopping holiday, much like the day after Thanksgiving in the United States. It is a time where shops have sales, often with dramatic price decreases. For many merchants, Boxing Day has become the day of the year with the greatest revenue.

      General Questions

      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?

      • The unpaid vacation entitlements for the previous year; plus
      • the unpaid vacation entitlements for the current year pro-rated (calculation based on the number of days for the last date of employment, divided by 365 days).

      • When is vacation pay to be paid to an employee whose employment is terminated?

        • Where proper termination notice is given, or notice is required to be given by the employer, vacation pay must be paid within three days of termination.
        • Where neither the employer nor employee is required to give termination notice, vacation pay must be paid within 10 days.
        • If an employee quits without giving proper termination notice, the employer must pay vacation pay to the employee within 10 days after the date on which the notice would have expired if it had been given.

      AMS Private Cloud

      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:

      Venue Responsibilities

      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.

      AMS Private Cloud Data Centres - Montreal/Vancouver

      Each data centre consists of high availability servers with a lot of redundancy. This is where all new cloud setup will reside.

      Implementing AMS Cloud checklist

      The following indicates the general steps and/or requirements for implementing or migrating a client to the AMS cloud. It has some key provisions

      Sales Cycle

      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:
      1. Default is Schedule "D" compliance: for post dated payments only. In this case, encrypted credit cards are stored in the database only for as long as is needed for a post dated payment. This:
        • drastically limits any risk exposure and
        • should be used if the Merchant Profile option below is not suitable for the venue - such as Moneris who charges exorbitant fees for the privilege.
      2. Schedule 'A-EP' if using Moneris Hosted Payment Page. This has other benefits for the venue like verified by visa, possible apple-pay online, and online debit.
      3. Schedule "C" compliance with two sub-options:
        • do not store any credit card data in AMS cloud at all.
        • refunds are done by tokens for a period of time (currently seems to be 120 days after purchase).
        • (optional) implement any need for post dated payments via use of merchant profiles, if supported by your merchant provider. This adds card tokenization (not subject to PCI) specific to your merchant processor. Cards are still never stored in the database. Most merchant providers do not charge for this, Moneris does.
      Sales
      1.2 Make sure that their internet is of sufficient speed and robustness to accommodate web sales.
      • It needs to be at least 5 megs up/down.
      • Far better is higher download like 50+ down and 5 or 10 up.
      • Test speed if need be using a login to an existing cloud client from client venue
        • Make sure client knows that we expect this to be dedicated to the sales process and not used for simultaneous download of large video files.
      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:
      • We will create a custom TLS certificate for the venue (such as tickets.myvenue.org) using the standard processes
      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:
      • Stop all their services on their site
      • Make a backup copy of the database. Typically 30-45 minutes and depends on size of database. This can be determined exactly by looking at backup start time and last modified date on any backup.
      • FTP the database to artsman. This is probably longest step and is mostly dependant on the client's upload speed. It can generally be calculated by testing their upload speed using a reading from speedtest.net inside their network and calculating

        Approx. time (minutes) = upload speed * database size in bytes / (8* 60)

      • Load up the database to the cloud server. A reasonable estimate going to be about 10% of the time it takes to make a backup.
      • Add in an estimate of time for updating versions of Theatre Manager to the latest. eg:
        • From any Version 10 should be short.
      • Add an hour for contingency or (if the timing must be precise, do a practice run).
      Sales/Support

      Prior to Migration

      Item Notes Responsible
      2.1 Create initial settings in AMS cloud Server Database. This involves:
      • Make an TheatreManager[myVenue] user in the main AMSCloud Postgres server and create a complex password (PGadmin can be used)
      • Create an empty main Database and Test database for the customer with owner being the TheatreManager[myVenue] user
      • Make an entry in the AMScloud database to register these two databases under the CustomerNumber
      • Find the customer in Daylite and look for the Remote Access note. Add in the connection information for the AMSCloud which will include:
        • The customer number
        • The password for accessing the AMSCloud database.
        Note that is password is only for connection and is not the TheatreManager[myVenue] user account info. The patron can be told what this is, so it needs to be reasonably complex with mix of upper/lower/numbers. It should not be really obvious or follow a pattern from customer to customer so that it is predictable.
      • Set up the backup script for dumping the database individually to another machine. It will be part of replication automatically
      Development
      2.2 Set up Web Sales
      • PFSense Router
        • Determine an IP address for the virtual machine and assign to the DHCP settings
        • Edit the routing table on the to point tickets.myvenue.org to this virtual machine
      • Virtual Machine
        • Create the virtual machine to be used for web sales and make sure it works
      Development
      2.3 Setup main web server with routing/TLS
      • Edit the config to point tickets.myvenue.org to this virtual machine
      • Set up the TLS that was purchased for the client
      Support
      2.4 Setup Web Sales
      • Log into the Virtual Machine that was set up for the client
      • Install apache or web services as required
      • Put the initial web pages in place
      • Set up a git repository so that we can maintain version control on web pages and back them up
      Support

      Migration Days

      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
      • Shut down web sales at the client site
      • Turn off all user access by editing the ph_hba.conf so that only pgadmin and local clients can log in
      • Run a backup
      • FTP it to artsman site
      • Set access on the file to be RWXRWXRWX - can be done with fetch
      Support
      3.3 Load up the database
      • Drop and recreate the database if it has anything in it
      • Use PGadmin or terminal to load the database from the FTP folder to the production AMScloud postgres server
      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:

      • Relay that information to the client and assist them logging on the box office work stations
      • Provide them with an email detailing how to do this for their other workstations
      • Have them do a test purchase, including authorizing a credit card - using their card
      • have them run a void on the credit card sale
      Support
      3.8 Start and test web sales, including:
      • Adding a patron to their web site
      • purchasing tickets, donations and gift certificates
      • finishing the sales process and using a test card 4242 4242 4242 4242 - and getting a rejection
      This should make sure that web is working and client can communicate with their credit card service provider
      Support
      3.9 Test Client's email server settings by making sure you:
      • Create an account on their web site and receive an email -or
      • Request a password change for your own id, if you have one on their web site
      Also have the client request a password from one of their employees. If emails are problematic, help them set up a mailgun account an enter the information into Company Preferences.

      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

      AMS Cloud Backup Strategy

      The following lists the backup strategy for private cloud databases in Montreal:
      • ONSITE at Data Centre
        • Streaming Replication: every database transaction is replicated on a 24x7 basis to second database server on another machine so that latest transaction is always on second sever. This serves as generally instant-on response in case of total failure of one machine.
        • 2 Daily Snapshots: are made and put on 3rd machine. The purpose is to provide redundancy in case the two primary master/slave machines die at exactly the same time. This allows restoration of a database that is no more than 12 hours old - and 30 daily copies are kept of snapshot backups
        • 24 Month End Backups: The backup process is designed to retain at least 2 years of monthly backups at the data centre
      • OFFSITE at another location
        • 7 Days of Offsite Backups: 7 days of daily snapshots are saved at an offsite FTP server in 'live mode' (i.e. 14 backups). This is in case there is a physical unforeseen act of god at the data centre (eg fire, insurrection, etc).
        • Recyclable NAS Storage: The offsite backups are also saved to a separate NAS box and stored until the device runs out of space and older backups start to recycle. This provides typically months worth of offline backups that take a little longer to access
        • ** periodically, the offsite backup cycle may get reset and the storage retention start again as they are not the primary backup
      • Customer Backups at location of their choice
        • Personal Backups: Each venue, per contract, can have a copy of the database sent to them daily by FTP, they just need to make and ftp site. The venue can specify how many days they want to keep and we’ll delete anything older -- The customer can pick that retention period

      Comparison of Web Sales with other vendors

      This page is intended to show comparisons with Theatre Manager ticketing site and other vendors. If you notice something about the site changes, please keep up to date -- its valuable sales intelligence.
      Competitor
      # Pages till purchase completes
      Responsive
      Flash?
      Branded to Client
      Fees
      Sample Site Comments Quirks or Additional Features
      Arts Man
      7
      yes
      no
      yes
      no
      tickets.artsman.com
      • leads you through process
      AudienceView
      calshakes.org  
      Choice Tickets
      no
      no
      yes
      Varies
      $1.50 fee
      $2.00 academic fee
      Kingsbury Hall  
      OvationTix
      colonytheatre.org
      • not bad at process
      Patron Manager
      orlandoshakes.org  
      Showare
      mtroyal.ca  
      Spektrix
      bardonthebeach.org  
      Tessitura
      strazcenter.org  
      TicketFly        
      redbuttegarden.org  
      TopTix        
      vancouverfringe.com
      • using back button at any process seems to hang system

      Exceptional Customer Support

      Philosophy

      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.

      Support Mission

      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.

      Goals

      The goal is excellent customer service. We will try to quantify it this way such that the initial response to:

      • a phone call is within 4 hours of receiving a voice mail, and within the day that it occurs if it's not in the last hour of the day. Phone support is not intended to be carried over to the next day.
      • an email request is within 4 hours of receiving the email. Next day email response to a late day email is satisfactory.
      • Observe PA DSS PCI requirements at all times when providing support, especially for remote access and managing customer data

      Expectations

      There are two levels of support, Primary and Tier II.

      Primary Level Support

      Primary support represents the initial contact that a customer makes with our support team. Generally, the roles and responsibilities are

      • Handle all incoming voice mails, emails and faxes.
      • Prioritize and categorize the support requests in FogBugz
      • Verify eligibility for support using Daylite
      • Correct any contact information in Daylite including adding new contacts and email address, and changing existing ones if people leave the organization
      • Determine which help page best answer the customers question and augment if necessary, either in the web page if the page was not clear, or in the corresponding email response if it is a very specific answer
      • Consult Second level support for non-obvious problems
      • Keep your iChat status up to date with your current status in general terms. eg 'On Phone', 'Email Support', 'Doing Demo', etc. so that other team members are aware of your status.

      Tier II Support

      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:

      • Verify if an 'odd situation' is a bug (or not) based on the observed results of a test provided by Primary Support
      • Accept only items that cannot be completed by primary support
      • Provide an estimate for completion of the task by second level support and record in FogBugz.
      • Indicate if the problem is an enhancement/feature request, or a bug along with how critical it is to resolve
      • Update the iChat Status to reflect the problem and customer. eg 'Barrington db balance', 'SOPAC Subscriptons' etc.

      General Guidelines

      • Primary support will be completed by the end of the day for calls received.
      • Verify eligibility of customers for support in Daylite. Customers with expired maintenance will be referred to the Sales & Marketing Department for further action.
      • All support arrives via and will be documented using FogBugz. Support is linked to the email address of the client by entering that in the correspondent field before the next support item is taken.
      • When you need to leave your desk and the support will be unattended, set your iChat status to 'away' with a reason or expected return time.
      • Use online help web links where possible to provide assistance with responses. If there is no link or answer in an existing page, consider enhancing the page before answering the customer and then send the revised page link to the customer.

      Be Proactive

      • To reduce further email requests for clarifications, provide all the details the first time. In other words, avoid off the cuff responses or a one-sentence replies that contains vague details.
      • Do not respond with the 10% solution. If you do not know the answer, or are not 100% sure of an answer, investigate and verify how it works in Theatre Manager. Try not respond until you know the definitive answer.
      • If a response will take some time, let the client know you are working on a solution.
      • If a request for more information is required, provide the client on information and guidance the kind of information the support team needs to resolve their questions.
      • Read the cases that have been closed in a day to see if you can learn something from them
      • Use your team members, the online help, and Tier II as resources to resolve issues

      Telephone - Priority 1

      All support calls automatically forwarded as a voice mail to FogBugz as we rarely answer the support phone directly. This is done to provide a measure of triage on incoming calls. However, customers who call support are to receive first priority for support and call-backs; as their problem is likely to be more urgent.

      Preliminary Procedures

      Listen to the voice mail in quicktime and do the following with it:

      • Determine the approximate customer requirement in the voice mail and put a synopsis in the FogBugz description field.
      • Copy the phone number to the description field and/or alter it to math the voice mail. Sometimes the incoming phone number identified by the phone system is the customers switchboard
      • Change the title of the voice mail to something meaningful indicating the topic area that the customer called about.
      • Find the patron in Daylite and put their primary email address into the correspondent field
      • If you think you know roughly what it might take to resolve the problem, place an estimate of time
      • Assign it to support (generic), or a particular person on support that day.
      • Assign a priority to it.
      • Check to see if the customer also sent and email on the same subject and then link that incoming email case to the phone case
      • Add the version number and computer OS to the boxes if known

      Response Procedures

      • When a problem is assigned to you, do any specialized research required on the problem so that you are ready to deal with the call. Call the customer back, or if the answer is explained directly in our support site, email the customer with the support link and then follow up in short order to discuss the email link.
      • Generally, phone replies are for questions that we think can be answered in ten minutes or less.
      • Anything requiring longer explanation should be scheduled for training and/or for a specific time period. If that is the case, contact the customer right away, explain that it is a probably long response requiring concentrated 'quiet' time and arrange an off peak or appropriate time that meet the needs of both the customer and Arts Management. Generally, mornings appear to be best.
      • If the problem being reported is likely to take a long time and requires further research, advise the customer of the time you will get back to them with the probable answer.

      Email & Fax - Priority 2

      • Will be replied to within 4 hours of when they come in.
      • Will be replied with step-by-step guidelines to resolve their question.
      • Will refer to web site links for information as much as possible (the goal is all requests for information and processes
      • Faxes will be stored on the server and linked in Daylite to the ‘references’ pane.
      • Email contacts will be entered and updated in Daylite so that a ‘white list’ of their names can be created for valid email filters to Arts Management’s Email system and sending announcements to users and knowing that the user will receive the announcement. When available, the following minimum information will be captured:
        • Email address
        • Full Name (first and last name)
        • Direct telephone numbers
        • Address
        • Position within the organization

      Online Help - Priority 3

      The help is all contained within theatremanagerhelp.com. Each support representative has access to edit and correct pages that are factually inaccurate. Before responding to a patron, find a web page that answers their question. Read the pages to see if it makes sense, or if some part of Theatre Manager has changed due to a version release, correct the discrepancy in any text and revise pictures if required.

      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:

      • Identifying deficiencies and provide the updated corrections or improvements in manuals and support documentation.
      • Monitoring Email responses and add to existing online support web pages where appropriate.
      • Perform queries within online support web pages to bring up answers to questions and provide those links to clients within responses to their questions.

      Daylite

      Daylite is the corporate contact and sales management system. In general, all the primary contacts for any customers will already be in Daylite and are going to be used for reference purposes by the support organization.

      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.

      • All contact information will will be documented in DayLite and the contact associated with an organization. This means names and addresses for all contacts. There is a 'grab' button to get the primary organization address to simplify data entry.
      • Please check with Daylite to confirm the version number that the venue is using to transfer to FogBugz support tracking.
      • If somebody leaves an organization, please mark there relationship as 'former employee' and the description as 'former xxxxxxx' - daylite.

      Support Guidelines

      General

      The purpose of support is to provide our customers with 'how to do it' answers and not to 'do it for them. How to answers are generally handled right away by referring to a web page.

      General Philosophy

      • Customers are our best source of continuing business and new referrals. They are to be treated with courtesy and respect at all times.
      • All clients are to be treated as equal and will get complete detailed explanations. This is to avoid the cases where some clients who are friendly get chatty responses; some clients get terse responses; some clients get no responses.
      • Have the client assist in duplicating problems that they bring to our attention. Once a problem can be duplicated, or we have received the steps to create the problem, a resolution can be determined.

      Time Consuming Issues

      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:

      • Ticket face coding will be completed during non-busy support times.
      • System balancing will be completed during non-busy support times.
      • Building a new venue map is generally a special project
      • Season subscription setup/training will be completed during non-busy support times. This process may take 1 to 2 hours, so a block of time needs to be set aside.
      • Web support will be completed during non-busy support times - unless it is an emergency and sales will not work

      Training & Demo Sessions

      • Training and demo sessions are all to be pre-arrange and handled through the Sales & Marketing Department.
      • Telephone training/demo sessions will be completed during a scheduled time when there is secondary support available to handle the calls or during a non-busy support time. This process may take 1 to 2 hours, so a block of time needs to be set aside. Between the hours of 8:00AM to 10:00AM if possible.
      • Limit the number of training, demos or setup sessions scheduled for Wednesday’s. This is the support’s heaviest day of the week.
      • Always check to see who else is available to provide primary support when a phone training session is planned and keep the team informed of status via iChat 'status' (eg 'training customer' or 'phone demo', etc.)

      Transfer Ownership of a Case

      Some issues take longer than others to finish and will require follow up if you leave to go on site at a client, go on vacation, go to the doctors, or take time off for any reason.

      Prior to leaving the office, there is to be a turn-over process.

      • Examine all your existing cases that are in progress.
      • Discuss them with a team member and assign a case to somebody else with their permission.
      • Repeat for all cases currently in your bailiwick prior to departure.
      • the expectation is that all cases can be reassigned to someone else
      • If there is a complicated case and you choose to keep it, then you are expected to follow that case until it is done. That means, while at a customer site, to complete that case after hours. Or, if on vacation, to deal with the case on an ongoing basis to continue to provide excellent customer service.

      Remember: complete or turn over all cases prior to going on a protracted leave and advise your team of any peculiarities on the case

      Remote Access

      All remote access is to be done at the invitation of the customer. The product we use is called teamviewer and it is built into Theatre Manager. If you are on the phone with the customer and need to use remote assistance, the procedure is:
      • Ask the customer to activate the remote access session
      • Ask them to provide you the number and password for remote access the session
      • Connect to their work station
      • Ask the customer to confirm our identity by providing them their customer number and having them look it up in 'about Theatre Manager' or providing the case number that they received from us that initiated the need for report support session (PCI requirement for authentication)
      • As part of the pre-amble, inform them how they can disconnect you immediately if there should be anything come on the screen that they feel you should not see or is private.
      • Provide the appropriate support
      • When the support all is finished, have the client disconnect you and have them acknowledge you are gone
      • Do not leave a session active when you are done. If need be, close the session on their end to force you out.
      If you remote into a customer site and log in, all passwords used on a customer site must comply with the same rules as PCI DSS requirements 8.5.8 to 8.5.18 (described here) and if customers do not appear to be using compliant passwords, a gentle reminder could be useful.

      All Theatre Manager access passwords are required to be PCI compliant in Version 9

      Daily Activities

      First Thing (7:45 to 8:00 am)

      First thing every morning:
      • Log into Daylite
      • Log into FogBugz and review your cases from the prior day
      • Listen to and prioritize all Voice Messages that came in since the close of support the previous day. This is to be done first thing in the morning before any other support is commenced
      • Prioritize all existing and new cases

      Be there ready to begin support at 8:00AM. Not 8:15AM, not 8:25AM.

      Morning Activities

      Morning activities are prioritized to clear out any backlog from the end of day or that came in overnight.

      • Call back clients that have purchased after hours support. Their organization account has ‘911/After Hours Support’ in the Groups Classification tab in Daylite.
      • Send emails to clients who call outside support hours that indicated the regular support hours. Also, answer their question if you can by email with a web help link to get them started.
      • Check all existing cases for any further customer replies and deal with those first. It is especially important for cases 'waiting for customer response' or those assigned to second level support.
      • respond to clients in priority order

      Afternoon Activities

      • Re prioritize all existing cases, especially those whose system is down versus common questions
      • Prioritize by East coast versus West coast and answer the East coast first.
      • Need to be careful not to postpone a critical support issue, with an incoming phone call for training or help style question. Let the client know that we will get back to them as soon as practical. Complete the critical support issue.

      All Day Activities

      Classify and Respond to voice mail
      • Evaluate the voice mail for priority
      • Respond according to priority
      • Converse with second level support if an item appears to require Tier II support and assign appropriately
      • Record contact changes in Daylite
      • Adjust web pages as required to provide clearer answers

      Close of Day (4:30 to 6:00 pm)

      Nominal support hours are currently 8:00am to 5:00 pm mountain standard time and customers are informed of this during the sales process, during training and at various other junctures. The geographic distribution of the support team means that we are following these hours corporately as best we can.

      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:

      • All outstanding voice messages will have been replied to
      • All emails and faxes that arrived prior to mid afternoon will have been replied to.
      • Very late incoming emails will be answered is possible, and if not left for the next day. Since all emails are auto-responded, the customer should have received confirmation that we received it and replying is not necessary
      • All new customer contact information that you received during that dat has been updated in daylite. Normally, there may be one or two people, so the volume is not high
      • at 5:00pm, check for voice messages one last time

      Prioritization Policies

      Cases should, in general, be worked on in a first come-first serve basis so that all customers are treated fairly and equally.

      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

      Treat Customer Data with Care

      Customer data is to be considered sensitive at all times, especially when it comes to data relating to PCI compliance and credit card information. Please refer to our specific data storage policy that is to be respected all all times.

      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.

      FogBugz Issue Management (Change Control)

      Reviewing issues

      The first place you go every day should be to FogBugz. Start FogBugz, login and you’ll see the UI similar to the one below.

      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.

      Find issue by number

      To locate a specific issue number type the issue number in the upper left search box and click the magnifying glass

      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.

      Issue details

      There is a lot of information that a FogBugz issue can hold. The documentation, again, will provide the most complete overview of all the data, but here are a few areas you should be familiar with.

      Description

      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.

      For all Bugs or Support Issues

      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.

      • Enter the correspondent's email address if the incoming item is a phone message
      • Assign to a staff member (normally yourself, but could be second level support>
      • attach or relate to any prior sub-cases that you are aware of or are in the links
      • Estimate the amount of time that it may take to solve the issue
      • Enter the version of the software in the form VXXXXX - such as V82501 - that the user experienced the issue with
      • Indicate what operating system that the user illustrated the problem with

      For New Development

      For new development tasks, or task transferred from support to development:

      • enter the estimated due date (or date that the customer might want the item) if there is a deadline
      • Assign the task you 'unassigned development'
      • Change the 'project' from 'Inbox' to 'Theatre Manager'
      • Change the area that the problem is in to categorize it. That way, when code is opened up, we can look at other tasks in that area and resolve one or more issues, or see how often the issue has been reported
      • Indicate the approximate release we may wish to release this code

      History

      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)

      Development Estimates

      Once you have determined what needs to be done you should fill out the Development section as shown below. Fill out:
      • Proposed changes in the text area
      • Estimate in the estimate area
      • Set the category, area, milestone as required
      • Associate any sub cases
      As more is known with the case or other issues are discovered, edit the above, or create additional tasks to track subsequently discovered issues

      Forward an issue

      If you are rejecting an issue, or you have completed an issue, it is time to reply to the originator and complete it.

      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.

      Creating an issue

      You may need to create an issue. You can begin this by clicking on the ‘New Case’. Refer to the section called ‘description’ above for a screen shot and what to enter.

      Start by selecting the category of issue that this will be, then use the following guidelines.

      • Bug – This is a defect in the application
      • Feature – This is a change to the functionality of the application
      • Inquiry – This is a query about how the application works
      • Schedule Item – This is a proposed new feature for the application that has not yet been approved
      In most cases these are the four you will be dealing with. Most of the time, as a developer, you have to create an additional issue to document a fix you put into place for a bug that you discovered while fixing a current issue.

      Emailing Cases

      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.

      Completing an issue

      When a development issue has been completed and check into the VCS, it must also be completed in FogBugz. Find the case number and:

      1. Edit the case
        1. Change the project to Theatre Manager
        2. Category to bug or enhancement
        3. Area to reflect the part of the application that was changed
        4. Who completed the task (if it is different than the assignee)
        5. And the release number milestone that the fix is targeted for
        6. Fill in the estimate if it was not already filled in.
        7. Add notes about the resolution. This is probably similar to the VCS notes.
        8. Click OK to save the changes.
      2. Set the the case to be tested
        1. Management will assign a tester to the case to confirm functionality
        2. This should include visual inspection of the code where appropriate
      3. Then, resolve the case and provide:
        1. The actual hours to resolve the issue
        2. Add release notes that are suitable for providing to the customers and pasting into the theatremanagerhelp.com release notes.
        3. Close the case

      Product Development Process

      Defect Tracking Process

      The Arts Management Ltd. support and development teams will use the FogBugz defect tracking tool to manage development tasks such as implementation of new features, change requests, defect correction, etc. This tool will present developers with information related to issues and will allow them to prioritize their tasks based on these assignments.

      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.

      FogBugz

      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/

      Issue Submission

      Tasks that will eventually get assigned to developers come in from a variety of sources. Issues logged as defects will be evaluated by the Development Team to determine the validity of the issue and to assign the severity and the target release. Feature or change requests are evaluated by the Product Design Team to determine the sensibility of the request and the overall market need for the change.

      Who Can Submit Issues

      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.

      Product Design Team

      The Product Design Team will submit new feature and change requests for future development. Additionally, bugs may be found during customer support sessions that will be submitted for resolution by the support team.

      Technical Support Teams

      Any Arts Management Systems team (Support, Management, Development) may, in the course of the day, interact with customers. Issues logged by these groups in FogBugz may include defects with step-by-step instructions about how to recreate the defect, and sample data if necessary (see the section below entitled Secure Storage System).

      Feature and change requests will also be submitted to the Product Design Team.

      Software Quality Assurance Team (SQA)

      The software quality assurance team ensures that the software we develop passes our rigorous internal testing before it is released. Issues are validated to ensure that the developer has completed the necessary work and that the reported issue is solved in a manner consistent with the product design and customer expectations.

      The issues reported from SQA will include refinements to existing issues, new issues caused by a break to existing code, and change requests.

      User Acceptance Testing

      After SQA has completed their testing of a release and prior to releasing that version, products will undergo a few days of User Acceptance Testing. The Arts Management Systems Beta Management Team manages this process with representatives from various Arts Management Systems departments participating in the test effort. The focus is on customer use model testing and is an unscripted process.

      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).

      Development Team

      Issues across applications can also be found by developers. These issues may be discovered while working on other issues, or just in use of the product. When an issue is discovered it is the responsibility of the developer to log the new issue even if it is something that is fixed while completing another task. This level of record keeping will ensure that there is accountability for the changes in the applications.

      Target Release

      Each issue is assigned a Target Release Date which is the expected release for the change. This assignment is based on the severity of the reported issue, source of the reported issue, and customer priority. Tasks will be assigned to each developer and should be started based on the Target Release Date and priority. If the issue does not have a Target Release assigned, it is possible it is deferred to a future release.

      Severity

      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.

      Issue Resolution

      When an issue comes in, a developer has many steps they go through in solving the problem. While these are not always followed verbatim they should be considered best practices for solving issues.

      Validating

      When first looking at an issue there are a couple of steps that should be taken to validate that it is a real issue, and not a problem with the operation or state of the machine that the application was running on.

      Is this the expected behavior?

      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.

      Pre – Testing

      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.

      Scoping

      Once an issue has been validated it is up to the developer to decide if there is enough information to proceed with code changes.

      Addressing Security Concerns

      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.

      Return for more 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.

      Sent for Design

      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.

      Technical Specification

      When a change to the applications reach the level that a functional design is required then a technical design may also be required.

      When to do them?

      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.

      What goes into them?

      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.

      Template

      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 .doc’ and a history retained in the TM Development/TM Design Documents folder.

      Optional elements

      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.

      Peer Review

      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.

      Methods

      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.

      Persons involved

      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.

      Security Concerns

      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.

      Developer Coding Cycle

      When a developer is ready to begin coding there are a number of steps that are a part of Arts Management Systems normal Agile software development process. These are detailed in the following sections.

      Version Control

      The Studio Version Control Software (VCS) is in use to allow us to track changes made to the source code for our applications.

      VCS 101

      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.

      Implementation

      The actual process that a given developer will use in changing code is varied and not covered here. We have standard tools provided, but do not force limitations on the flexibility required for successful development.

      Platform

      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

      IDE

      Primary Development is done using:

      • Omnis Studio (which controls, chroma-codes and interprets code as it is entered)
      • Python using Pycharm (which chroma-codes and inspects code as it is entered for pep-8 compatibility)
      • Some minimal ‘C’ code. In such case, Developers are free to use any editors as long as these do not introduce editor specific artifacts into the source code.

      Tools

      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.

      Code Writing

      While there are not specific rules for the code you will write, there are a number of coding guidelines that should be followed. Most of these can be found in the documentation.

      Best practices

      There are documented coding guidelines that Arts Management Systems developers should follow.

      Security Practices

      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

      In-code documentation is required for all new code as described in the coding practices.

      Protected Classes

      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.

      Defect tracking notes

      As you work you should keep track of the units you change and what the overall changes to those units are. This can most easily be added to the check in notes in the VCS.

      Unit Testing

      After making the necessary code changes unit testing is required to ensure the issue has been fixed correctly and that no aberrational effects have been introduced. As a developer your unit test should test the use of the new feature and when necessary test the application without the new feature. Both these inclusive and exclusive tests will reduce the number of issues returned from SQA marked “retest unsuccessful”.

      Inclusive Testing

      An inclusive unit test is one where you actively try to use the new code changes. For example if you added code that did something when an invoice was saved you would go through the process of saving an invoice. You should try as many permutations as seem relevant. For example if you were testing the amount of a fee at the time the invoice was saved you should save the invoice with lots of different fee amounts and types to ensure there are no defects in the new code.

      Exclusive Testing

      An exclusive test is one where you test what happens when new code is not used, but related blocks of code are called. For example if you added code that was triggered by the user having a preference active you would have tested that code already with the inclusive unit testing. Now go back and disable the preference and repeat all the same test cases. This will ensure that you have not added any aberrant behavior when the code does not fire.

      Step Through and Branch Testing

      For all newly written code in Theatre Manager, the developer is expected to step through each line of code manually and verify the code is changing the variables as desired. If a code branch is not taken, the developer is expected to set up a condition to take that branch and prove that the values work, the notation is correct, the parameters are correct as designed. A developer is not expected to step through known to be working super class methods – those can be stepped over unless it produces an unexpected result.

      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.

      Security Testing

      Some segments of code are particularly vulnerable to security controls and/or breaches. This would represent the parts of code that touches credit card information or any of the web components.

      Credit Card & Security Testing

      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.

      OWASP testing

      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

      Checking in changes

      Once you have ensured that your code changes are acceptable and they perform as expected, you can now check them in to the appropriate VCS. Special care should be given to checking code into different branches. Dependencies that existed in one branch may not have been fully implemented in other branches.

      Periodic Build Testing

      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.

      Peer Review

      Peer reviews are a necessary part of improving our development process. They need not be overly complex or complicated. A peer review of you code changes is required for any code that is written to deal with sensitive data (credit cards, etc.). Peer review may also be required for a number of other reasons, including but not limited to changes to any code that works with or stores credit card data.

      Methods

      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.

      Persons involved

      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.

      Security and Protected Classes

      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.

      Hand Inspection

      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.

      Review Approval

      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.

      Release to Software Quality Assurance

      Once your code has been tested, reviewed, and checked in the issue is ready for SQA (Software Quality Assurance) testing.

      Documentation

      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.

      Defect Tracking Cycle

      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.

      In person follow up

      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.

      Candidate Builds for QA/Production

      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.

      Separation of Environments

      The Studio VCS is used to help control and separate the Development, Test and Release functions.

      • Developers test on their own machines, and at the end of the building and unit test processes, must place code into the VCS.
      • The QA Test team builds candidate release from the VCS and uses their own test databases and test suites to prove the bug fixes or enhancements
      • Code designated as a production release will go through the final build and testing process

      Release Builds

      There are two ways to release Theatre Manager to customers.
      • Auto Deployment - a release library is packaged up and placed into our CDN for delivery. This should be targeted to testing (for testing), then support, then selected customers, then all customers according to a timeline based on the type of changes
      • Downloadable Installers - a full installer (containing the same release library) should be made periodically for those sites that prefer to download and self install. If there is a sub-component change like the word processor, that may need an installer. In general, the Downloadable installers do not need to change often and must be a version equal or after the current auto-deployed versions.

      The release process for Auto Deployment and Downloadable Installers is similar. There will always be:

      • Beta build for internal testing
      • Release Candidate for testing within the support team
      • Targeted Releases for specific customers with specific problems
      • General Release for releases that pass muster in the above three test levels
      • Backout Release which is a re-deployment of the prior version, except with the version number rolled ahead of the abortive release.

       

      When code has been designated for potential release:

      • a final build of the code will take place using Build without Comments
      • it will be placed onto the build directory and new installers built using the automated deployment scripting tool that is platform appropriate:
        • Macintosh: we use packages to make a mac platform .pkg installer (see release notes)
        • Windows: we currently use Installer Vise
      • the installers will be tested on all platforms to ensure they run as expected
      • the full installer will be placed on the production servers as 'Final Candidate'
      • the Support team will download and perform complete installation and usage tests, prior to public availability and notification.

      Beta 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.

      Production Release

      When an installer is deemed ready for public release, a number of steps need to occur:

      • Release notes are to be created and published in the version release notes that contain:
        • change notes compiled from aggregating and editing the developer checkin notes from the VCS and enhancing with information from FogBugz.
        • a complete steps to upgrade all affected components
        • an estimate of the time that a release will take
        • any special notes or warnings as necessary
      • The release will be placed into the 'PriorVersion' directory and given a codified name for Arts Management purposes
      • A file on the server will have an entry placed into it that details the version number, release date and codified name. The purpose for this is so that a client can retrieve prior versions in the case a backout is required
      • A brief 'marketing summary' of the release notes will be created and placed into the RSS feed on the main help page and published for public consumption

      Auto Deployment Builds

      Set Version in Theatre.lbr

      in Startup_task method, set the following three items:

      • Version Number according to the versioning terminology.
      • Migration Step to be the minimum allowed TM server version that the client will work with
      • Release Date to be the intended release date
      This will be used by the manifest.json file to determine actual eligibility for the release per the last item in this checklist.

       

      Privatize/Lock the Library classes.

      Auto Deployment builds require the Theatre Manager library be built without comments and to be locked except

      • All Report Classes - excluded using filters in the Studio development tool
      • Password Classes - excluded using filters in the Studio development tool
      • Systems Classes - excluded using filters in the Studio development tool
      • the 10 or so specific classes that are marked with a bullet and are easily found by sorting the classes. An example is shown below

       

      Testing With Runtime on Test Environment

      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.

       

      Building Auto Deploy Package

      • Rename the Theatre.lbs library to be TheatreXX.YY.ZZ.lbs where the XX.YY.ZZ matches the versioning terminology.
      • Use the Studio development tool to make a specialized JSON payload, encode and zip it into a file.

        The menu is Developer->Make AutoDeployment LBR's for 2ndGen

      • This will:
        • ask you for the location of the libraries and reject if not in the proper name
        • encode, compress and zip the file for you into the desktop
        • Display a message telling you to open terminal and paste the clipboard into the command line to generate a SHA384 hash
      • Open Terminal and paste from the clipbard. The command should look similar to below. When you hit return you will get the proper SHA-384 checksum for the zip file.

       

      Staging deployment package to the CDN

      • Login into Digital Ocean and go into the artsman-updates CDN folder. Drag the TheatreManager-XX.YY.ZZ.zip file created in the previous step to the Digital Ocean CDN and make sure to set the permission to public

      • Also, log into the web server via seafile and push the release candidate into the folder as shown.
        • You can place the file into both the production and test folders.
        • A release will not proceed until the manifest.json file is edited.

       

      The Manifest.json file

      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:

      • Via the Test release manifest and directories:
        • all developers and verified for deliverability and changes.
        • all support staff and verified in course of normal use.
      • Via the Production release manifest and directories:
        • the specific customer(s) that need the change immediately to correct their issue
        • all customers subsequent to verification of each release stage

      The components of the JSON file are:

      • Major and Minor version numbers that this release is applicable for according to the versioning terminology.
      • Minimum TM Server to co-ordinate that the release will not download unless the TM server is at that version
      • Release Payload - the name of the release
      • Permitted Customers - the licensee's that are able to download the version. If this is incorrect, nothing will download to the customer.
      • SHA384 checksum - of the payload. if this is incorrect for the version, nothing will download
      • CDN Location - the URL of the file to download. if this is missing or private in the CDN, nothing will download.

      Backout Process

      Prior Public Releases of Theatre Manager are kept on the web site in a 'PriorRelease' folder for that version. In the unlikely event that a current release needs to be backed out, it is fairly easy to do, in effect reversing the release process that is used to put a version in place.

      The backout steps are:

      Remove current production installers

        Remove the version and file number from the file containing the list of releases on the web site
      • Mark the deployment package the Digital Ocean web site PRIVATE and change the manifest.json file so that deployment will not continue by putting a '-' in front of the venue URL's. Do not remove the venue URL's since the back-out will require knowing who could have downloaded the version.
      • Rename the TMSetup.zip or TMSetup.exe installer file so that it can only be accessed if the file name is known. This is for internal purposes and restricted access.
      • Edit the release notes on help.theatremanager.com for that version and mark as pending final testing
      • For customers that are using that version:
        • ascertain the impact of continuing to use the version by doing a mini SWAT analysis. (i.e. are they affected by the issue that was discovered, or don't they use that part of the application).
        • If customers need rolled back, they will be instructed to put the older version in place
        • the support team will roll back the database version so that they can use the older version.
      • Assign first priority for development to make any corrections to the code that prompted the backout in the first place for the next developer release.

      Create a New Installer

      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)

      Version Control

      There are two primary version control systems in use for the development process. These are:
      • Omnis Studio VCS - which is provided by the vendor and used exclusively for the version control of any Omnis Studio Code
      • GIT - which is used as a version control system for any other project, specifically python, web pages, and C code

      GIT Repository

      All code & web pages (other than Omnis Studio) is saved in our GIT repository from git-lab

      There is ample documentation on

      • git-lab on line
      • and the general usage of git to make:
        • repositories
        • Pushing changes (similar to Check-in)
        • Pulling revisions (get latest changes for a branch)
        • Making branches (we always have master, current development branch and any a number of specific branches for features)
        • Merging branches

      Various Git tools provide ample ways of diff-ing changes in versions, seeing who made the change (blame) etc.

      Omnis Studio VCS

      The features of the Omnis VCS are described in the Omnis Developer Manual. The key ways that we use it are described in the following sections.

      Branches

      The Omnis Studio VCS supports branches of code. This is a feature that is NOT TO BE USED at this time because it does not support merging branches. When this merge feature is provided, we will have two code branches: Main and HotFix

      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.

      Getting Source

      When you are ready to get the source code, build a library by starting the Studio development tool, signing in to the VCS and then ‘build updated projects’. Make sure your library status is ‘Unlocked’ for development (locked is used for a release build)

      Get Latest Revisions

      To get the latest code to an existing library, click on the ‘Theatre’ icon and then ‘update from VCS’ link. A list of changed components is presented to you. Copy them out ‘read only’ if you do not plan on changing them. Do not fill in the ‘Check Out Notes’

      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.

      Comparing Revisions

      If you want to compare the current source with a particular revision of the code, select the class comparison tool and select the class that you are interested in the upper window. Select the VCS and the version from the check in history that you want to compare the current code with. This illustrates the importance of the check in notes.

      Checking Out

      The VCS is a locking version control system. When you are ready to make changes you need to check out (or unlock) the code you want to change. To do this in VCS, find the component you want to change, right click on it, then select ‘Check Out’

      On the checkout window, indicate:

      • the reason you are checking out the component. If there is an associated FogBugz case, enter that as in the checkout notes along with a brief synopsis of the activity intended to be worked on.
      • If you are updating from the VCS or testing a component, indicate that you are copying out the components for testing.

      Adding Classes

      If you need to add new classes to the code, click the ‘New Class’ option. That will automatically create a new class for you and mark it as ‘locked’ by you. Anything that has a ‘lock’ is a candidate for check in.

      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.

      Checking In Changes

      When you are ready to check in units, either right click on the specific class and check-in or use the ‘Auto Check-in’ option on the window. When you select either, you will be presented with a list of classes you have checked out. Click on the classes that are to be returned to the VCS.

      When checking in, make sure that you:

      • put the issue number from FogBugz in the check in notes (if available).
      • add an explanatory comment with the case number
      • indicate the severity of the issue and scope of the change
      • update the version number to match the current release version to indicate when it was fixed.
      • Complete the case number in FogBugz and to indicate its status, mark it complete, ready for testing and put in release notes into FogBugz as well. Ideally, the release notes and the check in notes should be the same.

      Current Responsibility Matrix

      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.

      Software Development Lifecycle

      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.

      Agile Principles

      Agile methods are a family of development processes, not a single approach to software development. The Agile Manifesto states: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
      Individuals and interactions over processes and tools
      Working software over comprehensive documentation
      Customer collaboration over contract negotiation
      Responding to change over following a plan
      That is, while there is value in the items on the right, we value the items on the left more.

      Some of the principles behind the Agile Manifesto are:

      • Customer satisfaction by rapid, continuous delivery of useful software
      • Working software is delivered frequently (days or weeks rather than months)
      • Working software is the principal measure of progress
      • Even late changes in requirements are welcomed
      • Close, daily cooperation between business people and developers
      • Daily conversation is the best form of communication (co-location)
      • Projects are built around motivated individuals, who should be trusted
      • Continuous attention to technical excellence and good design
      • Simplicity
      • Self-organizing teams
      • Regular adaptation to changing circumstances

      Source: Wikipidia

      Contrasted with Waterfall Methodology

      Agile development has little in common with the waterfall model. The Waterfall methodology is the most structured of the methods, stepping through requirements, analysis, design, coding, and testing in a strict, pre-planned, "all at once" sequence. Progress is often measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.

      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.

      Release Definitions

      Software Releases are typically comprised of new features and defect corrections. The number of features and / or defect corrections addressed in any release is dependent upon several factors including severity of the issue, timing, development effort required, competitive advantage, etc.

      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:

      • Development Release: this release typically addresses a very critical need for a specific customer.
      • Production Release: this release is made available to customers when an arbitrary number of work items have been completed that meet customer needs, however significant or insignificant in scope. There will generally be at least one functional release per month that will have comprehensive release notes and back-out strategies. Clients do not need to implement the functional release unless there are items of interest to them. Functional releases are alway cumulative so skipping one release and implementing the next always gives the client the cumulative effect of all functional releases.
      • Major Release (the major release number is incremented): this release is scheduled to coincide purely with PA DSS certification because the PCI standards council has decided in an arbitrary manner that applications can only increase the release number at the time of their PCI audit. For Arts Management, that will mean a new release number every three years.
      The objective is to only include changes that affect PA-DSS Certification status in a Major Release and not more than once per year. A PA-DSS Checklist has been incorporated into our release process to assist in identifying impacts to our payment processes at the onset of a project and throughout the development cycle. Appropriate actions and decisions can be made based upon the assessment during the development cycle.

      Release Process

      The agile development methodology is ideal for customer driven software delivery. It involves one or more iterations a feature under the principle that the first set of requirements can only address things we suppose to be correct. Quickly building a prototype and showing it to team members and customers leads to other requirements that may, or may not get included.

      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.

      General Principles of Agile Unified Process

      The links will take you to the implementation of the process in our product development process

      • Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain.
      • Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit testing.
      • Test. Perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.
      • Deployment. Plan for the delivery of the system and to execute the plan to make the system available to end users.
      • Configuration Management. Manage access to project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.
      • Project Management. Direct the activities that takes place within the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget. We use FogBugz to track development tasks in a particular development release iteration, status and additional notes about them.
      • Environment. Support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.
      All stages above take into account PA-DSS requirements in the Product Development Process and the requirement to fill the PA-DSS worksheet if PA-DSS is impacted. However, by design, the only release could affect PA-DSS is the Major Release as design and product releases will take all pains to avoid such implications.

      Philosophies

      The Agile UP is based on the following philosophies:

      • The staff knows what they're doing. People are not going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you are interested, but doesn't force them upon you.
      • Simplicity. The Agile UP conforms to the values and principles of the agile software development and the Agile Alliance.
      • Focus on high-value activities. The focus is on the activities which actually count, not every possible thing that could happen to you on a project.
      • Tool independence. You can use any toolset that you want with the Agile UP. The recommendation is that you use the tools which are best suited for the job, which are often simple tools.
      • The AUP an be tailored as required to meet the needs of the development release iteration.

      Releases

      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

      TLS Certificates

      Creating KEY and CSR - Certificate Signing Request

      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.


      Step 1: Generate a KEY Pair

      The utility "openssl" could be used to generate the key and CSR. This utility comes with the OpenSSL package and is usually installed under /usr/local/ssl/bin. The following instructions will use the openssl that is installed with the standard Apache installation on an OS-X computer.
      1. Open Terminal
      2. At the command prompt, type: cd /Library/TLS to navigate to the desired folder where the files will be generated
      3. At the command prompt, type: openssl genrsa -out server.key 4096 to create a key file with 4096 bit encryption
      4. Wait for the server.key file to finish being created in Terminal The process is complete when Terminal returns to the command prompt. A server.key file will now appear in the /Library/TLS folder from above.

      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.


      Step 2: Generate the CSR

      1. If you have moved from the current directory from Step 1 above, at the command prompt, type: cd /Library/TLS
      2. At the command prompt, type: openssl req -new -key server.key -out server.csr to enter the server.csr setup process This creates the server.csr linked to the server.key file for security purposes.
      3. Enter the following details:
        • Country Name (2 letter code) [AU]: the two-letter code without punctuation for country Enter US (for USA) or CA (for Canada).
        • State or Province Name (full name) [Some-State]: the full name of the State or Province Do not abbreviate the state or province name.
        • Locality Name (eg, city) []: the City name
        • Organization Name (eg, company) [Internet Widgits Pty Ltd]: the full legal Company Name If the company or department has an &, @, or any other symbol using the shift key in its name, you must spell out the symbol or omit it to enroll. Example: XY & Z Corporation would be XYZ Corporation or XY and Z Corporation.
        • Organization Unit Name (eg, section) []: this can be left blank This field is optional; but can be used to help identify certificates registered to an organization. The Organizational Unit (OU) field is the name of the department or organization unit making the request.
        • Common Name (eg, YOUR name) []: the primary domain name the TLS Certificate will be generated for Enter the tickets.myvenue.org URL for the web sales ticketing site. Do not prefix it with http:// or https://. This name must match EXACTLY to what will be used for the https://tickets.myvenue.org online ticketing site.
        • Email Address []: the registered domain approval email address This can be one of the five email addresses approved by GeoTrust or the email address registered to the domain.
        • A Challenge Password []: do not enter a password for the TLS Certificate Entering a password means the Theatre Manager Server will not be able to start Nginx as the password is required during startup and is not supported at this time.
        • An Optional Company Name []: this can be left blank
          • A server.csr file will now appear in the /Library/TLS folder from above.

      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.


      Step 3: Generate the Diffie-Helman

      1. If you have moved from the current directory from Step 1 and 2 above, at the command prompt, type: cd /Library/TLS
      2. At the command prompt, type: sudo openssl dhparam -out dhparam.pem 4096 This creates the Diffie-Helman file.
      3. Wait for the dhparam.pem file to finish being created in Terminal This process will take some time and is complete when Terminal returns to the command prompt. A dhparam.pem file will now appear in the /Library/TLS folder from above.

      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.

      Submitting CSR for TLS 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.

      Submitting CSR for TLS Certificate - NameCheap

      Step 1: Access GeoTrust's Vendor Portal

      1. Access the NameCheap vendor portal via https://www.namecheap.com/myaccount/login.aspx?ReturnUrl=%2f
      2. Enter user name artsman
      3. Enter password refer to Daylite
      4. Click Sign in and Continue

      Step 2: Place Order for Certificate - PositiveSSL Multi-Domain

      1. Click Security >> TLS Certificates.
      2. Click the Buy Now button under the PositiveSSL Multi-Domain option.

      3. Select the number of years the TLS purchase will be valid for. Most clients purchase for 2 years.
      4. Click the Add to Cart button.

      5. After reviewing the order details are correct, click the Confirm Order button.

      6. Click the Pay Now button to purchase the PositiveSSL Multi-Domain SSL.


      Step 3: Activate the TLS Certificate - PositiveSSL Multi-Domain

      1. Click the Manage button in the Purchase Summary window.

      2. Click the Activiate button to start the activation process.

      3. Step 1: Enter CSR & domains PositiveSSL Multi-Domain will cover
          Copy and Paste the content from the .CSR file into the Enter CSR field. The Primary Domain field will populate with the domain name.
          Enter the additional domain names in the Add 2 more domains fields.
          Click the Next button.

      4. Step 2: Check PostiveSSL Multi-Domain CSR info
          Review the Domain names.
          Select the web server. This is usually set to Any other server (cPanel, Apache, NGINX, etc.).
          Click the Next button.

      5. Step 3: Confirm that you own the domain
          Choose the Approver emailfrom the drop down for the domain.
          Check the Same DCV for all domains box. This will ensure one email goes to the client to approve all three domain names.
          Select the same email Approver email address for the remaining domains.
          Click the Next button.

      6. Step 4: PostiveSSL Multi-Domain contacts
          Click the Next button.

      7. Step 5: Review & submit
          Review the TLS details to ensure they are correct.
          Click the Submit button.

      8. Copy and Paste the Certificate Authority's ID and Namecheap Order ID details along with the date into the Daylite Order/Install TLS Task.

      Submitting CSR for TLS - GeoTrust

      Geotrust TLS certificates are no longer used - refer to Name Cheap TLS Certificates instead.

      Step 1: Access GeoTrust's Vendor Portal

      1. Access GeoTrust's vendor portal via
      2. Enter user name artsman
      3. Enter password refer to Doug, Darwin or Dave for the password
      4. Click Log on

      Step 2: Place Order for Certificate - QuickSSL Premium Enrollment

      1. Click Order Certificates in the left side navigation bar.
      2. Click Place Order for the ACTIVE QuickSSL Premium contract.
      3. Validity Periods

        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.

      4. Renewal

        Select Initial Order or Renewal. If renewal is selected, they MUST BE renewing a previous TLS Certificate that was issued from GeoTrust.

      5. Competitive Replacement

        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.

      6. Special Instructions

        Leave this field empty.

      7. Click Continue
      8. Open up /Library/Apache2/bin/server.csr in BBedit.
      9. Enter CSR

        Copy the entire contents of server.csr file (including the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST tag lines) into Certificate Signing Request field.

      10. Click Continue
      11. Leave the Add Additional Domains field blank.

        Adding to this field will increase the cost of the TLS Certificate.

      12. Click Continue
      13. Verify Server URL

        Review information on the page for accuracy.

      14. Click Continue
      15. Site Administrator Contact Information

        Enter in Site Administrator contact information from the clients information as per instructions

      16. Technical Contact Information

        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

      17. Click Continue
      18. Approval of Your Certificate Request

        Select Approval Email address from the clients information as per instructions

      19. Click Continue
      20. Order Summary

        Review information on the page for accuracy.

      21. Check the box "I agree to this Subscriber Agreement" at the bottom of the page.
      22. Click Submit Order
      23. Inform the AMS Installer or the client contact that the TLS Certificate has been submitted and is now awaiting for their approval.

      Approving TLS for Creation

      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:
      1. Client (Site Administrator Email Address) will receive the 1st email from Comodo (orderprocessing@geotrust.com) indicating that the TLS Certificate has been submitted for creation.
      2. Client (Approval Email Address) will receive the 2nd email from Comodo asking for approval for TLS Certificate to be created at the specified authorization email address provided to approve the TLS Certificate.
      3. Client (Approval Email Address) will respond to 2nd email from Comodo approving the creation of the TLS Certificate by clicking on the acceptance link within that email.
      4. Upon approval from the client to create the TLS Certificate, Comodo will create the TLS Certificate.
      5. Client (Site Administrator Email Address) and Technical Contact (certificates@artsman.com) will receive the 3rd email from Comodo containing the actual TLS Certificate information.
        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.

      Creating CRT Certificate Files

      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.


      Step 1: Create the certificate CRT file

      1. From the Comodo Order confirmation email, move the .zip file to the desktop.
      2. Extract the .zip file.
      3. Open the two files in the extracted folder using BBEdit.
      4. Copy the entire contents of the .crt Web Server Certificate (including the BEGIN CERTIFICATE and END CERTIFICATE tags).
      5. Paste the content into an new BBedit document.
      6. Copy the first bundle in the .ca-bundle file (from the first BEGIN CERTIFICATE to the first END CERTIFICATE tag). Do not include the upside down question mark.
      7. Paste the content on a new line under the .crt.
      8. In BBedit, go to File >> Save As...

        Location: Desktop
        Filename: server.crt
        Line Breaks: Unix (LF)

      Installing TLS Certificate

      The pages below indicate the steps for installing the final TLS Certificate files.

      Installing TLS Certificate For Theatre Manager Server

      Placing the TLS Certificate.

      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.

      1. SMB to the certificates folder on smb://smb.west.artsman.com.
      2. Open the folder with the domain name matching the TLS Certificate.
      3. Create a new folder titled Replaced followed by the date. An example would be Replaced20210714.
      4. Drag and drop the content of the folder into the new replaced folder.
      5. Copy the TLS Certificate files created including the .csr, .key, .crt and .pem files into the certificate folder.

      Manually placing the TLS Certificate.

      1. Gain access to the Web Server computer. This will be the machine in the DMZ if a DMZ is present.
      2. Open the Theatre Manager Server in a browser by navigating to 127.0.0.1:3012
      3. Select the Configure tab at the top of the window.
      4. Scroll down to the Transport Layer Security (TLS) section of the page.
      5. Drag and drop the TLS Certificate .crt, .key and .pem files onto the highlighted section.
      6. Click Save at the bottom of the page.

      Testing TLS Certificate

      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.


      Alternate method using firefox: Testing the TLS Certificate

      1. Open the Firefox browser.
      2. Enter the full site address in the address bar.

        This would the https://tickets.yourvenue.com/TheatreManager/1/login&event=0.

      3. Click enter on the keyboard for the site to display.
      4. Click the lock next to the address in the address bar.

        This should be done after the site has finished loading. A box will appear indicating the status of the TLS Certificate.

      5. Click the More Information button. The Page Info window will open.

      6. Select the Security tab in the Page Info window.

      7. Click the View Certificate button. The Certificate Viewer will open to the general tab.

      8. Review the Issued On and Expiry Date in the Validity section of the viewer. If the TLS certificate has been installed correctly the date should be equal to the number of months purchased for the certificate

      9. Go to http://www.sslshopper.com/ssl-checker.html.
      10. Enter the domain the TLS certificate was created for (exp. tickets.myvenue.com).
      11. Review the details to ensure there are no broken red arrows in the chain files.

        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.

      Troubleshooting TLS Certificates

      TLS on Router

      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.

       

      TLS doesn't appear on HTTP

      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.

       

      The site can be accessed using https but not http

      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.

       

      Coding Practices

      Coding Styles/Methodology

      Encapsulation

      • Generally any specific SQL commands should be placed in PGSQLDAM or any other DAM that is being used. Avoid using direct SQL where possible. Exceptions can be made where performance is a concern.
      • Put most ‘work’ methods in the main table classes so that they are accessible from all parts of Theatre Manager (Windows, Web, Reports, Future Features). If a query/table class requires the functionality it should inherit from the main table class and add appropriate fields to do so. For example, a method that calculates subscription prices is stored in tF_SUBSCRIPTION because that is the database table that stores the subscription.

      Looping

      • The For list.$line to list.$linecount step 1 form is generally preferred for loops for the best blend of efficiency and readability. While…End While and Repeat…Until are slower and should only be used when required. In performance sensitive areas the construct below is preferred.

        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.

      • Any long running loops should be nominated for conversion or re-factoring into SQL stored procedures if they perform any database access.

        Method coding and placement

        • One should avoid, where possible, putting behavior code in events under objects on a window. It is preferred to have a public or private method in the window class that an event calls, rather then putting the code directly under an event. This allows for encapsulated functionality and allows the behavior to be called for other purposes. For example, a button that opens the patron window should have the same code whether it opens from a toolbar button, or a push button -- This would be located in $clickBtnOpenPatronWindow of the class and called from both the push button $event and the toolbar button $event.
        • Avoid writing code in window methods where possible. Window method code should only contain interface and interaction. If and code deals with database, the approach to be used is:
          • to put that code into a table class
          • invoke it from the window class by doing 'do list.$doMyMethod(parameters)'
        • A comment in all methods is essential. At the very least a comment section should include what the method is expected to do based on what inputs.
        • When altering existing code within a method, the developer should put a comment indicating what version the code was altered in as well as the initials of the developer altering it. E.g. ; V90000 DM (Version 9.00.00 [D]avid [M]cKeone)

        Parameter Passing

        • Throughout TM, the TMObjs.$makeparamrow() and TMObj.$loadparamvars() functions are used for passing parameters between objects. This method is favoured over passing individual parameters to a top-level class, especially when a large number of the parameters are optional. See wModeless.$construct for an example.
        • When over-riding any method:
          • always put the parameters in place that the superclass has:
            • in the same order (verify the order always)
            • document with the same parameter definitions
            • copy whatever documentation from the superclass and augment with why you are over-riding the class if it is not obvious
        • All parameters are to have an initial value specified for default case. 0, kTrue, Kfalse or #NULL is acceptable if no value is wanted

        Table Classes (SQL database)

        • All foreign key relationships should be in $buildChildRecordList of the appropriate main table class. E.g. All relationships for the F_CLIENT database table are in the tF_CLIENT table class.
        • All F_APPLICATION replaceable variables (indicated by a ‘g’ prefix). Should be specified in the $getReplacementSelectNames. Use $getReplacementSelectNames where possible:
          • To avoid setting values in the omnis list - for performance reasons
          • To add functions to replace gVars, especially where there may be multiple parent records to a relationship (eg sold by, changed by, printed by all connect to employee)
          • To obtain key customer data like Primary Phone, email address and other data that varies depending on the outlet (department) of the employee who is logged in. Example: the primary address for patron 1 made be different for outlet A and B
          • In reports so that there is limited record looping in the detail section of report (again for performance)
        • Any validation on a table should be done in $verifyRecord of the main table class for that database table.

        Tidying Up Code

        After completing code changes and final testing of any code class, always:
        • Remove unused variables from the Local variables
        • Remove unused variables from the Instance Variables. If a variable is not used in a superclass class, but is used in a number of subclasses, then in the superclass, in the construct, after the quit method, calculate the variable as itself so it will not show up as unreferenced.
        • Check the class variables and see if they are used and remove if not

        In Code Documentation

        Class Documentation

        The $construct or $initialize of a class there should be a block of code that is used to document the overall purpose of the class and any key directions to the developer.

        Method Documentation

        In each public method, the following standards are to be observed as per the example below:
        • a description for each parameter must be entered in the upper area
        • In the method, at the top, is a description of the purpose of the method
        • The parameters are repeated in text format as part of the method so that when a method is over-ridden, the parameter description will be copied into the over-ridden method.
        • If there is an expected return value, document those at the top of the method

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

        Schema Documentation

        Much of theatre manager's OO design has led to a very table driven application based on settings in the internal data dictionary. By following a few set-up steps as outlined below, many things in the application just start working for you with little or no effort. Examples are field tool-tips, column headers, alignment, visibility, formatting, etc.

        This is one of the most important setup steps when creating new data base fields.

        Schemas are to be documented in three places.

        File Class

        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.

        Schema Class

        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

        Data Dictionary

        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:

        • Criteria Name (medium length name of the field for help)
        • List Heading (short description of the field for the top of list columns wherever the field is used)
        • Description (the tool tip to be displayed for the user when they hover over the field on any window)
        • Usage flags for visibility and other options in Theatre Manager
        • Justification for columns in lists
        • Criteria level for use as a search field in reports and mail lists
        • Lookup table - if the field is an enumerated data type and the user is to select 'is one of' the values from the list
        • Search Sub Window which defines the sub window class to be used in list windows when this variable is used a search field

        Enumerated Type Documentation (codetables)

        All programmer defined enumerated types (internal tables) are to be defined in one central class called ‘oCodeTables’. An example definition is below where the fields used are from the code table file class:
        • FC_SEQ is the lookup number stored in a SEQ key in the database
        • FC_RESULT1_NAME is the description displayed to the user
        • FC_DEFAULT set to true for the item that is the default entry field

        Within the 'oCodetables' class, there are a number of getters that will load up any one of the tables into your object.

        Naming Conventions

        Class Naming Conventions

        Class Type Prefix Notes
        Code c
        • rarely used
        • Legacy exceptions for UpgradeRoutines and Common
        • specifically used as a broker between web sales GUI and remote tasks/objects
        File f or F
        • any new file classes start with 'f'.
        • Legacy File classes from Omnis Classes start with F_
        • pg for PostgreSQL system tables
        Menu m
        • Legacy exceptions for STARTUP
        Object o
        • Web listener objects: oWebCom
          Asynchronous objects: oAsync
        • (Exception for Database DAM’s, which must be named the same as the DAM they inherit from.  E.g. PGSQLDAM, FRONTBASEDAM)
        Query* q
        • Reports query classes: qr
        Remote Task rt  
        Report r  
        Schema s
        • Generally same as the File class it is based on, just prefixed by 's'
        Table* t
        • Reports table classes: tr
        Task none
        • there is only one real task in theatre Manager that must be called 'Startup_Task'
        Toolbar T_  
        Window w
        • Modal message windows: wMsg
        • Windows used for Sub-Window toolbars: ST_
        • Sub-windows used as part of a large complex window should be prefixed with the name of the large window they are part of.  Examples are wReportParam, wSell, wSearchSubWindow, wClient.
        • Windows should end in the suffix 'Detail' or 'List' and follow a similar naming convention to the table class they are based on if they are the standard detail or list window for any given table class. e.g The list and detail window for tfResources is wResourceList and wResource Detail. The list and detail window for tfResourceLink is wResourceLinkList and wResourceLinkDetail.

        *Query class names should match the corresponding table class. E.g. tClient and qClient.

        Data Dictionary

        • All file classes (database tables) used for the Theatre Manager database must be assigned a unique prefix in the Data Dictionary. For example, F_CLIENT uses C_, F_PLAYSEATS uses PS_. There are several essential parts of Theatre Manager that rely on this naming convention for automatic foreign key determination.
        • All primary key records are named with the prefix for the file class (database table) followed by SEQ. The primary key for F_CLIENT (C) is C_SEQ.
        • All foreign key records require the use of the unique prefix within the name, as well as the suffix _SEQ. For example the F_CLIENT (C) foreign key on the F_PLAYSEATS (PS) record is PS_C_SEQ.
        • If the user should not ever see a column, then it should be marked as internal. It is not required to enter a description for internal fields.

        Method Naming Conventions

        • Methods are named with camel case beginning with a lower-case letter. E.g. $myMethod
        • A method used for a button behavior should begin with $clickBtn. E.g. $clickBtnBuyTicket
        • getter methods should start with $get (eg $getCurrentColour)
        • setter methods should start with $set (eg $setCurrentColour)
        • group similar function methods under a dummy header method with a name that starts with some ---- eg '---- Window Open Methods ----'

        Variable Naming Conventions

        All variables should be named using camel case rather than hyphens or underscores. E.g myVariable or MyVariable instead of MY_VARIABLE.

        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
        • Developer preference
        • prefer prefixing with k.  E.g. kNameOfFile
        • Scope left to developer preference

        Proctected Classes

        The following classes are under the protection of the Arts Management Systems Architects. Prior to deployment, the Senior Architect must review any changes made to these classes an developer are to make the architects aware of changes.

        The architects will monitor the VCS activity on these classes by running checkin/checkout reports for any violations of this policy.

        Credit Card Processing

        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

        External Components

        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.

        Superclass objects

        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

        Web Listener Objects

        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

        Sensitive information in Code

        Sometimes passwords or credit card data and other such sensitive data needs to be stored inside the application or on the database. In all such cases, the data shall never be stored in plain text – it shall always be encrypted.
        • When the sensitive data is stored in the database (like user ids for logging in, or credit card numbers), it will use high encryption such as AES256 or better. Any seeds or salted keys will also be encrypted using some such mechanism and stored as a static variable inside the database or application.
        • Any data to be transmitted from one machine to another:
          • shall use the most recent high encryption transport technology (currently TLS 1.2 or 1.3) and
          • shall not use any encryption found to have been compromised (SSL1 through TLS1.1 etc)
        • Any key, user id, or encryption salt that must, by necessity, be stored in the application shall also be encrypted as a static variable and decrypted before use during each run of the application and/or of that method so that keys rarely exist even in memory in unencrypted form.
        • Any un-encrypted key should be in local variables so that they are destructed automatically at the end of the method. This constant decryption and discarding of keys, salts, logins, and credit card data should minimize the possibility that it may exist in real memory, or even in virtual memory
        • Never use real credit cards to test credit card processes in the test environment. Use the supplied test cards and accounts that are provided by the test merchants.

        Upgrade Methodology

        All upgrade routines should be placed in the UpgradeRoutines code class.
        • Each version has a Steps and Update method.
          • E.g. For version 8.24.xx there are methods called “Steps 8.24.xx” and “Update 8.24.xx”.
          • It is expected that each upgrade performed in Update has a matching step in Steps.
        • There is also a method called 'versionUpdates' that adds the update step to a list. This must be set for the upgrade to be invoked
        • All changes to the file fSystemPreferences must be made in 'addSystemPreferencesFields' as these particular fields are sensitive and must be set up prior to login or creating other upgrade steps
        • All other new fields or tables are established in 'addAllNewDBFields' which is done before any of the update steps are run. This ensures the database consistency before any steps begin

          Vulnerability Awareness/Training

          Recognizing that Theatre Manager is a point of sale system that manages sensitive information that includes credit card data, it is important that the developers keep abreast of new and developing threats. The following sources are examples of web sites that developers are expected to read periodically and share any findings with the rest of the teams.

          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.

          Quarterly, review the PCI documentation web site for any new or revised versions of PCI PA-DSS documentation and assess whether current or proposed changes merit implementation before the next review.

          • postgresql Always check for the current production version of postgres and see if there is a new release. Releases typically are about once per quarter. When there is a new version, then make sure to read the release notes to see if there are
            • bug fixes beneficial to Arts Management
            • and fix that specifies some security vulnerability
            • Developers are always expected to be at the latest release for testing
          • Nginx. The web server processes are dependant upon Nginx and PCI compliance scans generally identify old or outdated versions of Nginx. Check monthly to see if there are any new stable releases available. We do not use Alpha or Beta releases of Nginx, only mainline releases.
          • Omnis Studio Check for an new releases or patches to the devlopment tool. Of special interest are bug fixes and/or any release that implements additional security in other areas like TLS, etc.
          • macnn is a newsnet style mac based web site. It can usually be relied upon to report both mac and PC news (especially if it is negative)
          • Credit Card processors such as
          • OWASP - to review emerging internet vulnerabilities at least semi annually.
          • per PCI requirement 2.2, periodically check NIST for reported security vulnerabilities and record pertinent ones in the vulnerability assessment for each component we use.

          Data Importing

          Data Review

          Before you start anything

          • Do not just dive in and start cleaning up data at the first file you see.
          • Make sure you have all the 'current' data that will be used for importing.
          • Review ALL the files for completeness and record counts.
          • If there is 5,000 donations, and 90,000 patrons, verify with the client that this is the approximate number of records they are expecting. Perhaps their export process was incomplete and there should be 50,000 donations.
          • Double check that you have all the starting information that you need to move forward and all of the initial questions answered. Nothing is worse then moving forward on what you think is best, only to find out later that you assessment was incorrect and you need to start over.
          • Do not go into a cleanup and preparation process and start deleting any data or columns that you do not know what they mean. Even if they contain 'junk' data. That 'junk' data may turn out later to be a key index field that could be the primary link to 'this' file, or to 'another' file.
          • If they provided 'sample' data, compare the files that they sent in the sample to the 'final' set of files. Did they resent the 'sample' files too. If so, great. If not, where are they and why not?

          What to look for

          • When you start reviewing all the files the first thing to look for is a 'key link' or a column of data that 'links' this record to any other records. Once you find the 'key link' to each file, the record connections and how the data relates to each other will become clear.

          Create New Database

          Creating a new database for a new client:
          1. Download the most recent "empty" database
          2. Restore the downloaded "empty" database
          3. Configure "TheatreManagerServer" to:
            • Database name: "empty"
            • Web Listeners: 1
            • Classic Web Listeners: 0
            • Housekeepers: 1
          4. Using the Theatre Manager application, log into the "empty" database.
          5. Setup >> Company Preferences >> Reports/Misc tab >> Set Maintenance Jobs to run from 8:00am - 5:00pm.
          6. Restart the "TheatreManagerServer" processes to read in the new Company Preferences settings.
          7. Setup >> Batch Functions >> Worker Jobs - Verify all jobs have completed successfully.
          8. Setup >> Company Preferences >> Reports/Misc tab >> Set Maintenance Jobs to run from 1:00am - 5:00am.
          9. Set the System Preferences
            • Appearance - Canadian/USA spellings and descriptions (State/PST, Federal/GST/HST)
            • Licence - Set the DB User Suffix
            • Licence - Set the initial Customer License number
          10. Set the Company Preferences
            • Company - set default contact company information (reference Daylite)
            • Accounting - set general accounting information (Fiscal Year, Start Month, Store Year Start/End)
            • Director - set Web Server URL and Custom Template URL for their web sales site. NOTE: make sure there is https:// in the URL when using port 443
            • Donations - in the Donation Comments, replace with client's organization. Set Government Website.
              • Canada: canada.ca/charities-giving
              • USA: irs.gov/eo
            • Appearance - set the Canadian/USA spellings (Color, Zip Code, State, Medic/Behavior, Social Security, Hair Color, Eye Color, Theatre, Venue)
            • Reports/Misc - visit the client's existing website to gather icons and information for: TicketTrove icon, company overview, logo for reports (reference client's website), set Time Zone.
          11. Set Invoice Comments
            • Replace with client's organization in 2 places
            • Canadian/USA spellings for cheque/check
          12. Set Code Tables
            • Country - set the default country
            • Province/State - set the default Province/State
            • Payment Methods - Canadian/USA spelling for cheque/check
          13. Merchant Account
          14. Patron Account's
            • Update the Master User and Web Listener patrons to be in the correct city/province with company name
          15. Rest Database Date and Time Stamps
            • Resets the data and time stamps on existing database records to the current date.
            • Purges any transactions in the database.
            • Prepares the database to make it appear like a first time use.
            • File >> Import/Export >> Company Settings >> Outlet Management >> Timestamps button

          Create New Outlets

          Creating a new outlet within an existing database:
          1. Download the most recent "client" database
          2. Restore the downloaded "client" database
          3. Log into the "client" database as the Master User
          4. Set the System Preferences
            • Licence - Update the Customer License number to include the Outlet Module
            • This process will automatically log you out of the database.
          5. If required, update the Daylite company profile with the new customer number (both primary and new outlet)
          6. Log into the "client" database as the Master User
          7. Using the Developer Tool for License Number creation, increase the 'Number of Department Licenses'
          8. If required, update the Daylite company profile with the new number of user licenses
          9. Create New Outlet (Setup >> Outlet Preferences)
          10. Initialize New Outlet with Values based on Existing Outlet (File >> Import/Export >> Outlet Settings >> Outlet Management >> Create Initial Outlet Settings). These will duplicate/create values based on the existing outlet's data. This is an OPTIONAL step, but it will save you a bunch of setup work if the values will be similar for the new outlet. The process will ask you if you wish to duplicate each section before it will duplicate the data.
            • Tax Rates
            • Code Tables
            • Ticket Faces
            • Chart of Accounts
            • Fee Types
            • Invoice Comments
          11. Create New Merchant Account (Setup >> System Tables >> Merchant Accounts) and assign it to the New Outlet. You can also duplicate an existing merchant account and assign it to the New Outlet. Note: This step needs to be completed BEFORE you will be able to create employees for the new outlet.
          12. Create New Marketing Records for New Outlet. When the new outlet was created, it created a job listing. These jobs need to be run via Setup >> Batch Functions >> Worker Jobs. Note: This step will take a while to complete and needs to be completed BEFORE you will be able to create employees for the new outlet.
          13. Create New Patron for Outlet Administrator (New Outlet)
            • First Name: {Outlet Name}
            • Last Name: Admin
            • Company: {Outlet Name}
            • Title: Outlet Administrator
            • Work Address: Do Not Mail
            • Work Phone: {Outlet Phone}
            • Marketing Flags: Do Not Mail, Email, and Delete
          14. Set Patron as Employee for Outlet Administrator (New Outlet)
            • Outlet Administrator: Yes
            • Access ID: admin_{Outlet Name}
            • Employee Initials: ADM{outlet#}
            • Initial Window: Patron Window
            • Transaction Source: Box Office
            • Merchant #: {Outlet Merchant Created Above}
            • Set Login Password
          15. Create New Patron for Web Services (New Outlet)
            • First Name: {Outlet Name}
            • Last Name: Web
            • Company: {Outlet Name}
            • Title: Web Services
            • Work Address: Do Not Mail
            • Work Phone: {Outlet Phone}
            • Work Email: tickets@{outlet email domain}
            • Marketing Flags: Do Not Mail, Email, and Delete
          16. Set Patron as Employee for Web Services (New Outlet)
            • Outlet Administrator: No
            • Access ID: web_{Outlet Name}
            • Employee Initials: WEB{outlet#}
            • Initial Window: Web Sales
            • Transaction Source: Internet Sales
            • Merchant #: {Outlet Merchant Created Above}
            • Set Login Password
          17. Update Existing Master User Patron for System Administrator
            • First Name: System
            • Last Name: Admin
            • Company: {Primary Outlet Name}
            • Title: System Administrator
            • Work Address: Do Not Mail
            • Work Phone: {Outlet Phone}
            • Marketing Flags: Do Not Mail, Email, and Delete
          18. Update Existing Master User Employee Account
            • Access ID: admin_system
            • Employee Initials: ADMS
            • Initial Window: Patron Window
            • Transaction Source: Box Office
          19. Using the Menu options, duplicate existing data for new outlet for:
            • Invoice Comments - only if you didn't duplicate them already or created the default set of comments
            • Sales Promotions (or have client start creating new Sales Promotions as they need them)
          20. Using the Menu options, export any existing data applicable for the new outlet:
            • Venue Maps
            • Venue Pricing Maps
            • Venue Pricing Map Seat Names
          21. Log out of database
          22. Log into database as the Outlet Administrator for the New Outlet
          23. Review Code Tables to assign 'default' values (Setup >> System Tables >> Code Tables >> Set Default button in toolbar)
          24. Using Developer Tools, remove any duplicate existing data for new outlet for:
            • Code Tables >> Facility Project Types
            • Code Tables >> Folder Names
          25. Using Menu options, Import any applicable data for:
            • Ticket Faces
            • Venue Maps
            • Venue Pricing Maps
            • Venue Pricing Map Seat Names
          26. Set default Sales Promotion (Setup >> Sales Promotion >> Set button in toolbar)
          27. Update Outlet Preferences
            • Ticket Faces >> Address Ticket
            • Ticket Faces >> Receipt Ticket
            • Web Options >> Enable Web Sales
            • Web Listener >> Set Employee ID for web sales
            • Appearance >> Volunteer fields #1, #2, #3, #4 (Hair Colour, Eye Colour, Vocal Range, Instrument)
            • Appearance >> Volunteer Flags #1, #2, #3, #4 (Dance, Sing, Act, Play Instrument)
            • Box Office >> Why did Patron Buy (for quick cash sales)
          28. Assign any existing employees who need access to the New Outlet as Employees of the New Outlet (Outlet Administrators or Normal)

          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

          Employee Information

          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

          Venue Maps

          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 Accounts

          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)

          • 1, Asset
          • 2, Liability
          • 3, Equity, Capital
          • 4, Income, Revenue
          • 5, Cost of Goods
          • 6, Expenses
          • 8, Other Income, Other Revenue
          • 9. Other Expenses

          Account Setting (CA_POSTING)

          • 0 = Detail - default value for new records
          • 1 = Posting

          Reporting Level (CA_LEVEL)

          • 1 = default value for new records
          • 2
          • 3
          • 4

          Unless specified, the External Account Number will default to the Account Number

          Events and Performances

          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:

          • Column A = Season Year
          • Column B = Event Title
          • Column C = Event Number (calculated by the following)
          • =IF(B2=