FrancisG-Massey / Capstone2016

4 stars 0 forks source link

User / Trapline-user pages #157

Closed MrMJLee closed 8 years ago

MrMJLee commented 8 years ago

Need some help where to locate these pages on web.

ZoeUdy commented 8 years ago

I have an idea:

What if the contact page displays all volunteers with contact phone number and email? And contact page is hidden if not logged in as admin. Info can be displayed in a table with

We can still have our team contact information at the bottom of that page (in a horizontal layout instead), but it will not be available to the public (i.e. people not signed in)

sam-hunt commented 8 years ago

Hi all, we really need to knuckle down on our design so that MJ can implement it. At this point, it may mean compromising on one thing or another.

Let's look at how the possible use-cases for contact, user and trapline-user:

  1. Non-users who want to contact us about our project.
  2. Non-users who want to join the doc program as a volunteer.
  3. Users (usually admins) who want to see a list of all users.
  4. Users who want to update a user's details (99% of the time, this will be their own)
  5. Users (may be admins) who want to see the traplines a user is enrolled on.
  6. Users (may be admins) who want to see users who are enrolled on a trapline.

Please update this list if you can think of anything else.

sam-hunt commented 8 years ago

As for my opinion on this:

  1. Non-users who want to contact us about our project. We should keep the contact page as it is currently. Minimal identifying information.
  2. Non-users who want to join the doc program as a volunteer. We should keep the volunteer page as it is currently and link to doc. Minimal identifying information. If doc pick up the project, they should decide who's names should be publicly available (and do it on their page) not ours.
  3. Users (usually admins) who want to see a list of all users. We should have a "user list" page which can list all users visible to that user (all if admin) and their basic details, i.e. GET /user
  4. Users who want to update a user's details (99% of the time, this will be their own) We should have a "user details" page. This will show all of the user's stored details, and will allow the user to edit them if they have permissions. i.e. GET /user?id=42
  5. Users (may be admins) who want to see the traplines a user is enrolled on. There should be a link on the user-details and user-list pages which goes to the trapline-list page, filtered to their user id i.e. GET /trapline?user-id=42 I'd need to check the user-id parameter is enabled, but its easy enough.
  6. Users (may be admins) who want to see users who are enrolled on a trapline There should be a link on the trapline-list and trapline-details pages which goes to the user-list page, filtered to that trapline id i.e. GET /user?trapline-id=13 I'd need to check the trapline-id parameter is enabled, but its easy enough.

Let's hear all of the ideas, shoot questions, shoot criticism, shoot fast 👍

ZoeUdy commented 8 years ago
  1. is already implemented
  2. I think going through 6. is acceptable
  3. let's not deal with this right now and say that it is the responsibility of the site/database admin to change details as requested
  4. this is what I was suggesting
  5. already implemented
  6. this info could be moved, say to the screen which will have info on the mobile app?

I still think my plan as in the comment above is a good, simple solution

MrMJLee commented 8 years ago
  1. Contact us details will be in Contact page.
  2. To apply as a volunteer, a potential volunteer should visit DOC volunteers link via volunteer page (From my understanding).
  3. Rather put single dropdown lists as before when the admin menu is on click (Trapline and users). The users list will show all users distinguished by their assigned regions.
  4. This is currently no implementation of a normal user (non-admin) can edit his/her details.
  5. Currently not supported
  6. This will be done via a view volunteers link for in the trapline page.

I think there should only be one core feature on each page in the web app.

sam-hunt commented 8 years ago

I think there should only be one core feature on each page in the web app.

Ah yes I agree this is very important.

ZoeUdy commented 8 years ago

Related to #164