As a user, I want to know if an audio file has been attached to a record when I'm editing that record. At the moment, the edit page will show photo thumbnails when photos are attached to a record, but shows no indication of an audio file when an audio recording is attached.

Scope:
If an audio recording is attached to a record, the edit record page should reflect it by either showing the audio player or an image representing the audio file, with a download link. Image should be a typical audio file icon.


h3. Acceptance Criteria

|Given|When|Then|
|Given an mp3 has been attached to a child record|When I am on the Edit Child Record page|Then I should see an audio player at the bottom of the record|
|Given an AMR file has been attached to a child record|When I am on the Edit Child Record page|Then I should see an audio file image and a download link at the bottom of the record|

h3. Narrative

As a user, I want to see who flagged a record, when, and for what reason, in the record summary when I am in any of the view record or search results pages, so that I can quickly make decisions about records without clicking through.

h3. Acceptance Criteria

|Given|When|Then|
|a child record has been flagged as suspect | I am on a "view all" child records page | I should see "Flagged By {user} on {date flagged} Because {Reason flagged} in the record summary row.|
|a child record has been unflagged as suspect | The child record shows up in the search results page | I should not see the flagging details in the record summary row.|
|a child record has been flagged as suspect | I am on a "view all" child records page | I should see "Flagged By {user} on {date flagged} Because {Reason flagged} in the record summary row.|
|a child record has been unflagged as suspect | The child record shows up in the search results page | I should not see the flagging details in the record summary row.|

So that we can eventually upgrade to Rails 3.1 and make RapidFTR the modern marvel it should be, we need to fully transition from Webrat to Capybara. This is one of a series of very similar stories to help with that process. If you have any questions, please email jorge and the Google Group.

h3. Scope:

This story covers the following features only:
* api_authentication.feature
* api_create_child.feature
* api_edit_child.feature
* api_retrieve_child_photo.feature
* api_retrieve_child_record.feature
* api_retrieve_child_record_ids.feature
* api_retrieve_contact_info.feature
* api_retrieve_form_sections.feature


h3. Steps:

# Move feature file from features/ to capybara_features/
# Run tests
## If the scenarios all pass, then move on to the next feature on the list and repeat
# If a test does not pass, figure out what steps need to be rewritten so that they pass. Rewrite them.
# If you find something has been duplicated in the cucumbers you are migrating, de-dupe them.
# If you have any questions, email the google group.



h3. Acceptance Criteria

|Given|When|Then|
|Given I have moved a feature from features/ to capybara_features/|When I run the tests|Then they all pass!|

So that we can eventually upgrade to Rails 3.1 and make RapidFTR the modern marvel it should be, we need to fully transition from Webrat to Capybara. This is one of a series of very similar stories to help with that process. If you have any questions, please email jorge and the Google Group.

h3. Scope:

This story covers the following features only:
* (done) edit_user_details.feature
* (done) manage_users.feature
* password_recovery_request.feature
* user_disable.feature
* user_login.feature
* user_time_zones.feature
* create_and_view_user.feature


h3. Steps:

# Move feature file from features/ to capybara_features/
# Run tests
## If the scenarios all pass, then move on to the next feature on the list and repeat
# If a test does not pass, figure out what steps need to be rewritten so that they pass. Rewrite them.
# If you find something has been duplicated in the cucumbers you are migrating, de-dupe them.
# If you have any questions, email the google group.


h3. Acceptance Criteria

|Given|When|Then|
|Given I have moved a feature from features/ to capybara_features/|When I run the tests|Then they all pass!|

So that we can eventually upgrade to Rails 3.1 and make RapidFTR the modern marvel it should be, we need to fully transition from Webrat to Capybara. This is one of a series of very similar stories to help with that process. If you have any questions, please email jorge and the Google Group.

h3. Scope:

This story covers the following features only:
* admin_access.feature
* admin_page_link.feature
* sidebar_links.feature
* webapp_authentication.feature
* editing_contact_info.feature
* home_page_link.feature


h3. Steps:

# Move feature file from features/ to capybara_features/
# Run tests
## If the scenarios all pass, then move on to the next feature on the list and repeat
# If a test does not pass, figure out what steps need to be rewritten so that they pass. Rewrite them.
# If you find something has been duplicated in the cucumbers you are migrating, de-dupe them.
# If you have any questions, email the google group.



