Iteration #2

Iteration #2

Initial Goals
Predicted Complications
Pair Programming
Testing
Progress Reports

##Group #####720NoCode

• Matt K.
• Peter H.
• Nic R.
• Jacob O.
• Mags C.

#####Schedule

• Matt: After 4 T,TH. After 2, M,W. Weekends good.
• Peter: Anytime after 4, except Sunday.
• Jacob: After 4, most weekends.
• Joseph: pretty much any time.
• Nic: Anytime after 4, not really Monday nights.
• Mags: Free T,TH mostly. Free after 4:30 M,F. W kinda busy. Weekends mostly open.

#####Communication

• We primarily communicate by simply talking since we have been good at getting our entire group together. Additionally, we have used email to communicate as well.
• We have been very careful with GitHub to avoid push/pull issues.

##Initial goals / plans: - __Overview__: We chose stories that seemed to be high priority to the customers after the previous iteration as well as some that were still revolved around finishing the foundation to ensure stories are "bullet-proof." Some also stem from feedback from KK. At the beginning of the iteration we emailed the estimates to our customers. With Steph, we confirmed she was okay with them the same day. We also discussed how editable she wanted the submission form to be and came to an agreement. Elena also approved via an email. This led to potential future stories, but she was on board for stories we had suggested. With this in mind, we went about the agreed upon stories. Main dependencies are listed below. We used previous estimates to help determine what stories could be accomplished in the given, shorter, iteration as well. As of 10/28, it seems our estimates are on track to be completed as well as they can be given the dependencies.

• Story: Make the submission form text editable.

  • This was a high priority for the customer, we want to ensure this is done.
  • While developing this, potential additional user stories were spawned. These include: seeing the submission form on the side while editing, integrating a sort of mark-down language system like this wiki uses for stylizing that the admin can do, and adding hidden questions that can later be unhidden to give the form additional future edit-ability.
  • Notified the customers of new additional stories. They can choose to prioritize them however they'd like. They only know the specifics of the hidden question story (via email), will fill them in on the others during the presentation.
  • On 10/28, verified that Steph wanted the current form text to go to the text area to be modified in the editor instead of other alternatives. Stopped by her office for the verification.
  • As of 10/29, this is completed. However, it may be worked on more in the future with the other stories.
  • Looks near-identical to the previous iteration as desired.

• Story: Get submission form "production" ready.

  • Involves making sure text doesn't run off the side for the submission list. Done as of 10/24.
  • As of 10/26, we have reached this point.
  • As of 10/28, we added more features based on feedback from KK and Kirbie after iteration 1. This includes adding a time stamp to the submitted data, moving the to the submission list page after submitting so they can see it worked, and standardizing using two names for the adviser as well (note, we only did it the other way in the first place because the original form did it).

• Story: Create different user types (admin, presenter, adviser, etc) so the view would be different based on the user.

  • Note: This story has dependencies. Until we get pages specifically to be used by all the types of users respectively, it is not practical to say we have made all the types of users.
  • As of 10/27, this is completed to the extent we can with the given dependencies. The only roles that were relevant to create at this point due to needing other stories fulfilled include Admin and presenter. Also, we do not use Google accounts for this yet.
  • Got our different current users to work with Google accounts as well as the built in accounts. This "fully" completes the story as we can generalize this knowledge to make the other users when they have their own specific features.

• Story: Have to be logged in to access pages beyond login and homepage with login button.

  • As of 10/27, we have reached this point. Attempting to access other pages re-directs back to the home page or log in page.
  • As of 10/19, this works with all our final additions made to the system (even the new submission list).
  • Will need to continue adding checks as more pages are added.

##Additional goals / hopes:

• Filter submission list based on users.

• Make this stuff only work for MORRIS Google accounts.

• Due to the time the main stories are taken, we will not likely get to these. That's fine as we never initially told the customers they would be done. These stories were just extra goals should we burn through our initial estimates.

