Securing the API, so that it is safe and we can allow connections of remote services.

Current workflow to register as NGO:

1. register as normal user
2. contact admin, verify as NGO
3. have admin change ur user-role to 'ngo_admin'

Problems I see:

• hard for admins to keep track on NGO-requests when more (normal) users registering
• NGO requests need to be verified / checked (to not have app trolled by idiots)
• NGOs don't get the registration process without knowing/contacting an admin

Solution I'd propose: separate registration process for NGOs (as intended with 2nd button on landing page)

• workflow:
  • NGOs register as NGO-user right away
  • account blocked, notice that account need to be verified
  • admins get mail on new NGO request (can verify email, phone)
  • admin approves request -> email to NGO, account open
• technical
  • additional routes, extend/derive registration controller (minimal effort)
  • eventually STI on user model

Love to 👂 ur feedback on that. Could work on it tomorrow on the train.

Allow admins to edit all needs, including the user_id field setting the ngo.

• Use admin namespace for managing all resources globally
• Use ngo namespace to set up and manage (own) needs
• Use no namespace for public/volunteer view on needs
• Remove unused devise/registrations or users routes (currently double).
• Remove user/new (should not be possible due to devise)
• Update user forms for ngos and volunteers

Format registration form, add classic validates :terms_and_conditions, acceptance: true for terms and condition, privacy stuff etc.

Hey @loncie & @jakobmaul,

I updated the registration forms for NGOs and volunteers according to where2help/creative#2 (comment). Can you please have a look at the wording. I am missing the "why" text for NGOs here in german and here in english.

Can you please either change it and open a PR or just write it here and I'll update it afterwards.

This will surely cause some UX changes but the way I see it is:

• a link to add more categories in the add/edit form for a need
• the needs list isn't listed by need, but instead by categories, then needs (so the same need may be multiple times on the list)

The reason for this is that I don't even know if it's possible right now to create two needs at the same time. Even if you can, this is an unnecessary step for the user.

Currently US date an time formats are used. Please change to European Format:
Time: 00:00 - 23:00
Date: dd/mm

I think it's kinda hard to read #87CEC9 on #DDDDD6 or #EDEDE5.

The web interface still lacks proper navigation. I'd suggest a semantically different one for each user role, arranged in a classic bootstrappy way: logo (home), etc. on the left side and user specific stuff such as logout, profile, etc. in a dropdown in the right corner.

Means of navigation I think we need:

Already referencing a data model I suggested here

1. normal user
   • Logo/Home -> feed view
   • Termine -> list of needs a user signed in (to allow hopping out again)
   • Dropdown
     • Profil -> edit form to change email / telephone
     • Logout
2. ngo user
   • Logo/Home -> feed view (allows NGOs to check if other NGO already posted request)
   • Kalender -> calendar view
   • Events/Termine -> elaborate list view of events and needs (should be able to see who signed up, contact volunteers)
   • Dropdown
     • Profil -> edit form (maybe photo to better identify NGO)
     • Logout
3. admin user
   • Logo/Home -> feed view (allows NGOs to check if other NGO already posted request)
   • Users -> user index
   • Events -> events index
   • Events/Termine -> elaborate list view of events and needs (should be able to see who signed up, contact volunteers)
   • Logout

What do you think?

A GET to /api/v1/needs returns empty HTTP headers.

10-22 12:37:36.365 27554-28119/app.iamin.iamin E/PullNeedsTask: Access-Token = null
10-22 12:37:36.365 27554-28119/app.iamin.iamin E/PullNeedsTask: Token-Type = null
10-22 12:37:36.365 27554-28119/app.iamin.iamin E/PullNeedsTask: Client = null
10-22 12:37:36.365 27554-28119/app.iamin.iamin E/PullNeedsTask: Expiry = null
10-22 12:37:36.365 27554-28119/app.iamin.iamin E/PullNeedsTask: Uid = null

Seen this on staging.

The "Expiry" header for validating tokens is a date or a time span?

This is mostly brainstorming

• ngo workflow story
• ngo creating need
• ngo editing need
• ngo looking at need status
• ngo deleting need (and how does this affect volunteers)
• volunteer looking at needs
• volunteer filterning at needs
• volunteer signing up for need
• volunteer canceling need
• volunteer looking at needs they are part of
• volunteer need history

After logging in as an admin, heroku throws up the following:

