This is a high level view of the Welcome screen requirement.

• As the next step let us try implementing the day selection and
  checkbox on accommodation and transport (ref: screenshot attached)
• For now do not worry about the collection / tables for
  accommodation / transport, we will store the accommodation / transport
  as a boolean field in the User object to see if the User has requested
  the services. Hopefully in the next iteration we will be expanding on
  both the accommodation and transport details (the number, time, type
  etc).
• We will need to keep track of the days the user is visiting,
  currently for this specific application I am just using a boolean
  array of 14 days, marking true / false for the days the user wishes to
  attend and store it in the user object.

We should have some amount of significant data on the completion of #10 and #11 , which means after those two tickets, we will need to see the basic administrative interface where we can filter the people who registered and filter them based on the various parameters.

Therefore we will need to get a timeline on when the interface can be built to be demonstrated. Also do mention if you ( @raghavneesh ) would like any other data from our end, which is missing out or preventing you from building the administrative front end.

@cherrymathew , You will need to if necessary, describe any explicit details that might be needed in the Administrative UI. For now I am assigning the ticket to you and once you are done with filling up the necessary gaps (if any), you shall assign the ticket back to @raghavneesh .

Currently if a user tries to verify by Phone it gets rejected, the regular expression does not allow certain patterns due to the limitation of the 10 digits for a phone number check in the current one.

Preferably a regex like [+0](0)?\d{10}[\d]* would be nice to allow for some flexibility especially when numbers are international or has country code

Example matches

09876543210
+916789875671
+9128907896781

P.S: I have not hard tested the regex so do verify it before applying.

= $TITLE =

---- dataentry signup ----
type_hidden : Talk
title : $TITLE
by : $NAME
email_hidden : $EMAIL
other_hidden : No
othname_hidden : No
projector_hidden: "Yes, I need it" |
"No, I don't need it"
tool_hidden : "No, I don't need any tools" |
"Yes, I need tools"
toolSpec_hidden : $FREEFORM
else_hidden : No
duration : $FREEFORM
abstract_hidden : ""
speaker_hidden : ""

descript_hidden : ""

I got error then when I accessed the welcome screen after the recent pull.

Here is the stack trace

