Version 8.00

Version 8.00

Version 8 is a significant upgrade with over 50 new features. Many changes relate to 'under the hood' performance along with enhancements to various parts of Theatre Manager based on feedback from users.

From the users perspective, version 8 looks and functions the same as version 7. There are additional buttons in various places to extend functionality. Users familiar with version 7 should not need training on version 8.

Version 8 will be installed by the Arts Man Support team using remote access. It is free to all venues who have a current active support agreement. Upgrades will occur during normal support hours on dark days. For those on after hours support, evening upgrade time slots may be arranged.

April 2009

Key changes:

  • Version 8 is certified PABP compliant and listed as an approved application on Visa's web site. While version 7.36 is also compliant - we chose to have an external auditor (Security Metrics) officially submit version 8 for PABP/PCI compliance.
  • Contains a number of under-the-hood changes that move processing from the workstation to the server. In our lab test cases, performance improvements in some areas ranged from 2x as fast to 10 times as fast.
  • Coupon codes can now be redeemed on the web
  • The apache module comes with a new statistics and performance monitoring tool
  • Window positions are now remembered between sessions on a per user basis
  • Window and list positions are remembered between sessions for each user.
  • More tools were implemented to manage end of day process.
  • TM preferences have been altered from per machine to per user basis. This supports a greater range of options in a terminal services implementation.
  • TM web settings support placement of web listeners in a greater range of network configurations, including a DMZ and/or multiple listeners per machine under fast user switching or terminal services.

There are mandatory web change for this version and a new Apache Loadable module must be installed. For this version, it will be done by Arts Management Support team.

Preparing for the Update

Theatre Manager requires all three key components updated. This will be performed by the Arts Management support staff via existing remote access tools (Timbuktu, Logmein or RDC). Each venue needs to coordinate an upgrade slot with the support team. The following key activities are done as part of the upgrade:

  • Postgres Database:
    • The postgres database must be upgraded to the latest released version (currently version 8.3.7). For sites that are at version 8.3 (any version), this takes about 5 minutes or less. For sites at version 8.2 (any version), the database needs to be backed up and restored (could take as much as a couple of hours).
    • Postgres can be upgraded at any time in advance of installing version 8 because it works with both version 7 and 8.
    • Venues wishing to attempt this themselves can follow these instructions.
  • Apache Web Server
    • The apache web pages may need some conversion from version 7 to version 8. Most changes are minor (and required to support the new apache module). A venue will need to provide the web pages which the support team will compare to the current standard pages and return - ready to implement
    • The apache web server will be upgraded to version 2.2.11 (the latest shipping version)
    • This upgrade can be be installed at any time in advance of installing version 8 of Theatre Manager. These changes will work with both version 7 and 8
  • Theatre Manager
    • Theatre Manager version 8 will need to be installed on each workstation.
    • The upgrade will convert the database
    • This upgrade is the last step in the upgrade process.

The venue will need to

  • Coordinate a time with the support team regarding the upgrade and provide the existing web pages.
  • If you have an onsite training session coming up, this will be when the upgrade occurs unless there is some feature that is absolutely necessary.
Before upgrade
After Upgrade
  • This upgrade requires that you install Theatre Manager version 8 on each machine
  • Do the install after your database has been upgraded by the Arts Management Support team
  • Verify your web sales pages are as you like them by testing them
Optional Steps
  • If you choose to implement PABP/PCI user ids, follow these instructions
  • Examine Company Preferences for any changes that you want to make to the settings for Theatre Manager. e.g.
    • For web logs, decide if you also want them saved to each listener (recommended).
    • Set the default message log level setting for each listener.
    • Adjust the preferences for how long you want to keep web logs
    • Set the preference for reservation only (recommended to disallow it)
    • Set the preference for end of day deposit reports
    • Set the preference for accepting coupon codes on the web (and set up coupons if desired)
  • Examine System Preferences
    • Look at setting for credit card retention. Recommend that the setting is 365 days (or longer).
    • Run the shred process for any cards older than you want to retain
    • Run the process that re-encrypts your credit cards with a new-randomized key after shredding the existing cards you no longer want.
