1.10.1

Bugfix release:

https://github.com/City-of-Bloomington/uReport/issues?q=milestone%3A1.10.1+is%3Aclosed

1.10 - Modernized

The release is largely a source code cleanup release. We've updated the source to using namespaces and PSR autoloading. This will help us add new features even faster in the future.

Also in this release is support for multisite hosting and custom templating for sites.

Of course, to support this, the configuration has changed.

Database changes

There are a couple of minor database changes. The SQL commands are in /scripts/migrations/1.9-1.10/databaseChanges.sql

Configuration Changes

To support the multisite hosting, the configuration.inc has been split up. A new /data/site_config.inc has been created to cover all the site-specific settings. configuration.inc now only includes installation-specific settings.

You will need to move your current settings into the new files. Most likely, you will not need to edit configuration.inc at all. (But take a quick look through, just to be sure)

All of the settings for your specific site will have moved into /data/site_config.inc.

Data directory is now configurable

The /data directory now contains all site-specific configuration, data, and custom templating. In your Apache config, you can now specify the SITE_HOME to point to wherever you would like to put the data directory.

The default still places the data directory inside the crm application. However, you can choose to place the data directory somewhere else. In your Apache conf for the site, you just set the SITE_HOME environment variable to wherever you have placed the data directory for your city.

Doing this means the crm directory hosted by Apache would no longer have any modifications from the release. Upgrades are now even easier. Since your site_config and data are all outside of the crm application, you can apply updates by just completely overwriting the crm directory with the new version from github. You don't even have to restart Apache! Instant upgrades! All your city settings and data are safely elesewhere.

Alias /crm "/srv/sites/uReport/crm/public"
<Directory "/srv/sites/uReport/crm/public">
    Options FollowSymLinks
    AllowOverride None
    Require all granted

    RewriteBase /crm
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule .? /crm/index.php [NC,L]

    SetEnv SITE_HOME /srv/uReport/MyCityData
</Directory>

1.9.1 - Bug fix release

Bug Fixes:
https://github.com/City-of-Bloomington/uReport/issues?milestone=5&state=closed

1.9 Google Summer of Code release

What's New

• Maps and map-based searching
• All required libaries are now included
• Users can now save bookmarks to searches and reports
• Added support for i18n
• Added support for multi-home installations
• Bug fixes!

Full information is available in the Issue Tracker
https://github.com/City-of-Bloomington/uReport/issues?milestone=4&page=1&state=closed

Upgrading to 1.9

Backup

Backup your database, configuration file, and data directory. Just in case things go horribly wrong, you can replace the old version. I usually do this by dumping the database into an SQL file inside of /crm/data, then tarballing the data directory and putting the tarball somewhere safe.

It looks something like this:

cd /srv/sites/uReport/crm/data
mysqldump -p --opt crm > crm.sql
cd ..
tar czvf data.tar.gz data
mv data.tar.gz /srv/backups

Download

The easiest option is to download the source code from this latest release. The links to the zipped source code are down at the bottom of this page.

One of the major differences in this release is that all required libraries are now included in the download. It used to be that you had to download them yourself, and set them up. If you've already got them downloaded, you can probably continue to use the versions you've got working.

If you choose to do a clone from Github (to grab the latest bleeding edge copy), the libraries are in the repository as submodules. You'll need to initialize and update the submodules in order to download the libraries to your working copy.

Replace

Replace your existing install with the new version. Save your data directory, and your configuration.inc, but everything else should be deleted and replaced with the new version.

Redo your configuration

There are a few changes you'll need to make to your configuration.inc.

