Version 6.2
Version 6.1
Version 6.0
Version 5.4
Version 5.3
Version 5.2
Version 5.1
Version 5.0
Version 4.9
Version 4.8
Version 4.7
Version 4.6
Version 4.5
Version 4.4
Version 4.3
Version 4.2
Version 4.1
Version 4.0
Version 3.2
Version 3.1
Version 3.0

Manual: Versions-Version 5.2

Get Started |Calendar |Locations

July 2017

Version 5.2 is an incremental upgrade of the RidgeStar Interactive SiteInteractive Site incorporating new concepts and features in the base 5.0 system, as described below:

0. MariaDB and Injection Defenses
The acquisition of MySQL by Oracle has necessitated the shifting of the Open Source Database in use within the RidgeStar servers to MariaDBGoing. Along with this shift, the underlying calls to the database are being converted to the MariaDB Object Model for all processing of SQL requests that originate on the website.

While there are many benefits to this effort, one of the key aspects is the improved detection and defense from any sort of SQL Injection "attacks" that may be directed at a RidgeStar site. Further, Audit entries generated via the new Object based API will be stored in the Audit table in an enhanced mode for visual inspection and more accurate post-processing (should that be required in the future).

Existing sites and all end users should not notice any change in capability or processing characteristics. The Administrator may notice a few subtle changes behind the scenes (the Audit table, error messages, etc.).

1. Criteria now stored in JSON format
Saved criteria contained certain restrictions in the character sequences that could be stored as a Criteria for use in a Form. This upgrade changes the format of the saved Criteria to a format (JSON) that eliminates the previous restrictions. The system will continue to accept older Criteria storage formats for upward compatibility, but all Saved criteria in 5.2.1 systems or greater will save Criteria in the new format.
2. Feature=SubFields replaces/upgrades Feature=FieldParent
The system has been enhanced to permit any single Field to be defined as a subset or a portion of one or more other Fields. This permits an existing playing surface to be utilized/marked for smaller sided Matches (thus, multiple "SubFields" within a single Field) without sacrificing the cross checking for double booking of Matches included in the system.
3. Feature=Mail now supports Delete_After and Delete_Without_Logon
The system has been enhanced to permit the Webmaster to specify an Interval of time that internal Mail messages will be retained. Delete_After provides an interval to age any and all Mail messages. Delete_Without_Logon permits the specification of an Interval that will cause the deletion of Mail messages for Users that are no longer actively using the system. See Manual: Settings-Mail for more information.
4. Feature=PageText permits an Administrator to override default fixed text
Fixed text at the top and bottom of the pages on the site can be changed to Webmaster controlled content (specified using the Topics and stored as a specific Tag). Activate ?pagetext=1 on your site to get the site to display which Tag will be used on a specific page.
5. Feature=CheckSchedules identifies possible schedule Match overlaps
Verification is done a Match is updated to verify that the Date, Time, and Field associated with a Match has no identifiable overlap with aother scheduled Match (requires Feature=Durations to be installed and active).
6. Bulk Load and Bulk Update have been upgraded to honor Positions specifications
It is now possible (via Setting=BulkLoad) to specify Site segments (e.g. Assignor) that can only manipulate portions of the Matches table, based upon Positions specifications.
7. Feature=Threads provides Record level locking
The Thread mechanism supercedes Feature=Locks that has been previously used to prohibit the use of Multiple Tabs/Instances when using a Form on the same database table at the same time. The Thread mechanism PERMITS an authorized User to manipulate 2 (or more) DIFFERENT records within the same database table at the same time on multiple Tabs/Instances without possibility of data value overlap.

This is a "Record level" thread that will intercept efforts to re-use the SAME data record twice, but will permit usage of different data records on different tabs. For sites that have been using Feature=Sessions to permit this sort of usage pattern, it IS quite likely Feature=Threads will eliminate the need for multiple Session support.

8. Feature=JavaNames3
Changes the Name pulldown JavaScript (client side) logic to take advantage of Server based REST protocols to defer loading of applicable names until the Visitor clicks into the Name field. This permits the site to easily handle very large Users tables without the high overhead related to populating the related pulldowns. See Manual: Settings-JavaNames for additional, detailed information.
9. Feature=Conflicts permits an Administrator to specify SelfAssign Rules that will be verified
Verification is done when an Assignor displays a Match against the current assignments on the Match and are displayed as an Alert when the Administrator enters the Administrator segment. This Feature can act as an alert to both the Assignor and the Administrator when an Assignment has been made that does not comply with SelfAssign specified standards.

This version of the system is complete and available to existing Clients (contact your account rep)


- The Development Staff