Time Required
  • Approximately 4 hours from version 7. The actual time depends on:
    • the size of the database if a dump is needed
    • the number of transactions in the database
    • the performance and memory in the server
  • Venues on after hours support can schedule evening conversion. Venues on regular support will need to set aside a dark day.

8.00 Changes & Enhancements

Version 8 consists of many hundreds of little changes through out Theatre Manager. Some are major and are listed below. Most were under the hood tweaks for performance and added convenience in a number of areas. They are too numerous to mention them all, so this document focuses on the key ones.

Performance

Some code in Theatre Manager has been moved from the application into the server using more stored procedures. That generally improves performance of applications and this is true in Theatre Manager. We did this in a number of areas to try to take out seconds, or even milliseconds of time and improve response. The table below shows some sample improvements that we have experienced on our test suite of machines. Venues that are currently using version 8 have told us that it seems faster, so, anecdotally, the improvement is noticeable.

The improvement that each venue achieves is dependant entirely on the postgres server machine and is affected by things like: memory, striping of hard drives and speed (number of CPU's). Sample performance improvements are listed below (note that they are not cumulative, just indicative of areas where we focused on performance):

Window or function After Improvement
email blasts Does one ping at the start of the process (and each time there is an interruption longer than a minute). We also adjusted memory management about 3 times faster on small batches. Much faster on large batches of emails. The standard test suite now allows 4000-5000 emails to be sent per hour from the merge process
record inserts revised the methodology of generating new keys 10-15% improvement inserting new records in all aspects of Theatre Manager
Open Sales window Optimized the reading of records window opens about 10% faster
selling individual tickets There is a minor change to selling one ticket by clicking on it and then clicking on another small, not generally appreciable
selling block of tickets when selecting multiple tickets and booking at one time, the process goes much faster. selling between 10 and 80 tickets at one time - speed improvement was as much as 3 times faster. Example selling 83 tickets took 30 seconds. It now takes less than 10 seconds.
Selling any ticket server contention and record locking has been optimized any number of users may now sell large blocks of tickets simultaneously without any record locking happening. We have noticed that each ticket workstation in a large venue now receives the same response time from the server (on average)
End of Day Posting Some work that used to be done during end of day to post to daily statistics is now done during the ticket sale even though the ticket sale is 3 times faster, this change also improved end of day posting by a factor of 2 to 2.5 times. Posting 280 transactions is about 2 time faster.
Refunding tickets   refunding tickets and creation of transactions is now about 1.5 times faster
Entering donations the allocation of payments and creation of transactions was optimized entering a new donation is about 2 times faster.
Finding Patrons and other records The actual performance of finding records has not changed. We optimized this display of the records on the work stations. displaying a moderate number of patron, orders, shopping carts and such is as much as 10 times faster. Retrieving them from the database takes the same amount of time - the display is much faster because work is now done on the server.
Postgres optimizations a number of indexes were removed from fields that are heavily updated to take advantage of a feature in postgres version 8.3 In general, this optimization results in about a 30% improvement in record I/O a the server on a properly tuned system.

General Interface Changes

There were changes to the general behavior of Theatre Manager in response to requests we had from people. Many of these are subtle such as:

  • When you close and window and re-open that same window, Theatre Manager remembers its size, its position, the search field that was used and the position of all sub windows and list columns within that window. For example, if you change the columns on the ticket sell window as well as re-adjust the height of various lists, the next time the sell window is opened, it will open to the same place, with all lists in the same position as before. You do not have to save the position.
  • The saving of window placement is per user (each user has their own preferences) and per monitor (if a user goes from one machine to another and the monitors are different sizes, then Theatre Manager will save a preference for each monitor size)
  • If a person has multiple monitors, windows can be placed on the secondary monitors and will open on the secondary screen.
  • If a user removes or turns of a secondary monitor, Theatre Manager will bring the open window back on screen.
  • Window placement is saved between sessions so that if you logoff and then start Theatre Manager later, windows will open in the same place.
  • Toolbar buttons now work in all cases. A key bug was fixed where clicking the button on the toolbar did not always cause the button to be pressed.
  • Active and Inactive flags have been added to a number of tables (theatre maps, promotions, events, ticket faces, donations, gift certificates, accounts, mail lists, etc). Lists now exclude inactive items by default (although you can search for them). Venues can pare down the size of visible lists as desired.
  • The 'print' icon on all list windows will now display at least two options: a built in report, or the ability to print the list exactly as viewed. This way, if you customize any list, you can print it as viewed and get a report.
  • More legends have been placed on lists to explain colours or icons in the lists as an assist (see screen shot below - at bottom)
  • All lists are now alternate striped on each line in accordance with the Leopard interface guidelines. This is for clarity in viewing across a list. An example is shown below. (OS-X only - It is not currently available in XP or Vista due to interface guidelines for Microsoft).
listWindow

Patron Window

There were a few minor changes to the patron window to add some functions requested by users.

email LinkOn the patron window where the email addresses and phone numbers are displayed, you can now:

  • add a primary fax number in addition to a primary phone number
  • add a primary web site
  • click on the link for the email address which will open your email client - ready to send an email to the patron

There is an optional field for each patron that we called an 'external search field'. If enabled, you can specify a key that can be used to find the patron. Suggested uses for this field might be a student/faculty number or a number that relates a Theatre Manager patron to an external system.

There is a new feature on the address list and patron card detail window that allows you to:

  • copy the address to the clipboard
  • display a map of the address in a browser, or
  • show the weather forecast at the users address if they are out of town

The ticket and order window now has a legend on it indicating if the order contains reservation only tickets, as well as if you owe money to the patron or the patron owes money to you. Ticket window now displays order notes.

From the ticket window, you can now select some of the tickets and then 'print a map' showing a picture of the seats where the patron is sitting.

Company Preferences

There are a number of minor changes on this window:

  • You can completely prevent reservation only orders from being taken by turning on a new preference
  • There are preference for purging logs and data specific to:
    • Completed shopping carts (default is to keep those for 1000 days)
    • purging anonymous shopping cart logs (default is to keep for 180 days)
    • purging other web startup logs and miscellaneous information like calculation errors (default is to keep for 60 days)
  • Before event sales has a preference to set the default 'why did patron buy'. This allows 'why did patron buy' to be mandatory for all sales, yet provide a suitable default for walk up sales. This should improve the value of this field
  • Web Sales now supports a default mail fee and works in conjunction with the new web pages. Setting this fee in default data automatically makes the optional mailing fee appear on the web pages. Removing it and it is removed from the web site. It means that you can change mail fees at will without web page changes.
  • The web listener can gather and store the apache statistics (see end of document) in the database. The default is to sample them each hour so that you have 24 snapshots on each day of what the load on the web site is - and look back over time.
  • You can implement multiple web listeners through a DMZ to an apache server to support complete PCI compliance at your venue.
  • The titles for 'regular' and 'season' tickets are now customizable throughout Theatre Manager. The special meaning of these ticket types have remained the same - but the names can now be changed.
  • A feature added in version 7 for mandatory zip codes now has defaults for regular sales, before event sales and pay what you can sales mode. These were implemented so that you can still use quick cash under all sales modes for a faster sale.

Accounting

  • A minor, but significant change has been made for the recording of donations allocated to a 'reserved' bank account.
    • Previously, Theatre Manager created a G/L entry to take the money out of the bank account right away. Now the system creates a GL entry to create a 'payable' clearing account - meaning that all funds are accumulated into a separate account that you will need to clear periodically
    • Donations that are changed to/from a reserved account had to be manually tracked before. Theatre Manager now creates a G/L entry to tell accounting to move the current value of payments against that donation (to date) to/from the restricted back account.
  • Entering account numbers no longer crashes a PC
  • Entering account numbers and backspacing no longer skips every second digit of the account number

Credit Cards

  • You can no longer enter a new credit card for a patron that already exists for that patron.
  • Old Credit cards can be 'shredded' on the patron window based on settings in system preferences (i.e. there is a minimum retention period so that recent cards are kept and old ones can be rendered un-readable).
  • Shredding a card like 4500 1234 4567 9012 means that it will not longer be stored in the database in encrypted (non-readable) format. Instead, it will be stored with only the first and last 4 digits of the card (the rest are removed). Such credit cards will be marked as 'inactive' and will not show up in lists. They cannot be edited either. Taking the same card number as part of a payment will re-activate a shredded card because the patron used it again.
  • There is a feature to mark credit cards as 'permanent'. These cards will not be shredded
  • From the 'System Preferences' window, you can shred a mass of old credit cards - ones that are no longer being used. We suggest a retention period of 1 year to handle ongoing year to year transactions. Use a retention period of 90 days at a minimum to handle charge back situations. This means that most of your cards in the system will be rendered useless. However:
    • You can still find a patron by a shredded card because TM will look for only first 4 and last 4 digits of the card.
    • Any card used for post dated payments that have not yet been paid cannot be shredded
    • Any card used for season auto-renewals cannot be shredded because the patron gave explicit permission to use the card
    • Any card marked as permanent will not be shredded
    • Any card that is taken today and not yet deposited cannot be shredded.
  • There is a feature to indicate that cards are to be shredded right away and not retained in Theatre Manager. This feature means that card information is stored temporarily(encrypted format) and completely shredded when the deposit occurs. This is essentially 'schedule C' compliance as far as TM is concerned. We do not recommend this mode (we prefer at least 90 days before shredding), but it can be used if desired. If cards are to be shredded daily, the following occurs:
    • post dated payments can only be 'checks'. Credit cards are no longer permitted
    • Subscription auto-renewals cannot be entered any more because cards cannot be stored
    • Credit cards marked as permanent are shredded anyway.
    • Credit cards are shredded after each successful credit card settlement
    • Credit cards are marked inactive after their use
    • Any reports with credit cards on them are marked as *** *** *** #### regardless of user level. Nobody can see the full card information because it isn't there anymore.

End of Day

  • A new setting was added to Company Preferences (End of Day tab) to allow you to set the preferences for the 3 end of day deposit reports you would like to have. These preferences are used on the End of Day window so that daily reports can be consistent.
  • Anything relating to version 6 transition to version 7 has been removed
  • Patron orders can be edited or rebuild from the A/R tab
  • You can now got to the patron record directly from the A/R tab in order to address A/R issues. When the patron window closes, the outstanding A/R will be recalculated.
  • A fix was made to the end of day posting to address the odd occasion when Theatre Manager said a transaction was open after posting to the G/L in the end of day.
  • The End of Day wizard does a stricter job of calculating the 'difference' when windows are opened and closed to assist the EOD process
  • End of Day will purge shopping cart information based on settings in system preferences
  • End of Day posting process is about 2 to 3 times faster (depending on hardware).

Employees

  • During the upgrade, each 'normal' users access to credit card information will be restricted to be more in line with the general PABP recommendations. This is a one time setting and you can go back and reset any credit card access permissions you want.
  • Changing a user from master user access to normal access automatically removes all credit card view access. This is to provide the tightest security settings against credit card access. Settings may be changed afterwards to grant more access than the minimal PABP settings.
  • There are additional settings to control access to
    • the new web features
    • all credit card information
    • the various subscription components like manage favorite seats, creating packages, and selling packages
    • access to the various payment tabs on the payment window such as post dated and the contractual tabs.
  • Cash drawer support has been added for PC's to automatically open electronic drawers that support the appropriate signal to a com port. This is reset to <none> on upgrade.

Season Subscriptions

  • The subscription sales process has had a minor, but significant revision. When selling a subscription after a subscription performance is over (e.g. show 1 is done), Theatre Manager assumes that you are renewing a 'short season' and will calculate the price of the subscription renewal (or new subscription) based on the price of the remaining shows in the package. You no longer have to remove an event from the package to do renewals.
  • Renewal notices have had two significant changes:
    • When printing a renewal notice after a subscription performance is over (e.g. show 1 is done and only shows 2 to 5 are left), Theatre Manager will ignore that first event and print a renewal notice with the cost calculated for the remaining events. This is to support the process of creating new subscriptions after a 'try 1-buy the rest' process
    • During the printing of the renewal notices, if Theatre Manager cannot get access all performances in the series, it will now mark the subscription in error. This is to prevent erroneous notices from ever being created if one of the events in the package is missing a series code like 1-FRI or OPENING.

Donations

  • A G/L tab was added to the donation campaign setup so that you can view all postings to that donation campaign
  • The giving level setup has been broken into 3 tabs. This now shows the level, the benefits, and a more complete detail of the statistics of donations against that giving level (totals, averages, soft credits, gifts, pledges, etc).
  • To repeat information from accounting, a minor, but significant change has been made for the recording of donations allocated to a 'reserved' bank account.
    • Previously, Theatre Manager created a G/L entry to take the money out of the bank account right away. Now the system creates a GL entry to create a 'payable' clearing account - meaning that all funds are accumulated into a separate account that you will need to clear periodically
    • Donations that are changed to/from a reserved account had to be manually tracked before. Theatre Manager now creates a G/L entry to tell accounting to move the current value of payments against that donation (to date) to/from the restricted back account.
  • A transaction tab has been added to the donation window so that you can see all accounting entries relating to the specific donation
  • The payment process for a donation has been altered to better allocate payments to orders that include donations, tickets, gift certificates, and/or order fees. This allocation will deal with situations where money was refunded on donations and donation receipts deleted in a nicer way
  • You can easily delete donations that have receipts, but where the receipt is not printed. YOu no longer have to go delete the receipt, then the payment, then the donation.

Gift Certificates/Passes

  • A G/L tab was added to the gift certificate setup to make it easier for reconciliation
  • A transaction tab was added to the gift certificate entry window that contains a complete accounting history on that gift certificate/pass

Mail List

  • A zip code count report was added to the mail list window.
  • Search for text fields that 'end with' now works.

Merchant Accounts/Authorization

  • This same feature is automatically performed on start up of Theatre Manager so that users are notified when the database is approaching proper size.

Reports

  • Invoices now have a logo on them
  • Entering search criteria now displays 'long' names for comparison operations. Theatre Manager used to display '=' or '<>' or '>='. It now displays the operator in words like 'equals', 'not equals', or 'greater than or equal to'. Enough users indicated that the mathematical operators caused them to stop and think - so we changed it to plain english.
  • A new feature has been added to reports to toggle the report display between a 'page preview' and the current report format. The default is set in employee preferences - and is set to the new 'page preview' mode for all users. Existing all existing features like print to PDF, copy highlighted report text still work. The subtle differences between modes are:
    • current format
      • text displays approximately 2/3 size and is fixed in size
      • scrolling also scrolls the titles and the entire report
      • pagination is shown as a fine line
    • page preview (now the default view).
      • a paper background is displayed behind the report so that you get a visual sense of how the report prints
      • a complete page is always shown in the onscreen report
      • the titles on a page preview remain static - so as you scroll through the report, the titles stay at one place on the screen
      • resizing the window - resizes the report area.
      • any indenting of reports (subscription notices for example) are reflected more truly in this mode.
  • The filters for field names and values in lists are now at the top of the criteria entry window instead of at the bottom.
  • All search fields have been categorized as 'Essential', 'Frequently Used', and 'All Criteria'. There are fewer fields in the 'essential' category, typically fields like lookup fields. This should limit the search fields to a much smaller subset for users new to Theatre Manager - to make reporting and mail list building for novices easier. This setting can be set as a default on Employee Preferences on a per user basis. An example of essential fields is below

Essential

  • The ability to enter a custom report title has returned for each report
  • The A/R allocation reports now place all receivables at the end of the report.
  • On the toolbar is a button called 'Run Similar Reports'. This now shows a wider range of reports that can be picked. After running you main report, you can change the format easily.
  • Column widths on dynamic reports are more liberal. each column takes as much width at is required for the total at the bottom of the report for that column. If you have more fields on a report, it may cause columns to go onto a second page in order to preserve the column widths.
  • Merging of form letters has been removed from the report window. We found that the easy way to explain a form letter merge/email blast is to edit the letter and click the merge button. That seemed a much more intuitive approach to users during training and so we made it the only way it could occur.
  • The record count reports have been restored so that you can count and subtotal by many fields
  • The record count reports also allow you to do distance metrics from any zip or postal code for most types of data in the system in a customizable way. The example below shows the total ticket sales for one performance (that was the criteria chosen). The sales are broken into quantity and total sales by state, by distance from the venue. This can be done for donations and an number of other records - to get an idea of drawing area or how far people will travel for certain types of shows.

distancefromtheatre

  • There is an new report called 'Ticket Purchase Times' in the 'Box Office Statistics' category. This can be used to display when people are buying tickets during the day. The report supports displaying ticket quantities, total number of transactions, amounts for a range of hours during the day. You can only place 40 columns on a report, so showing price and ticket quantity could be done for an 18 hour period in any day (because there is before the selected time and after the selected time columns). An example is below.

ticketPurchaseTimes

Coupon Codes

Theatre now supports redemption of coupon codes on the web. There are three pre-conditions to accepting them:

  • Each coupon code that should be accepted on the web needs to be flagged to be accepted on the web
  • There is a setting in 'Company Preferences' on the 'Web Options' tab called 'Accept Active Coupons'. That must be turned on to enable coupon codes on the web. Turning it off is a quick way of disabling acceptance of coupons on the web instantly
  • Some web page changes will need to be made (part of the version 8 upgrade process)

Web Sales

There is a new apache server version 2.2.11 that will be installed. There are some slight revisions that must be made to your existing web pages to support the new apache module. Your existing version 7 web pages will be converted by the support team unless you have made massive modifications to them (most venues have not).

Key changes to the web component:

  • activeListenersA new 'health & statistics' module has been created for the apache server. It provides some key monitoring statistics so that you can tell how long patrons are waiting (now, and historically), as well as the status of each online listener. The statistics are displayed in a web page and have two basic areas.

    • The upper area of the web page shows the number of active listeners and the current status of each listener. In the example below, there are:
      • 6 listeners in total
      • the listener at 172.16.22.248 is busy servicing a request at the current time
      • all 5 other listeners are available to accept a request

    • statisticsThe second part of the web page display shows statistics about the performance of apache and each of the listeners. It shows statistics such as:
      • Current requests
        • The current number of waiting requests and wait time. These are requests that still have to be serviced and are waiting for an available listener. If these numbers start to rise dramatically, it means people are waiting NOW, and an extra listener should be brought online to handle a peak load.
      • Total request
        • Total requests are the number of people that have requested at least one page from any web listener
        • Total no wait are the number of requests that were handed off directly to a web listener because at least one was available.
      • Averages relate to the size of the queues and wait time.
        • If people need to wait, but the average wait time is very low, then it means people are still being serviced in a reasonable time.
        • Average listener time is the average time that a request took from the time it was given to the listener until the listener handed back the finished page
      • Maximums show the heaviest load.
        • Max requests is the maximum number of patrons to hit the Apache server simultaneously. It is ok for this number to be higher than the number of listeners, as long as the average wait time is low. In that case, it generally means a one-time spike.
        • Max Queue size is the maximum number of people that had to wait.
        • Max Listener time is the longest a listener took to respond. This can be skewed by startup time when TM needs to start caching pages.
      • Totals
        • Wait pages are the number of times that all listeners were busy for longer than 25 seconds (typically) and the user was handed off to the waiting room page. IF this number starts to rise during a busy on sale, you should start one more listener
        • Closed pages is the number of times that the listeners were all shut down (none active at all) and people tried to hit your web site. These people would be told that the web sales was closed.
        • Total Error pages handles cases when an unexpected error occurs and and the user is given the 'error' page specified in the apache setup.

  • Clearing the cache on one listener will cause all other listeners to synchronize and reload their cache. You no longer need to do it at all listeners. There is also a way to reset the cache from the Company Preferences window on the 'Web Listener' tab.
  • The checkout process has been revised to address the odd seat left on hold status.
  • There is a message at the bottom of each web listener (in the typical message area) that gets updated approximately every 5 minutes. It indicates the current run time on the listeners, the amount of bytes moved, and the number of connections. This is only 3 bits of data that can be found in more detail on the 'Usage' tab and is for quick reference.
  • Also at the bottom of each listener is a setting for the level of log that you want displayed on the web listener. Regardless of this setting, all log entries are stored in the database.
  • There are a number of additional items for web sales. Because of this, the web sales listener has been separated into a separate sub menu. The options are:
    • Web Sales Listener - moved from the main 'Patron Sales' menu and starts the web listener as before
    • Shopping Carts - moved from the main 'Patron Sales' menu into here and shows the shopping carts as before.
    • Pending Emails - is a new feature to view all email blasts that are sitting in error status.
      • this shows the reason why the email did not go (bad email address, missing email address, server down, etc)
      • you can then edit the patron record to correct the issue and the email will be reset.
    • Scanning Monitor - the web listeners handle the checkin/checkout process for wireless scanning. Because of that, we added a new feature here that lists the tickets that are being scanned for that day and who (or which device by IP address) is scanning them. This gives you:
      • an opportunity to see the performance of each wireless device
      • watch the actual house fill up based on scanned tickets (the window refreshes itself every 30 seconds or so) and anticipate when to start the show based on traffic flow
      • it also displays the status of the house based on tethered scanners.
    • View Web Statistics - this is a new feature that shows the hourly snapshot of the performance statistics on the web. It also allows you to open up the performance web page (described above) in your local browser if you have permission to access the statistics from your IP address (based on settings in the listener)
    • View Listener Log - the web logs (on each web listener) are now written to the database as well as to the local hard drive. This is how you can view logs from all listeners in a coherent order easily.

webSales

Shopping Carts

  • The web listener logs are now saved inside the database (in addition to optionally saving as a text file on each listener). This means:
    • you can view the combined logs from many listeners in one location within theatre manager.
    • You can easily see how a particular patron was handed off amongst web listeners.
    • You can view the same logs on a shopping cart basis.
  • When a patron calls up with an open shopping cart, you can see where they have been and help them out on the phone
  • If a shopping cart is still open, an a patron calls up to talk to the box office, you can complete the shopping cart for the patron if you wish and take the payment over the phone.
  • On the shopping cart, you can see any correspondence sent to the patron relating to that shopping experience. This means you can view (and resend) the confirmation email exactly as the patron would have seen it.

Application Preferences

  • Preference settings unique to each machine have been moved from the tmdb.txt file and this file no longer exists. The preferences are now stored in the standard preferences location and varies depending on operating system. The upgrade will move and rename them automatically. The new location of the preferences are below. 'MyUser' represents the user you are logged in as so this means that each user of Theatre Manager on a machine will have their own preferences:
Operating system Generic Location Typical Path name
OS-X HOME ~/Library/Preferences/TheatreManager/TheatreManager.plist
note: ~ refers to each users preferences, or /User/MyUser/Library/Preferences/TheatreManager
Win 2000 and XP USERPROFILE C:\Documents and Settings\MyUser\Application Data\TheatreManager\TheatreManager.txt
Vista LOCALAPPDATA C:\Users\MyUser\AppData\Local\TheatreManager\TheatreManager.txt