To start off with, since the libraries are now included in the download, you may want to point to the copies that are included in the application. (Also, you may not want to, it's just up to you).

Aside from the library changes, there is also a new setting needed in configuration.inc. If you look in the new configuration.inc.default, down towards the bottom is the new stuff.

define('LOCALE', 'auto');

Also, in the bootstrap section, there's a few new lines of code that check for an environment variable. If you are just modifying your existing configuration.inc, I would copy and paste the entire bootstrap section from configuration.inc.default, replacing the old version you have in your own configuration.inc.

Alternatively, you could also just start a new copy of configuration.inc from the default, and then, go in and apply all the settings needed from your old configuration.inc.

Run all the migration scripts

All of the required upgrade scripts are in /scripts/migration/1.8.1-1.9

• Apply the SQL changes contained in databaseChanges.sql.
• Run generateTicketClusters.php
• Copy the new schema.xml to your Solr core configuration directory.
  • Remember that you'll need to restart Solr (Tomcat) after changing the schema.xml
• Re-index the Solr search engine

databaseChanges.sql

This should be quick and easy. You can either copy and paste the SQL commans into a MySQL shell...or just send the SQL file directly to MySQL on the command line:

mysql -p crm < databaseChanges.sql

generateTicketClusters

This may take a while, depending on how many tickets you have, and how fast your system is. For us, in Bloomington, with ~100,000 tickets, it takes about 45 minutes. You can kick this script off in a terminal window, and do other stuff while waiting for it to finish. Just keep in mind, you cannot re-index the search engine until after this script finishes. The whole point is to put the new cluster data into the search index.

schema.xml

The new mapping clusters require special, spatial fields in Solr. You'll need to copy the new schema into place, and restart Solr. Don't worry too much about the current search index data. It's going to get wiped and re-indexed.

Re-index the Solr search engine

Run the indexSearch.php script. This will wipe the existing search index and re-index everything, picking up the new mapping clusters that we've created.

This could take a while as well, but not as long as generateTicketClusters. For us, in Bloomington, with ~100,000 tickets the search indexing takes about 15 minutes.

That's it

You should be up and running on the new version now. Enjoy. And let us if you run into trouble.

1.8.2

Updating to 1.8.2

Follow the general updating instructions in the Wiki

This is primarily a bug fix release. It also includes all the bug fixes from what would have been 1.8.1. However, I never tagged that release. And anyway, 1.8.1 was really a bug-ridden mess, neccessitating a 1.8.2 release to fix all the bugs.

Media Bugfixes

I changed the naming scheme for storing media files on the server hard drive.
There's a database migration in /scripts/migrations. But before you run that, you'll need to clear the media thumbnail cache to remove all the old filenames. There's new script for this in /scripts/media.

• Run /scripts/media/clearThumbnailCache.php
• Run /scripts/migration/1.8-1.8.1/databaseChanges.sql
• Run /scripts/migration/1.8-1.8.1/updateMediaFilenames.php
• Make sure apache still has permission to write into the media directory

1.8

New in 1.8

• Support for Solr 4.0
• Nicer looking icons (from FontAwesome)
• People can now have multiple addresses, emails, and phone numbers
• Locations are validated against a city's lat/long bounding box
• Support for weekly digest emails to employees
• Support for tracking Service Level Agreements
• Bugfixes!

Detailed change log is in the issue tracker:
https://github.com/City-of-Bloomington/uReport/issues?milestone=2&state=closed

Updating to 1.8

Instructions for updating from previous versions are in the Wiki

Update your configuration.inc

There are a few new configuration settings that must be added to your previous configuration.inc. You can copy the default settings from configuration.inc.default into your previous configuration.inc. Inside configuration.inc.default, look for, and copy these settings into your previous configuration.inc.

<?php
define('SOLR_PHP_CLIENT', APPLICATION_HOME.'/libraries/solr-php-client');

/**
 * Bounding box for valid locations
 *
 * Comment these out if you do not want this validation.
 * Tickets will be rejected if they have coordinates that
 * do not fall inside the defined bounding box.
 */
//define('MIN_LATITUDE',   39.069187);
//define('MAX_LATITUDE',   39.99915);
//define('MIN_LONGITUDE', -86.641575);
//define('MAX_LONGITUDE', -86.440543);

/**
 * Image handling library
 * Set the path to the ImageMagick binaries
 */
define('IMAGEMAGICK','/usr/bin');
define('THUMBNAIL_SIZE', 150);

define('CLOSING_COMMENT_REQUIRED_LENGTH', 1);

1.7.3

We recently migrated this project from Google Code. However, we did not migrate all
the past issue tracker history from the Google Code project.

http://civic-crm.googlecode.com

The 1.7.3 release has issues spanning both systems.
Previous releases were done in the Google Code project. Issue tracker history
for those fixes are still saved in the old, Google Code project.

• http://code.google.com/p/civic-crm/issues/list?can=7
• https://github.com/City-of-Bloomington/uReport/issues?milestone=1&page=1&state=closed