h3. Acceptance Criteria

|Given|When|Then|
|Given I have moved a feature from features/ to capybara_features/|When I run the tests|Then they all pass!|

So that we can eventually upgrade to Rails 3.1 and make RapidFTR the modern marvel it should be, we need to fully transition from Webrat to Capybara. This is one of a series of very similar stories to help with that process. If you have any questions, please email jorge and the Google Group.

h3. Scope:

This story covers the following features only:
* -delete_field_from_forms_section.feature-
* -add_suggested_field_to_form_sections.feature-
* create_custom_fields.feature
* reorder_fields.feature
* disable_enable_form_fields.feature
* add_custom_field_to_form_section.feature
* edit_custom_fields.feature


h3. Steps:

# Move feature file from features/ to capybara_features/
# Run tests
## If the scenarios all pass, then move on to the next feature on the list and repeat
# If a test does not pass, figure out what steps need to be rewritten so that they pass. Rewrite them.
# If you find something has been duplicated in the cucumbers you are migrating, de-dupe them.
# If you have any questions, email the google group.



h3. Acceptance Criteria

|Given|When|Then|
|Given I have moved a feature from features/ to capybara_features/|When I run the tests|Then they all pass!|

As a user, I want my searches to return child records according to my permissions level. If I only have access to child records that I have created myself, then my searches should only return records I have permission to see.

h3. Acceptance Criteria

