This is an admin interface for the data that appears on the SMC-Connect website. It allows organization members to sign up with their organization email address, and allows them to update the locations that belong to their organization.
If someone signs up with a County email address that ends in @smcgov.org or @co.sanmateo.ca.us, they will need to ask someone who has "Master Admin" access, like Edwin Chan, to add them as an admin for the locations they need to update.
- Ruby version 2.1.1
- Rails version 3.2.17
- MongoDB with the Mongoid ORM
- Testing Frameworks: RSpec, Factory Girl, Capybara
Please note that the instructions below have only been tested on OS X. If you are running another operating system and run into any issues, feel free to update this README, or open an issue if you are unable to resolve installation issues.
###Prerequisites
OS X: Set up a dev environment on OS X with Homebrew, Git, RVM, Ruby, and Rails
Windows: Try RailsInstaller, along with some of these tutorials if you get stuck.
OS X
On OS X, the easiest way to install MongoDB (or almost any development tool) is with Homebrew:
brew update
brew install mongodb
Follow the Homebrew instructions for configuring MongoDB and starting it automatically every time you restart your computer. Otherwise, you can launch MongoDB manually in a separate Terminal tab or window with this command:
mongod
MongoDB installation instructions using MacPorts are available on the Wiki.
Other
See the Downloads page on mongodb.org for steps to install on other systems: http://www.mongodb.org/downloads
From the Terminal, navigate to the directory into which you'd like to create a copy of the SMC-Connect Admin source code. Next download this repository into your working directory with:
git clone https://github.com/smcgov/SMC-Connect-Admin.git smc-connect-admin
cd smc-connect-admin
script/bootstrap
Inside the config folder, you will find application.example.yml.
Rename it to application.yml and double check that it is in your
.gitignore file (it should be by default).
By default, the app is configured to point to the
demo API.
To point to your own instance of Ohana API, change the value of
OHANA_API_ENDPOINT in your application.yml.
If you made changes to config/application.yml in either the Admin
app or the API app, or if you're pointing the Admin app to an API app
that already has ADMIN_APP_TOKEN configured, make sure that the value of
ADMIN_APP_TOKEN in the API matches OHANA_API_TOKEN in the Admin app.
Start the app locally:
rails s
And visit it in a web browser at:
localhost:3000
The bootstrap script you ran earlier created three users for you that you can sign in with. You can see the username and password for each user in db/seeds.rb. When you sign in with the first two, you'll have access to locations whose email or website domains match the domain name of the user's email address. The locations come from the sample data provided by the Ohana API.
The third user is there to let you try the interface as a master admin, but you can set any of the three users as an admin by setting the "role" field to "admin". To do that, you need direct access to your Mongo database. The easiest way to view and update Mongo data is with a GUI like one of these.
Run tests locally with this simple command:
rspec
For faster tests (and many other rails commands, like rake):
gem install zeus
zeus start #in a separate Terminal window or tab
zeus rspec spec
To see the actual tests, browse through the spec directory.
The tests will take around 3 to 5 minutes to run. Note that a browser window will open during the integration tests as some of them use the Selenium web driver.
In the spirit of open source software, everyone is encouraged to help improve this project.
Here are some ways you can contribute:
- by using alpha, beta, and prerelease versions
- by reporting bugs
- by suggesting new features
- by suggesting labels for our issues
- by writing or editing documentation
- by writing specifications
- by writing code (no patch is too small: fix typos, add comments, clean up inconsistent whitespace)
- by refactoring code
- by closing issues
- by reviewing patches
We use the GitHub issue tracker to track bugs and features. Before submitting a bug report or feature request, check to make sure it hasn't already been submitted. When submitting a bug report, please include a Gist that includes a stack trace and any details that may be necessary to reproduce the bug, including your gem version, Ruby version, and operating system. Ideally, a bug report should include a pull request with failing specs.
- Fork the repository.
- Create a topic branch.
- Add specs for your unimplemented feature or bug fix.
- Run
rspec. If your specs pass, return to step 3. In the spirit of Test-Driven Development, you want to write a failing test first, then implement the feature or bug fix to make the test pass. - Implement your feature or bug fix.
- Run
rspec. If your specs fail, return to step 5. - Add, commit, and push your changes.
- Submit a pull request.
This library aims to support and is tested against Ruby version 2.1.1.
If something doesn't work on this version, it should be considered a bug.
This library may inadvertently work (or seem to work) on other Ruby implementations, however support will only be provided for the version above.
If you would like this library to support another Ruby version, you may volunteer to be a maintainer. Being a maintainer entails making sure all tests run and pass on that implementation. When something breaks on your implementation, you will be personally responsible for providing patches in a timely fashion. If critical issues for a particular implementation exist at the time of a major release, support for that Ruby version may be dropped.
Copyright (c) 2013 Code for America. See LICENSE for details.