• Joe of special forces gave us a prototype for the system where an admin can change the submission status via the submission list component. There are some flaws with it as it is not production ready yet. This is not a problem though since it was not an original story. Like won't focus on it too much during the presentation (despite how cool it is).

  • Fixed all known issues with this, so will make it a bigger deal during the demo.

• KK told us towards the end that she would like us to be able to run the application through Hiroku. We are doing what we can to make that happen.

  • 10/29: This is not happenening for this iteration. Time is lacking.

##Predicted Complications: - Being production ready for the form might not mean what our customers (Elena) wants it to mean. * Steph has approved only having the text of the submission form being editable. (10/23)

• Filtering out non UMM/UMN Google logins.

  • Not sure if we can prevent them from logging in, but we might be able to prevent them from doing things based on email.
  • Only part of our extra goals for this iteration anyway.

• Figuring out how access to page contents is restricted on a per-user basis.

  • For now, only focused on admin and presenter since they are not any contents specific to other users yet.

Notes after Iteration #1 presentation

It seems as though the customer liked the interface that we have, but was extremely apprehensive regarding how the form would be updated in the future (apparently minor changes are made every 2 years or so). Solutions to this suggested by the customer primarily included creating a control panel to effortlessly edit the form and have database models and views update automatically, or moving to using google as the primary means of data storage and handling as opposed to a database.

##Pair Programming - Here are a few of the various examples of pair programming: * Jacob and Matt testing/fixing the submission form after Angular updates. * Nic and Mags trying to figure out having different users. * Peter and Matt fixing some hard coding in the submission form. * Peter Matt and Nic working on restricting web pages to those who are logged in. * Jacob and Mags working on the submission form editor. * Jacob and Nic working on storing the submission form's text in the database. * Mags and Nic working on adding KK suggestions to the submission form. * Matt and Peter updating submission list to fix some of the displayed information. * Nic and Mags working on restricting admin pages to users * Jacob and various others working on modifying the front-end of the submission form to pull its text from the new endpoint. * Lots of combinations for testing throughout the iteration.

• Almost never had someone working completely alone without others to help or watch. Definitely had pair programming for more than 90% of the time.

##Testing / Manual Tests to Run - We write these as if they were instructions for future users to have reference for how we tested. We performed the relevant tests whenever a feature was modified/added and deemed ready for testing. In this way, all the tests below were likely performed multiple times. Absent of a specific date stating when it was tested does NOT mean it wasn't tested. On 10/29, went through and tested everything and communicated results as we worked together.

• To test the submission form storing data in the database, fill in ALL fields/options and submit. Check the database either through WebStorm or the browser to confirm all data was stored. Be very sure to verify each field in the schema is present and has appropriate value.
  • Check the sponsors box by only selecting a few of the checkboxes (not all!), make sure no nulls are stored. Additionally, click and unclick at least one checkbox, make sure no empty string is stored.
    • This has been tested and is no longer broken (10-28)
  • If it is known that the database is storing individual fields properly and just want to check that the submission shows up, the submission list on the submissions page can be checked.
  • All subform fields tested and are displaying data as intended (found and fixed a bug for how presenter email was saved) (10-28)
• To test editing of submission form text being stored to the database, make recognizable changes in ALL of the text areas. Hit the submit changes button. Verify the changes were made in either the browser or mongo plugin.
  • Can also now test by looking directly in the submission form.
• CSS and HTML are tested by visually confirming all the proper information is stored and is displayed correctly. Changes are made one at a time when implemented to verify they work as expected. THis is easily done with grunt serve updating the page instantly when saved. If they don't work as expected, we verify our code and knowledge of how it should work is correct.
  • Tested various times as we went along.
• To manually test not being able to access pages while not logged in, enter the routes of any and all pages that shouldn't be open to the public (submission form, admin page, submission list page, submission form editor), you should be redirected to the home page or the login page. If not, document the issue and make sure everyone is aware.
  • All pages redirect to login if a user is not logged in. Working as intended as of (10-29)
• To test the data-binding for the submission form and the submission form editor manually (or future forms), put the variable being data-bound to temporarily in the HTML. Proceed to change the variable where that variable is modified (on the page, not in the code!) while watching to check that the variable displays the appropriate changes. Be sure to remove the testing variable upon completion! Do this with each and every data-bound field/variable.
  • As of 10/29, all tested manually multiple times.
