This is not an officially supported Google product.
The Service Eligibility Calculator is a simple discovery tool that allows users to filter and browse recommended services by entering information about their household. PII is not saved, but rather the tool filters the full list of services to only display services that match their needs. Filters include:
- How many people / how old are people within their household
- Personal interests, e.g. childcare, senior services, housing resources, etc.
- Income
- Residency within the city limits
See the Boulder For Me tool for a working implementation of a Service Eligibility Calculator.
The Service Manager is the content management portal for the services populating the Service Eligibility Calculator. This content management portal allows Service Managers - those most familiar with the service-level content - to enter service-specific details so users can more easily learn:
- Service overview
- Qualifications needed for applicants, e.g. income requirements, city residency requirements, etc.
- What they need to apply
- Timeline for application window
- How to apply when they are ready
With the most intimate knowledge of the questions their community frequently asks, Service Managers can ensure all of the relevant information is listed to reduce the need for community members to contact multiple city departments.
Google.org works to bring the best of Google to nonprofits and civic entities who are tackling the world's toughest challenges. The Google.org Fellowship embeds teams of Googlers with expertise in product management, software engineering, user experience, and more with nonprofits or civic entities for up to six months of full time pro-bono work. Fellows and their host nonprofit or civic entity build solutions together, working as a team to ensure the Googlers’ work has a sustained and lasting impact.
This README covers some of the one-time setup and deployment steps to run the code in this repository. Other documentation includes:
- Technical Design: Design details for the project.
- Linux setup: LAMP and NPM setup on a Linux machine.
- Code maintenance: Steps to maintain this project.
- Drupal setup: Setup for a Drupal-based service manager.
Windows requires two specific steps to ensure compatibility with symlinks present in this repository:
- Enable Developer mode
- Clone repo with git clone -c core.symlinks=true {url}
Some developers have also found Windows Subsystem for Linux (WSL) with Ubuntu to be an effective development environment. If using WSL, be sure to install the necessary dependencies within the linux VM itself.
See also the Linux setup for instructions on installing and configuring these dependencies on a Linux machine.
- Git
- MySQL Server
- Apache
- PHP (or: https://windows.php.net/download)
- Composer
- Node + NPM
- VS Code (optional)
Run the following SQL commands in MySQL and substitute "password" with a password of your choosing.
CREATE USER 'services_rw'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'services_rw'@'localhost';Create api/env.local and api/env.test.local with the following contents (substituting "password" with the previously chosen password):
DATABASE_URL=mysql://services_rw:password@127.0.0.1:3306/services
From /api run composer install.
From /api run php bin/console doctrine:database:create followed by php bin/console doctrine:schema:create to create the services database.
Warning: The following API tests are data desctructive. The database will be overwritten with test data.
From /api run composer test.
From /api run php bin/console server:run and navigate to http://localhost:8000/api.
From /client/service-manager run npm install.
From /client/service-manager run npm start and navigate to http://localhost:3000.
From /client/service-calculator run npm install.
From /client/service-calculator run npm start and navigate to http://localhost:3001.
The first step in deploying a new version is to create a new deploy bundle
using the deploy.sh script from a clean git client.
Start from a clean git client, for example:
git checkout master
git fetch origin
git reset --hard origin/master
git checkout -b new-releaseCreate a new deploy bundle, incrementing the patch version number (i.e. if the current version is v1.0.0, the new version will be v1.0.1):
./deploy.sh --env=your-deploy-env patchNote: You can replace patch with major or minor to update the major or
minor version number instead.
The --env flag specifies any local environment overrides specific to your deploy environment. This directory should contain the following resources:
- An
.envfile with system environment overrides to be applied during deploy. - A
publicdirectory containing any file resources (e.g. favicon and logos) that will be copied into the deployedpublicdirectories of both the calculator and manager deployments. - A
localesdirectory containing translations and text resources specific to your environment.
A sample deploy environment directory can be found at sample-deploy-env.
By default, the script creates a bundle of the standalone service manager and
calculator with the API-Platform backend. The --drupal flag will create a
bundle of the Drupal backend, with the standalone calculator configured to use
that in place of the API-Platform backend.
The deploy.sh script updates the version, creates a new deploy bundle, and
optionally commits, tags, and pushes the newly versioned bundle to github (must
be connecting to github with ssh for this to work).
You can now merge the new pull request into master using the normal process.
Alternatively, if no review is required / desired - you can run the
deploy.sh script directly from a clean git client at master bypassing a
separate pull request.
Once the deployment bundle is created, you can now install the bundle by
copying it to your own server, and then running the install.sh script
(or drupal/install.sh for a Drupal deployment).
If this is your first time deploying, you'll need to download the
install.sh script from github to your server first.
A windows specific install.ps1 script also exists for installing using
powershell in windows.
Top-level app.json, Procfile, package.json and composer.json files exist for Heroku buildpacks which operate at the root of the repository. Composer specifically lacks the ability to run install related command events without packages to install, so we used another lifecycle event.