2015-10-22T08:58:31.586286+00:00 app[web.1]: ActionView::Template::Error (undefined method `stringify_keys' for "/users":String):
2015-10-22T08:58:31.586288+00:00 app[web.1]:     14:   <% end %>
2015-10-22T08:58:31.586288+00:00 app[web.1]:     15: </li>
2015-10-22T08:58:31.586289+00:00 app[web.1]:     16: <li>
2015-10-22T08:58:31.586290+00:00 app[web.1]:     17:   <%= link_to 'Benutzer', users_path do %>
2015-10-22T08:58:31.586291+00:00 app[web.1]:     18:     <i class="fa fa-users fa-fw"></i> Benutzer
2015-10-22T08:58:31.586291+00:00 app[web.1]:     19:   <% end %>
2015-10-22T08:58:31.586292+00:00 app[web.1]:     20: <li>
2015-10-22T08:58:31.586293+00:00 app[web.1]:   app/views/application/_nav_admin.html.erb:17:in `_app_views_application__nav_admin_html_erb___611726443266481601_70087383669680'
2015-10-22T08:58:31.586294+00:00 app[web.1]:   app/views/application/_nav.erb:17:in `_app_views_application__nav_erb___2050051929353156741_70087384826140'
2015-10-22T08:58:31.586295+00:00 app[web.1]:   app/views/layouts/application.html.erb:41:in `_app_views_layouts_application_html_erb__361859152321145472_70087384494480'

Friendly forward admins after signing in to the originally requested resource. Otherwise impossible to include links in emails.

As discussed in #25 we should not require authentication for viewing needs. If clicking on a button to participate in a need, not signed in users should be forwarded to the sign in page and afterwards friendly forwarded back to the participation (as stated in #18 ).

This also requires changes to the navigation.

I would love to see this particular repository to be renamed to where2help.
I believe it is the last naming inconsistency related to the project's old name.
Any opponents?

We need the fields on the model and to display these.

Add list / index view for admins to view all needs (also old ones).

403 forbidden

The basis is there with i18n to get started with it

Are we missing a link or do i not get how this works?

Could be useful to send volunteers a reminder for needs they signed up for, including an entry (.ics) for their calendar. Could be digest mails (daily) or immediate ones.

Add a list / index view allowing admins to view all users (paginate the list).

Allow users to edit their profile (including email and password) and cancel their account. Devise already handles all this for us. So we only have to to two things:

• Link the respective views and adapt them to match the rest of the app
• Add the missing fields to the views and the parameters to Devise' strong parameters

Just add one

Seeing this on heroku

Didn't have the time to implement this during the hackathon: fulfilled need items should disappear from the list view + reappear if someone hops out.

List views for own needs for both, NGOs and Users. Currently linked to as 'Termine'.

I think "Helfen", green, with a check looks like I am already helping. Maybe "Ich will Helfen" without a checkbox, maybe a different color. I think of green in this context normally as a state of already committed. At the very least, I think the check should go away. But I also think the "x" may be ok to stay on "Absagen"

What do you think?

The green confirmation message is not necessary (content itself is already a confirmation) and just requires an additional click for closing. I suggest to remove it.

The following pic shows the current user flow of the android app:

But maybe we should force a user login/register on startup just like the web app since needs are not public anymore.

Documentation: More details on the /volunteerings end.
Extending endpoint: user#show : I would like to list all the needs the user is attending to inside the user profile.

When we hit submit after editing a need from the calendar, I get the following:
No route matches [PATCH] "/needs/51"

Allow admins to edit/delete users. Special Button for admin_confirmedfield.

Once a $period (e.g. week - should be configurable). Collect all new needs created since the last email (maybe by using a users_notified property on the needs) and send an e-mail with the description of all these batched needs to all the registered users.

Organisers should have access to "send notification to volunteers about this need" for a specific need immediately in case of urgency (e.g. volunteers needed in 2 hours).

People should be able to opt out of email notifications (we don't wanna be marked as spam).

Come up with a consistent and intuitive menu and general navigation (including wording) for the three types of users: ngos, admins, volunteers

Error responses vary by endpoint and deliver a mixed bag of german and english

auth/ is quite nice because of the detailed (and from the user understandable) infos inside the "full_messages" array.

  "errors": {
    "password": ["ist zu kurz (weniger als 8 Zeichen)"],
    "email": ["address is already in use"],
    "full_messages": ["Passwort ist zu kurz (weniger als 8 Zeichen)", "E-Mail address is already in use"]
  }

auth/sign_in on the other hand just returns "errors"

  "errors": ["translation missing: de.devise_token_auth.sessions.bad_credentials"]

So an option would be to use the error messages directly (But what about translation?):

  "errors": ["Passwort ist zu kurz (weniger als 8 Zeichen)", "E-Mail ist bereits vergeben"]

Or I assign my own set of strings to the keywords. (Would need a list of all the keywords though)

  "errors": {
    "password": ["too_short", "no_match", ...],
    "email": ["taken", "malformed", ...]
  }

We are still missing a license.
I suggest the AGPL v3.
You might wonder why?

The list view should be filterable:

• by category (dropdown)
• by place/city (text input)

Both should be ajax and can easily be integrated with the already in place pagination mechanism.

I'd also suggest both for the iOS and Android App too.

We need a need show view -> link from feed, showing description (yet to add) and map.
Static map image can be provided via Google Maps within seconds, but free contingent is limited.