|Given|When|Then|
|Given the user's permission is set to "Limited" (View/Edit Their Own Records Only| When I am on the Search page | Then only records matching the search criteria and created by the logged in user should be returned|
|Given the user's permission is set to “Unlimited" (View/Edit Records Created by Everyone)| When I am on the Search page | Then all records matching the search criteria should be returned regardless of who created the records|
|Given that user Jorge has created a child named Chris1 AND user Just is able to access only his own records|When user Just pastes the url for the Chris1 child record in his browser|Then the Chris1 child record should not be shown and user Just should return to the home page|
|Given my permission is set to "Limited" (View/Edit Their Own Records Only| When I am on the Search page | Then I should not have the option to search by 'created by' on the advanced search page.|

h3. Narrative

As a system administrator, I want to assign specific users the ability to only access and edit the child records that they have created, so that volunteers can register children in the field without being able to compromise the security of children whom they may not be in direct contact with.

This story covers:
* Adding a sub-option on the "User Details" section on the Add/Edit Users Page
* Only allowing "Limited Access Users" to see child records that they have created in the child view lists.

This story DOES NOT cover:
* search functionality (handled in story #748)



h3. Acceptance Criteria

|Given|When|Then|
|I am on the Manage Users Page| I select 'New User'| On the New User page I should see a radio button option labeled "User Permission Level: " with the following options: (option one) "Unlimited" (option 2 - SET AS DEFAULT) " Limited"|
|I am on the Manage Users Page| I select 'Edit' for an existing user |I should see a radio button option labeled "User Permission Level: " with the following options: (option one) "Unlimited" (option 2) "Limited" with the previously selected option enabled|
|a user set with "Unlimited" is created| I select "View all children" | Then on the "Listing Children" page, ALL child records should be displayed regardless of who created them.|
|a user set with "Limited" is created| I select "View all children" | Then on the "Listing Children" page only the child records created by that logged in user should be displayed.|
|a user set with "Unlimited" User Permission level and User type "User" | When logged in | The "Admin" menu access is NOT available|
|a user set with "Limited" and User type "User" | When logged in | The "Admin" menu access is NOT available|

Because so much depends on the name field, including basic search results, we should make the name field a special field which can't be disabled, renamed, or moved within the form sections.


h3. Acceptance Criteria

|Given|When|Then|
|Given I am an admin|When I am on the Edit Fields Page of the Basic Registration Form|Then I should not see a checkbox to enable or disable the Name Field|
|Given I am an admin|When I am on the Edit Fields Page of the Basic Registration Form|Then I should not see ordering arrows next to the Name Field|
|Given I am an admin|When I am on the Edit Fields Page of the Basic Registration Form|Then I should not be able to change the name of the Name Field|

So that I can better integrate RapidFTR data into my own system, I should be able to export my data in Upper Case, Title Case, or As Entered when I am exporting to CSV.

When clicking on 'export to CSV' and 'export selected records to csv' I should get a popup that asks me: "Would you like the export in UPPER CASE, Title Case, or as originally entered?

The text in the CSV should be displayed in whatever format I select.

As a
I want
So that


h3. Acceptance Criteria

|Given|When|Then|

*NOTE: Implementation will be tightly related to implementation of multiple photo attachments: #469*

h3. Narrative

As a user, I want to be able to add multiple audio files to a child record. This way, in addition to taking a primary interview of a child, I can document other related information such as the voice of the child, or the voice of a parent to play back to the child. Currently, the system only allows for one audio file to be attached to a record.

h3. Edit Child Page

* On the Edit Child page, add a button for 'add new recording' (this should replace the 'choose file' button).
** When an audio recording is added to a record which has no recordings attached, that first recording should be the primary one.
** Next to each audio file attached to a child record, add a button that says 'change recording'
*** When this button is clicked, the user will be able to select a new recording, following the same functionality that is currently in place.
* When an audio file is already attached to the record, and I choose 'add new recording' then I should follow the same work flow, but the new audio file should appear beneath the one that was already there.
* Adding or switching audio files should be logged in the child history log, following current functionality.

h3. View Child Record Page

* The primary audio recording should be the default audio recording. So where an audio player is displayed (if the audio file is mp3 and the browser is html5), the primary recording should be the one that gets played, following current functionality. On browsers where only a download link is displayed, the primary audio file should be linked first.
* If more than one audio file is attached to a record, links to the other audio recordings should be displayed below the player.
* There should be download links for all audio files, regardless of the browser or file format.



h3. Acceptance Criteria
|GIVEN|WHEN|THEN|
|Given I am a user or admin|When I am on the Edit Child Page|Then I should see a button for 'add new recording' where the 'audio field' is displayed|
|Given I am on the Edit Child Page|When I click 'Add new recording'|Then I should be prompted to find and upload an audio file|
|Given I have added an audio file|When the audio file is the only audio file attached to the record|Then it should be designated as the primary audio file|
|Given I am on the Edit Child Page|When there is an audio file attached|Then I should see a button next to the audio file that says 'change recording'|
|Given I am on the Edit Child Page|When I click the 'change recording' button|Then I should be prompted to find and upload a new audio file, and the new audio file should replace the audio file that was previously attached.|
|Given there is already an audio file attached to the child record|When I click 'add new recording'|Then I should be prompted to find and upload an audio file and the new audio file should appear beneath the one that was previously attached.|
|Given I am on the View Child Record Page of a record with .mp3 audio attached|When I am using an html5 compatible browser|Then I should see an audio player, and it should be set to play the primary audio file|
|Given I am on the View Child Record Page of a record with more than one .mp3 audio attached|When I am using an html5 compatible browser|Then beneath the audio player, I should see links to play the secondary audio files|
|Given I am on the View Child Record Page of a record|When audio is attached|Then I should see download links for all attached audio files|
|Given I am on the edit child page|When I have added a new audio file|Then this action should be logged in the Child History page, following current functionality.| comma separated free form text; at edit of child; but not gallery

h3. Narrative

As an Admin
I want to be able to view a user's mobile transactions history
So that I can disable users known to have misused data, compromised devices, or other problems as early as possible.

h3. Note

An "Activity Log" database will need to be created to record specific user activity including the activity time stamp; displayed in descending order.

Note from Tim Cochran: Initial work on creating activity log, events for child create, child delete, child update and user login is on this repo https://github.com/tcochran/RapidFTR/commit/9ecc67b4c5034435f3f6d6c9a22e82b9e9c43902

The timestamp should be logged whenever a user:
* Logs In:
** IP Address and User Name
* Create Child Record
* Updates Child Record

h3. Acceptance Criteria
Acceptance Criteria
| *Given* | *When* | *Then* |
| I am an Admin on the User Details page. | I scroll past the User Details and Device Information sections. | I should see a section called "User History". |
| A User has made two transactions through the Web App. | The "User History" section on the User Details page is viewed. | There are two transactions listed in order by timestamp in the User History. All transactions have the following information: timestamp, description of transaction, and IP Address. |
| A User has made twelve transactions. | The User Details page is viewed. | The ten most recent transactions are listed and a link called “Full User History” appears below the list. |
| A User has made twelve transactions. | The "Full User History" link has been clicked. | A page opens with all twelve transactions listed, in descending chronological order (Latest transaction listed first). |
| A User has logged into the Web App. | The "User History" section is viewed. | The login by the user has been logged in this format: {timestamp} {username} logged in from the web. IP Address: {ip address}. |
| A User has created a child record. | The "User History" section is viewed. | The creation of the child record has been logged, and displayed in this format: {timestamp} {username} created this child record: {uniqueID}. |
| The creation of a child record has been logged. | The "User History" section is viewed. | The child’s UniqueID in the log links to the child view page for that child record. |
| A User has updated a child record. | The "User History" section is viewed. | The update of the child record has been logged, and displayed in this format: {timestamp} {username} updated this child record: {uniqueID}. |
| The update of a child record has been logged. | The "User History" section is viewed. | The child’s UniqueID in the log links to the history page of the child record. |

h3. Add Photo to Child Details screen on Blackberry

* I want to add additional photos to the child details so there is more possibility of the child getting identified.

h3. Context

With the new functionality to add multiple photos to the Child Details, there is more possibility of the child being identified. The field worker will be able to add/edit photos of birthmarks and other identifiers.

h3. Value

This story allows the filed worker to add more photos to the Child Details to increase possibility of identification.


h3. Scope

*Note*
Entry Points to Add Photo -
* The Child Details screen
* Context Menu on the Photo Gallery

# ‘Add Photo’ option in context menu of Child Details screen
# Launch BB camera app to take a photo
# Once picture captured, Edit Photo screen is opened

h3. Notes

The "Edit Photo" screen is being dealt with in story #737

h3. Acceptance Criteria

|Given|When|Then|
|I am on the Child Details screen|I bring up the Context Menu|the Add Photo option appears|
|I am on the Photo Gallery page|I bring up the Context Menu|the Add Photo option appears|
|I am on the Child Details screen|I click on the Add Photo option on the context menu|the BB camera app launches|
|the BB camera app is launched|I take a photo|the Edit Photo screen opens|

h3. View and edit Photo Gallery on Blackberry device

* As a Field Worker I want to view and edit all pictures associated with a child

h3. Context

With the new functionality to add multiple photos to the Child Details, there is more possibility of the child being identified. The field worker will be able to add/edit photos of birthmarks and other identifiers.

h3. Value

This will enable the user to view and scroll through the photo gallery, as well as edit/delete highlighted photos.

h3. Scope

# 'View Photo Gallery’ option on the context menu instead of the ‘View Child Photo’ option
# Photo Gallery screen with all pics of particular child, primary picture appears first
# User can scroll through photo gallery
# Context Menu screen for the Photo Gallery screen as per workflow
# Set as Primary launches Confirmation dialog box. Yes will refresh gallery for selected photo to appear first.

NOT COMPLETE

h3. Acceptance Criteria

|Given|When|Then|
|Given I am on the "Child Details" page | When I bring up the context menu | Then I should see the option to "View Photo Gallery"|
|Given I am on the "Child Details" page | When I bring up the context menu | Then I should NOT see the option to "View Child Photo" option|
|Given I am on the "Child Details" page | When I select "View Photo Gallery" option from the context menu | Then I should be navigated to the "Photo Gallery" page And I should be able to scroll through all the photos associated to the child with the primary photo appearing first on the list|
|Given user is on the "Photo Gallery" page | When the user selects the "Back" button | Then they should be taken back to the Child Details page associated to the child|
|Given user is on the "Photo Gallery" page | When I bring up the context menu | Then I should see the following options: "Add Photo", "Set as Primary", "Edit Photo", "Delete", "Child Details"|
|Given user is on the "Photo Gallery" page | When the user highlights the first photo on the list (primary photo) | Then "Set as Primary" option is not an option in the Context menu|
|Given user is on the "Photo Gallery" page | When the user highlights a photo and selects "Set as Primary"| then the "Set as Primary" dialog box is displayed with the options "Set as primary?" and "Cancel"|
|Given the "Set as Primary" dialog box is displayed | When the user selects "Set as Primary?"| Then the dialog box disappears and the user is returned to the Photo Gallery page with the selected photo appearing first on the list|
|Given the "Set as Primary" dialog box is displayed | When the user selects "Cancel"| Then the dialog box disappears and the user is returned to the Photo Gallery page with nothing changed|
|Given user is on the "Photo Gallery" page | When the user selects a photo | Then they should be taken to the "Edit Photo" page - follow Edit Photo workflow (story #737)|
|Given user is on the "Photo Gallery" page | When the user highlights a photo and selects "Edit Photo"| Then they should be taken to the "Edit Photo" page - follow Edit Photo workflow (story #737)|
|Given user is on the "Photo Gallery" page | When the user selects "Add Photo"| Then the camera is launched - follow the "add photo" workflow (story #751)|
|Given user is on the "Photo Gallery" page | When the user selects "Delete Photo"| Then follow the "delete photo" workflow (story #735)|

h3. %{color:red}Defect%: May 10, 2011

* Clicking the BB "Back" button then returning to the "All Children" listed previously sorted by "Recently Added" resorts the list by "Name".
* Selecting "Go Home" then returning to the "All Children" listed previously sorted by "Recently Added" remains in the same sorted stated. (Does not meet Acceptance Criteria)

* "Sort by Recently Updated" is currently not sorting the list correctly. But this issue will be dealt with in another story.

* Pushing back to "Ready for Dev

h3. Narrative


As a user, I want the sorted stated of list of children and the selected child to be remembered across child record views So that the software is more usable

h3. Acceptance Criteria


|_.*Given*|_.*When*|_.*Then*|
|The list is sorted according to some criteria | The user returns to the list after viewing a particular child's record | The list should remain in the same sorted state |
|The list is sorted according to some criteria | The user returns goes back to the main screen | The list should be sorted by name when viewed the next time|
|The user selects particular child's record for viewing | The user returns to the list screen | The record of the child selected should be highlighted | Assuming that if we cancel the sync we need not roll back the records which are succesfully synced. If the cancel is clicked in the middle of synching a record, that record is only rollbacked to the original state and all the previous records which have synced successfully will not be rollbacked. Need to spike a bit and come up with a solution where the current record under sync is rollbacked if cancel is clicked and all the succesfully synced records should not be rolledback

Sync doesn't cancel when you try to cancel a sync. It shows that the sync is still active. In order to cancel the sync, you have to go to 'synchronize' from the main menu. When you do that it says 'other process [ Child Sync ] is Still Runing. Do you want to Stop it?.'

This most frequently happens when choosing 'Sync Individual Record' from child record view.



This story is to:

* allow the user to cancel the sync
* try to isolate why sync hangs when trying to 'sync individual record'
* change 'sync is still runing' error message to "Attempting to sync. Press OK to stop the sync process."




h3. Acceptance Criteria

|Given|When|Then| Remove tabs and put list on right hand side; assume UI widget to leverage

Right now, the only information that is visible on a form is whatever is included in the field names. Because it’s very likely that forms will need detailed help text included with them, there should be an option on the context menu of each form to show the form description, help text, and field help texts.

* When registering or viewing a child, there should be an option on the context menu that says "Show Form Description & Help Text"


As a
I want
So that


h3. Acceptance Criteria

|Given|When|Then| Current tabbed view looks fine. Do we have any other ideas to represent this data? We can remove the form sections which are empty from the tabs during the view of the child. During the "Edit Child" we can show all the forms as the user can add infromation in any form. 1. Don’t render the form sections which don’t have any data in them during the "View Child"

As a field worker I would like to be able to play back a recorded sound file so that I can transcribe the details into the field on the form.

*NOTE*:
** Companion blackberry stories are #189, #191
** Companion API stories are: #187, #188


h3. ACCEPTANCE CRITERIA

__show play button__

** *Given*: that a user is viewing / editing a child record that contains a sound file
** *When*: the user views the record
** *Then*: they should see a play button (black triangle pointing right)
** *And*: a stop button (black square) (disabled)

---

__click play button__

** *Given*: that a user is viewing / editing a child record that contains a sound file
** *When*: the user clicks on the play button
** *Then*: the application should playback the attached sound file
** *And*: the stop button should be enabled
** *And*: the play button should be disabled
** *And*: the user should still be able to continue editing / viewing the child record

---

__click stop button__

** *Given*: that the user is viewing / editing a child record
** *And*: listening to the attached sound file
** *When*: they click on the stop button
** *Then*: the playback of the file should stop
** *And*: and the play button should be enabled
** *And*: the stop button should be disabled Admin can already make change (not in estimate)