Discrepency between OpenReferral and Ohana

[devinbalkind]

Below are (what I think are) two discrepancies between the OpenReferral specification and Ohana.

• In OpenReferral: Services > Funding is a text field. In Ohana it's an autocomplete/select with 2 terms that are "Bank Statements" and "Government Issued Picture ID".
• In Open Referral: Services > Required Documents is a text field. In Ohana it's an autocomplete/select with about 15 terms that start with "City" and end with "United Way".

[monfresh]

The OR spec does not specify how a form in a GUI is to be implemented. The autocomplete/select fields you mentioned in the Ohana admin interface are also text. The reason why they provide multiple choices is because a Service can have multiple Funding Sources, as well as multiple Required Documents.

What I think you meant to raise as an issue is that you were expecting to be able to enter a term other than the ones provided. If that's the case, I'll refer you to the Ensuring data consistency section of the Admin basics Wiki article.

Since this project is being updated regularly, I would recommend always checking the latest installation instructions, as well as the latest Wiki articles to see if your question might already be answered there. We've also made many aspects customizable via settings.yml and application.yml. It's a good idea to read through the documentation in those files.

In the future, in order to help us best understand a problem you might be encountering, I would recommend describing in detail exactly what you are trying to do with clear steps to reproduce, then the expected result, and the actual result.

For example, if I'm understanding this issue correctly, it would look like this:

Steps to reproduce:

1. In the admin interface, visit any existing service
2. Scroll down to the Funding Sources section
3. Click inside the field
4. Type a word that isn't included in the list of choices

Expected Result: I want to be able to add a word that isn't listed

Actual Result: I can only choose from a predefined list of words

[devinbalkind]

Understood. Thanks for this note.

I see how I'll be able to resolve the issue for my own deployment by customizng settings.yml.

I guess my issue is actually a feature request, not a bug.

The feature request is to allow superadmins to manage the various taxonomies in settlings.yml through the admin interface.

I've got a few other features I want to upload. I'll document them all as well as I can and add them to Github in bulk in the near future.

Thanks.

On Tue, Dec 16, 2014 at 8:14 PM, Moncef Belyamani notifications@github.com wrote:

The OR spec does not specify how a form in a GUI is to be implemented. The autocomplete/select fields you mentioned in the Ohana admin interface are also text. The reason why they provide multiple choices is because a Service can have multiple Funding Sources, as well as multiple Required Documents.

What I think you meant to raise as an issue is that you were expecting to be able to enter a term other than the ones provided. If that's the case, I'll refer you to the Ensuring data consistency https://github.com/codeforamerica/ohana-api/wiki/Admin-interface-basics#ensuring-data-consistency section of the Admin basics Wiki article.

Since this project is being updated regularly, I would recommend always checking the latest installation instructions https://github.com/codeforamerica/ohana-api/blob/master/INSTALL.md#set-up-the-environment-variables--customizable-settings, as well as the latest Wiki articles to see if your question might already be answered there. We've also made many aspects customizable via settings.yml https://github.com/codeforamerica/ohana-api/blob/master/config/settings.yml and application.yml https://github.com/codeforamerica/ohana-api/blob/master/config/application.example.yml. It's a good idea to read through the documentation in those files.

In the future, in order to help us best understand a problem you might be encountering, I would recommend describing in detail exactly what you are trying to do with clear steps to reproduce, then the expected result, and the actual result.

For example, if I'm understanding this issue correctly, it would look like this:

Steps to reproduce:

1. In the admin interface, visit any existing service
2. Scroll down to the Funding Sources section
3. Click inside the field
4. Type a word that isn't included in the list of choices

Expected Result: I want to be able to add a word that isn't listed

Actual Result: I can only choose from a predefined list of words

— Reply to this email directly or view it on GitHub https://github.com/codeforamerica/ohana-api/issues/295#issuecomment-67262748 .

Devin Balkind @devinbalkind vitamindwb.com

[monfresh]

Sounds good, but please open each feature request as a separate issue in GitHub, including the one about managing settings.yml, and label them with the "feature request" tag.

Also, note that those feature requests might not be implemented in the near future, at least not by me since I won't be working on Ohana full-time anymore. However, other people can always build those features and submit pull requests.

For settings.yml, I personally don't think it's worth it to make it editable via the admin interface since it's just a matter of opening up a text editor and making changes. And settings.yml is not a file that would be changing all the time. Most of the settings will be configured once during installation and will rarely change afterwards.