biocore / american-gut-web Goto Github PK

If we modify one URL, we don't have an easy way to know how many files do we need to change. A potential solution for this, is to create a python file in which all the URLs are defined in variables, and use those variables in all the templates and python code.

...no longer relevant

So users can develop locally

Bring down the oracle/mod_python based site and bring up the postgres/tornado based site

Req. from Victoria, can we change "felons" to "people in prison"? I believe the only location is within the FAQ

webserver.py should have a parameter that lets you specify which configuration file to use, something like:

$ webserver.py --config-fp=british-gut.conf --port=7777 &
$ webserver.py --config-fp=american-gut.conf --port=8888 &

related to #131

As well as pull down for country of birth, etc.

Many of the instances can be changed to [email protected], please make sure to format appropriately (e.g., %(HELP_EMAIL)s)

...or extend existing admin tools. But it would be very nice to have either easy click commands or an interface that lets us:

• post a banner status message on login and portal (e.g., "we are currently experiencing problems, blah blah")
• disable login

Probably a few other things to the list

There are many places in the data access code (e.g., see these lines) where column order is hard-coded. It would be better if we could get the column names and values in a dict without hardcoding the order, probably by making use of a postgres results object method.

switch everything to use _ instead of camel case

...following completion of the primary survey, link out.

@jwdebelius, can you send on the URL for the ASD survey?

To send for update by the British Gut, we need to take the text strings defined by amgut.lib.locale_data.american_gut, and convert them into a Google Spreadsheet with two columns: variable name, and the text value. Ideally, one sheet per template. We will instruct the group to, with great emphasis, not manipulate the variable names or modify any inline html.

...needs to be run from a system that actually is running an MTA

We say that we'll return non-fecal samples January 1st, 2014. I assume we have not done this yet, and we should update the text. We also need to get these done.

Currently the Change Password link in sitebase points to /authed/change_password/ which does not exist. I think this is supposed to be the change_pass_verify.html page but not 100% sure.

Please contact me directly for test site credentials

...particularly, make sure to add British Gut group and Margaret and Phil from Australia. We need to sync with the American-Gut repo as well

...just need to remove it from amgut.lib.util.external_surveys

Any text that is displayed to the user will need to be pulled out into project/locale specific dicts. These dicts will be located under amgut.lib.locale_data, and each portal will have its own. For instance, the American Gut portal text and media will fall under amgut.lib.locale_data.american_gut. The motivation for portal specific, instead of language specific localization is that many countries rely on en_UK, but we need to play for having different branding (e.g., Australian Gut) moving forward.

Each locale_data module needs to provide two dicts, text_locale and media_locale. The structure of text_locale is as follows:

text_locale = {
    'name_of_template.html': {
        'INFORMATIVE_VARIABLE_NAME': 'The text that is displayed'
    }
}

media_locale = {'INFORMATIVE_VARIABLE_NAME': '/path/to/media.jpg'}

text_locale is per-template which minimizes what needs to be passed into render from the handlers. media_locale is not per-template as much of the media is common across templates, such as the logo.

In the __init__ for amgut.lib.locale_data, there is a media_locale that represents anything common regardless of portal. This dict is updated by the project specific media_locale.

For localization data, all handlers will need to add:

from amgut import text_locale, media_locale

The package-level __init__ will resolve the appropriate locale data. All handlers wishing to use the locale data will need to specify the locale over render. For instance:

class MyHandler(BaseHandler):
    def get(self):
        # stuff of interest
        template = 'really_awesome.html'
        self.render(template, ...whatever..., text_locale=text_locale[template], media_locale=media_locale)

Within the templates, all user visible text will need to be replaced with:

<!-- former -->
<p><strong>very</strong> informative message</p>
<!-- new style -->
<p>{% raw text_locale['INFORMATIVE_MESSAGE'] %}</p>

All variables should be expressed with raw, which will let us preserve html formatting and tags within the locale dicts.

And finally, the list of templates to knock off. A template is considered completed once the text has been pulled out and replaced with locale lookups, the relevant locale entries updated, and the handler has been updated.

• 404.html
• international.html
• FAQ.html
• map.html
• add_sample.html
• new_participant.html
• add_sample_overview.html
• new_participant_overview.html
• addendum.html
• no_auth_404.html
• animal_survey.html
• no_auth_sitebase.html
• authed_index.html
• participant_overview.html
• change_pass_verify.html
• portal.html
• construction.html
• register_user.html
• db_error.html
• retrieve_kitid.html
• error.html
• sample_overview.html
• forgot_password.html
• sitebase.html
• help_request.html
• survey_main.html
• index.html
• taxa_summary.html

Currently if something goes wrong the user is presented with the stacktrace and other info we really don't want them seeing. We need to have the python logger or some other centralized way of storing these errors for later examination.

There's a question referencing how to convert macronutrients to percent calories. We're no longer doing this.

• Create the structures that will be used to load questions, responses, question groups, etc.
• Create the tables that will store user responses
• Store user responses on post to human_survey.html (in human_survey.py)
• Load user responses from database when they exist

Key PORTAL_DIET_QUESTIONS in media_locale, in use within portal.html

...some might be in there without formatting actually happening

...once we receive it back. This issue also involves verifying that the changes make sense

Right now, the table structure does not make it plainly obvious how to add survey questions for a new portal. It would be very useful to have documentation about how this is accomplished.

This file seems out of place, and I don't think it's necessary any more (since the procedures were broken out into their own files, one per procedure) and placed in the american-gut-web / amgut / lib / data_access / procedures directory, but I wanted to make sure before removing it. Any objections?

unfortunately, that needs cleanup

@adamrp @ElDeveloper, do you recall if this was just an "under construction" page? If so, can we remove it?

...no longer relevant

See attached, they're falling in the wrong place

When you hit submit, you get "'AGDataAccess' object has no attribute 'getAGKitbyEmail'"

Assigning to myself

Basic usage stats (may not be necessary if google analytics covers a lot). We do want an easy way to determine the current number of active users.

Need to reflect:

• Jairam's short questions within the questionnaire
• The external link for the VioCare (Mayo) FFQ
• No longer need a food diary
• Might need to revise images

We need to figure out how to actually run both portals at the same time

currently there is only one group AG and the projects in that group are hard coded. This needs to be changed to be in the database then ag_data_access getBarcodeProjType needs to be updated to use the new table.

This cam up in #132. We need to have the addendum specifically state American Gut for all the data shown currently, but it would be nice to have info for each project and all combined projects once we have enough samples.

Those commits got reverted some how

Right now, supplemental form data is not added to the human survey (see templates/human_survey.html)

Doesn't make sense to have for the British Gut portal for instance

Since you can put anything in the url, need to verify that the participant passed is actually viewable by the logged in user.

There are some situations where this is okay to have, and some where it needs to be project specific. This is unfortunately a bit case-by-case. Project/portal specific should be replaced with %(PROJECT_TITLE)s and formatted appropriately. This issue also entails going back through BG text to see if "British Gut" is present and whether it should be string formatted.

related to #131

...with latest amendment