/home/fox/dev/node/hh-appserver/models/Token.js:37
                if(token.isExpired()){
                        ^
TypeError: Cannot read property 'isExpired' of null
    at Promise.<anonymous> (/home/fox/dev/node/hh-appserver/models/Token.js:37
:11)
    at Promise.<anonymous> (/home/fox/dev/node/hh-appserver/node_modules/mongo
ose/node_modules/mpromise/lib/promise.js:177:8)
    at Promise.emit (events.js:107:17)
    at Promise.emit (/home/fox/dev/node/hh-appserver/node_modules/mongoose/nod
e_modules/mpromise/lib/promise.js:84:38)
    at Promise.fulfill (/home/fox/dev/node/hh-appserver/node_modules/mongoose/
node_modules/mpromise/lib/promise.js:97:20)
    at Immediate.cb (/home/fox/dev/node/hh-appserver/node_modules/mongoose/lib
/query.js:1150:30)
    at Immediate._onImmediate (/home/fox/dev/node/hh-appserver/node_modules/mo
ngoose/node_modules/mquery/lib/utils.js:137:16)
    at processImmediate [as _immediateCallback] (timers.js:358:17)

When you try to save a talk with a null date value (since it is possible for the user to defer the preferred date of presenting the talk), the values are not saved on the server side.

Can you look into this and let me know why this is happening?

We will need to design the JSON for this above screen, this screen appears only if, the user selects that they require "Accommodation" from #3 screen.

Over here we have the following fields

1. Accommodation Type (Spinner) - The values need to come from the server for now the values are

   • Room
   • Bed
   • Tent

   These values need to be available via a GET , which if fails (like due to connectivity loss) will be populated by a default set which will be cached locally in the phone.

2. Start Date (for the Accommodation) - Date field of the format dd-MM-yyyy

3. Number of Days (to book the Accommodation for from the Start date) - Currently just an integer value

4. Number of Beds: Which is basically the number of people who are coming in for the accommodation.

As usual, when then user presses the "Next" button all of this data will be pushed into the server via a POST.

Expected date of completion: 2015-04-09

We will need to design the JSON for this above screen, this screen appears only if, the user selects that they require "Pickup" from #3 screen.

Over here we have the following fields

1. Location (Spinner) - The values need to come from the server for now the values are

   • Location 1
   • Location 2
   • Location 3

   These values need to be available via a GET , which if fails (like due to connectivity loss) will be populated by a default set which will be cached locally in the phone.

   For now I do not have the valid default values list of places, so we can use some filler values which can be changed later on.

2. Arrival Date - Date field of the format dd-MM-yyyy

3. Arrival Time - This will be expected time of arrival in HH:mm format, which means we will be using 24 Hour time format starting from 00:00 to 23:45, the time intervals will only be available in 15 Minute intervals, so valid intervals are 00, 15, 30 and 45.

   Some Examples

   • Valid Times: 06:15, 14:30, 12:00
   • Invalid Times: 6:15 AM, 14:20

4. Number of Seats: Which is basically the number of people who are to be picked up from the location.

As usual, when then user presses the "Next" button all of this data will be pushed into the server via a POST.

Expected date of completion: 2015-04-09

This is the screen shown to the user after the registration. At the very bottom you can see that there is a "Confirm" button when the user clicks this, I would like to sent a JSON to the server indicating the user has confirmed their presence at the event.

{
  "hhtoken" : "NcZpPwmTpzieU84zKBKBBrpNvmwHgyHKRzrJCSab8iDl8KkAsHpwkFfKXCQVEf",
  "confirmed" : 1
}

This should be stored in the User.js model.

Hi Avneesh,

Do you think we could have an "official" documentation of this, so we can publish it for other apps (like IOS et. al) ?

https://twitter.com/santoshrajan/status/597669708679090176

The details of the various JSON API expected from the Talk Screen

The template for this requirement is driven by the implementation of
this form:
http://hillhacks.in/signup

We select relevant fields from this form and push them to docuwiki.

The following details regarding people attending are required
to be transferred to the hillhacks docuwiki page in a Key/Value pair
style. The template for generating this will be spec-ed out later.

The Main section should have the following key:value pairs:

Attend Main Conference Events: Yes | No
Attend Pre Conference Events: Yes | No
Present a talk, workshop or session: Yes | No
Teach in the school outreach sessions: Yes | No
Attend Learn To Code : Yes | No
Mentor at Learn To Code : Yes | No

A subsection within the main section should contain the following
key:value pairs:

interestlevel: "Yes I am coming, dates set!"

accommodation: Yes | No
publication: Yes | No
arrival: $DATE-OF-ARRIVAL
departure: $DATE-OF-DEPARTURE

PS: The fields may have more constraints, given that people sign up at
the last minute - we'll spec that out later.

Description of the Issue:

When multiple POSTs are done to /users/talk/add with the same data, the entries are duplicated at the server end.

Steps to reproduce:

POST the same JSON string multiple times to the server.

Expected behavior:

Every time a POST for adding in a set of talks comes in you will need to either

1. Check for duplicates and then update existing talks or add new talk if it does not exist.
2. Remove all the existing talks and add the new list that just came in.

Approach 2 is recommended, since every time the user wants to add talks they do it all in one bulk go when the "Next" button in the screen is pressed.

The current verification code is alphanumeric in nature. We will need to change this to a pure 6 Digit random number.

I noticed this issue while testing out the code today. When you do a post to user/talk/add to add a set of talks by an user. The expected response is a JSON Object of the form

{
  "key" : "value"
}

But the response only contained the "value" and the "key" part was missing due to which an exception was being thrown at the client end. For example, when I added a single talk, I got the following response

[
  {
    "__v": 0,
    "user": "5533c42aa3242ada7e421407",
    "created_at": 1429458055809,
    "needsTools": true,
    "needsProjector": true,
    "hasCoPresenters": true,
    "duration": "bhvfm",
    "event": "Unconference",
    "type": "Session",
    "notes": "cvff\n",
    "title": "gdsyjvch",
    "_id": "5533cc87a3242ada7e421424"
  }
]

The expected form of response would be

{
  "talks": [
    {
      "__v": 0,
      "user": "5533c42aa3242ada7e421407",
      "created_at": 1429459061916,
      "needsTools": true,
      "needsProjector": true,
      "hasCoPresenters": true,
      "duration": "bhvfm",
      "event": "Unconference",
      "type": "Session",
      "notes": "cvff\n",
      "title": "gdsyjvch",
      "_id": "5533d075df56c90b075bf636"
    }
  ]
}

I spent sometime on how to correct the issue and made the patch which is present below.

diff --git a/routes/users.js b/routes/users.js
index 5555740..9540952 100644
--- a/routes/users.js
+++ b/routes/users.js
@@ -100,8 +100,9 @@ router.post('/talk/add', global.isAuthenticated, function(req, res){
                        error : error
                    });
                }
-               res.json(results);
-           });
+               res.json({
+                   'talks' : results
+               });

        } catch(err){
            res.status(500);

Kindly review the patch and apply it, do let me know when it is done.

Here is the basic backend implementation that we need by 23rd March

• Login Screen (Done)
• Welcome Screen (Done)
• Accommodation Screen (Done)
• Pickup Screen (Done)
• Talks Screen (Done)

Once the basic workflow is done, we will work on the expansions on each of the functionality.

It would be nice to have the JSON API expected responses / requests. For the welcome screen.

Do let me know if what sort of request JSONs that you expect from the android side so that we can spec out the details.

We shall work on the details of oAuth based authentication once we are done with the basic flow of the application and we shall discuss on the implementation details.