• To test that only the admin account can see the admin pages, log into a non-admin and try to access them by typing the page into the browser manually, they should re-direct you away. Then, sign in as the admin, should be able to get to the pages via links or typing into the browser. Also, try to access while not logged in at all, shouldn't be able to. Also, make sure only the admin accounts can edit the items in the submission list with the new status change features.
  • Only admin can access the admin and subformeditor page. Tested with all forms of users (admin, google, testuser, and no login). Working as intended as of (10-28)
  • As of 10/29, tested to make sure all areas the admin should see are only seen by admin, this includes Joe's new sublist editor.
• To test confirmation for submitting to the database on submission form or submission form editor, prepare either for submitting like usual, then hit submit; a confirmation window should appear. Try hitting cancel, you will go back to submission page and the database should not have vhanged yet; verify this through the browser or mongo plug-in. Also, hit submit and then confirm; verify that the page re-directs and the database IS changed.
  • As of 10/29, works for both submission forms.
• To test changing the approvals and statuses of submissions, sign into an admin account and make sure an edit and delete button appear. Change the status to a different status, hit cancel; no changes go through. Change status again, hit submit; change goes through and new color appears. If status is "Awaiting Adviser Approval", then approval should be false (No). If status is any of the other three, then approval should be true (Yes). Make sure changes between any statuses results in the appropriate approval changes. Try the delete button; make sure the submission is no longer in the submission list.
  • As of 10/29, all works as expected and makes appropriate changes in DB as well as front-end.

## Progress Reports #### 10-23 - Created the new wiki page. - Decided on user stories and informed customer of them. - Met with customer and got approval to only shoot for editable form questions. - Started removing hard coding in HTML submission form. - Fixed issue with sources and made it non-static. - Fixed abstracts going off the page on the submission list component. - Fixed user getting log-in page when logged in.

10-26

• Tested to make sure all data is stored properly to the database.
• Fixed issue with nulls showing up in the array of sponsors.
• Generated new routes a page for the list of submissions and an editor for the submission page.
• Generated an endpoint to store the submission form text.
• Created schema for aforementioned endpoint.
• Got data-binding working with the text areas in the front end of the subformeditor.

10-28

• Finished front-end for the submission form editor.
• Got the submission form editor to be able to display the current form text from the database.
• Made pages route back to the home/login page if a user is not logged in. This completes a story.
• Due to not being able to test HTML alone, went through the submission form HTML and read through making sure it is production ready (minus the changes needed for editable text). This finalizes the completion of a story.
• Added a timestamp to a submission when it is submitted.
• Added first and last name for adviser to match the presenters.
• Updated submission list to display yes/no instead of true/false.
• Got the database to successfully update the default form from the form editor.
• Asked Steph about potential options suggested for form editor. Went with the one she chose. (Put the text from the form directly into the text field.
• Prevent users other than admin from getting to admin pages.
• Added confirm for submitting submission form or submission form changes.
• Updated seed to have better examples for submissions.

10/29

• Finished pulling text to submission form from the database.
• Added Joe's prototype for having the Admin be able to modify certain attributes of a submission.
  • Note: It is a prototype and is therefore not production ready. Time allowing, we will try to make changes needed to demo it appropriately tomorrow. If we can't fix all issues or test it thoroughly, it will not be shown in detail.
  • Update: Most issues that it had have been fixed. We will likely show it off in a bit more detail at the demo.
• Updated new submission list to display timestamp.
• Various CSS stylings to get a tag to work appropriately with the database while still looking reasonable.
  • Looks nearly identical to the previous way we had it.
• Started trying to deploy with Hiroku. May not update back here with results, they will be seen at the demo.
  • Due to time constraints and needing Mitch, we are not going to be using Hiroku for the demo.
• Thoroughly tested the parts of the system that we said we'd have done.
• Got a google account to be an admin user. THis means we officially know we can support different users as desired through google. Matt's GMail is the admin.