Activities, Events and Reports

[asclines]

I think we need a different way of handling these things.

Currently

In our App Data spreadsheet we have these as follows:

Activity/Event

With keys:

• Approval Status
• Associated user(s)
• Category
• Date/Time
• Location
• Title
• Description
• Contact info
• Image

Activity Reports

With keys:

• Approval Status
• Associated User(s)
• Points
• Category
• Date/Time
• Location
• Title
• Description

With this setup I have a couple questions/concerns.

• Why do we need an "Activity"? Is there any scheduling needed there or is the student simply stating that they did it?
• If so wouldn't it make more sense to have Events and then Reports where a Report is used to track a students attendance at an Event or Activity?

With that here is my proposed way to handling them.

Proposal

Event

• Creator
• RSVPList <-All the students who RSVP'd for the event
• Category
• Date/Time
• Location
• Title
• Description
• Contact info <- Who to contact about the event (in case the creator isn't the one who should be contacted)
• Image

Report

Used to request points upon completion of an activity/event

• Approval Status
• Student
• Points
• Category <-Where we determine what kind of Activity/Event
• Date/Time
• Location
• Title
• Description
• Verification <- Maybe not the right word but this is where "proof" that they attended or completed something would be. Such as the professor contact info if they had a meeting with a professor.

Things that need to be worked out:

• How to manage who can join an event. The idea being that if a admin created the event, anyone can join it but it a mentor created it, only the mentor's students can join it.

Thoughts?

[StephanieKeck]

In terms of who can join an event, I was thinking this could be handled client-side. Events would have a field specifying what group they should be visible to, which the client would use to filter the view. Bad actors could unfilter it but mentors could make sure the event confirmation code only got to their students via means outside our app.

[asclines]

Okay so @StephanieKeck would it just check the creator of the event to determine that?

[StephanieKeck]

@asclines I was thinking each event would have an array of strings specifying who is allowed to view it. Perhaps if this list contained the keyword "mentees", the system would then check the creator name against the user's mentor's name.

[NilsG-S]

I think we need to be clear on why we need a given piece of data. I went through #29 and compiled my thoughts on the types of data discussed.

Activity/Event Data:

• When the event occurs. This is important because students need to know when to attend.
• Why do we need to know when it was created?

Activity Report Data:

• When the report was created. This is important because coordinators will need to go through and approve these reports, and we might want to put the oldest ones first.
• Why do we need to know when a report was approved by the coordinator?
• Why do we need to store when the student entered a confirmation code? As I see it, once we know that they've verified it we have all the information we need.

Account Data:

• Why do we need to store the date at which a student account was created/approved?

@asclines Would it be alright for me to edit the original post to add justifications?

[StephanieKeck]

Also, I think reports should have a date/time submitted field as well as a date/time approved/rejected field, along with a comments field for the coordinator to fill out in cases of rejection.

[NilsG-S]

@StephanieKeck Could you explain why you think the information you proposed is important to store?

[StephanieKeck]

@NilsG-S For the history feature. Coordinators and students would be able to look back through their history to see when things happened. It would also show which coordinator did the approving/rejecting. As @asclines mentioned, this would allow coordinators to sort requests by oldest, see the latest request they approved/rejected (in case they made a mistake), etc.

[NilsG-S]

@StephanieKeck That sounds reasonable to me. I'm going to be updating the proposal, so could you format your suggestions so I can copy them in easily?

Use This:

• [data field]
  • [explanation of what the field is]
  • [justification for why it is necessary]

[StephanieKeck]

I actually think we should separate the object which defines an event from the object that handles logging confirmation of that event, combining it with Reports. The object could look like this:

Request object:

• Type
  • 'event' or 'report'
• Status
  • 'pending', 'approved', or 'rejected'
• Student
• Category
• Points
• Date/time requested
• Data
  • Contains metadata based on type and category. If of type 'event', contains an id referencing the relevant event object. Otherwise, contains the fields the student filled out in the activity report. (Alternatively, we could separate out the activity report into its own object as well, having the request object handle approval requests for both, and store an id reference to the report object here.)
• Receipt
  • Date/time approved/rejected
  • Coordinator who approved/rejected
  • Comments I was thinking only coordinators would be able to write to this field, so that even if a bad actor changed the status to "approved" the report would still not show on their profile because the Receipt must be filled out. And maybe the confirmation code for an event could somehow give one-time access to write to this field in a secure way?

[asclines]

@StephanieKeck I agree with you on separating the two. Also I think there is a little confusion on report/request. I believe the report should be the request.

Scenario:

1. Student attends event
2. Student files report on event so they may receive points.
3. Upon handling the report, a mentor/admin may approve or reject the report thus generating a receipt
4. Student has read-only privileges on receipt.

Also, @StephanieKeck by simply preventing a student from having write access to the Receipt object using role-based security, we can safely assume that "no receipt" = "status:pending"

[NilsG-S]

Proposal

Event

• Creator
  • The user that created the event
  • Important for determining who can see the event
• Contact info
  • Who to contact about the event
  • In case the creator isn't the one who should be contacted
• RSVPList
  • All the students who RSVP'd for the event
  • Allows students to be given points for their attendance
• Category
  • The "type" of the event. One of eight categories defined by the CPCEED program
  • Allow the correct category in the student's points to be incremented
• Date/Time
  • When the event will be held
  • Let users know when they should attend the event
• Location
  • Where the event will be held
  • Allow users to navigate to the event
• Title
  • A string that gives some descriptive designation for the event
  • Give users a way of referring to the event. This could be important for signage guiding students to events
• Description
  • An explanation of what the event is about
  • Give students more information to use when deciding whether they want to attend an event
• Image
  • An image related to the event
  • Give students more information to use when deciding whether they want to attend an event

Report

Used to request points upon completion of an activity/event

• Approval Status
  • Whether or not the report has been approved by a Coordinators
  • Allows coordinators to control who gets points
• Student
  • The student associated with the report
  • Allow the correct student's points to be incremented
• Points
  • I'm actually not sure about this. Can they be worth more than one point?
• Category
  • Where we determine what kind of Activity/Event this report is linked to
  • Important for incrementing the correct category in a student's points
• Date/Time
  • When the report was created
  • Allow coordinators to sort event reports by oldest
• Location
  • Where the associated activity/event took place
  • Allow coordinators to identify the associated event/activity
• Title
  • A string that gives some descriptive designation for the associated event/activity
  • Give users a way of referring to the event/activity
• Description
  • An explanation of what the event/activity is about
  • Give coordinators more information to use when deciding whether they want to approve the associated activity/event
• Verification
  • "Proof" that they attended an event or completed something. Possibilities include:
    • A professor's contact info if they had a meeting with a professor
    • A verification code from an event
  • Coordinators need to have some grounds for accepting/rejecting a report

---

Notes on the Report object:

• I'm not sure why we need the points field

[StephanieKeck]

Re: points, my understanding is that events and activity reports can have any number of points regardless of category (at least when it comes to events)?

Ok, so how would this work with the confirmation-by-code system for events? My thought was the request object would just be created automatically, but the whole point of the code was so that coordinators would not have to approve events by hand. Would the code just be for preventing bad actors from being able to confirm the event client-side?

[asclines]

@NilsG-S you're right on the points key. That's leftover from when we were planning on them being multiple pints.

@StephanieKeck I believe we recently decided each activity/event would be one point each time.

[NilsG-S]

@StephanieKeck There aren't really enough points required to justify allowing for multiple points.

Do we have to get that system nailed down right now? I don't see it as necessary to this discussion.

[asclines]

@StephanieKeck The whole point of the code is to simplify the way coordinators handle events. To quote the email from the product owner:

... a way for activities to be pending until approved by program coordinators, ...

is one of the requirements.

Activities/Events still need to be approved by a human, we are just making a uniform, easy system for them to do that. Auto-approving is a nice feature though and in a future iteration we can present that idea to the product owner, that is just not in our currents scope.

[asclines]

@NilsG-S @StephanieKeck Let's put a pin the the points worth problem right now and assume 1 each. We can clarify with the P.O. later

[StephanieKeck]

@NilsG-S A few thoughts: We should track when an event was created. This info would be useful for, say, showing events that were just posted on the home page. I also suggest making images an array, as multiple images per event will probably be desired at some point.

Also, I don't think being awarded points for an event should be contingent on rsvp'ing, only confirming with the correct code. Storing who rsvp'd is purely so coordinators can track engagement. Events should also track who confirmed for this same reason.

Here's what I think should go in the report object:

Student (perhaps an object with name and uid) Type (event or activity report) Category Timestamp for when report was created Data For events, contains reference to event object and confirmation code. For reports, this is where any verification data, title, etc would go. Receipt (reference to object if it exists)

[NilsG-S]

@StephanieKeck Responses to your individual points:

• I don't see the utility of allowing users to see recently created events. Could you provide a user story where it would be useful?
• Allowing for multiple images could be useful.
• In terms of tracking engagement, I would think that keeping track of who was confirmed for the event would be superior to keeping track of who rsvp'd. While knowing both could be useful, I don't think we have conclusive proof that this is the case.

[asclines]

To clarify, @NilsG-S ,@StephanieKeck RSVP does not mean they get the points. They would have to fill out a report for the event. The RSVP list will be used for when the event is being set up. That way event coordinators can have an idea of how many people are showing up.

As for the keeping track of when the event is created, for the sake of being thorough.. it can't hurt to do that and we might be able to add some features like @StephanieKeck mentioned and it could be used for filtering events.

[NilsG-S]

I really like the idea of separating out the portion of events that was handling attendees. This would leave events as a purely informational object, while reports would handle changes to a student's points. Every time a student did something worthy of points, they would submit a report regardless of whether it was an event or an activity. The coordinators would then handle accepting/rejecting these reports. We could add more sophisticated mechanisms to handle multiple reports for the same event later.

I'm going to update the proposal accordingly.

[StephanieKeck]

I imagined rsvp'ing as having three functions: allowing coordinators to know how many people are coming to an event, allowing coordinators to track interest in an event, and allowing students to quickly see only the events they've expressed interest in (by rsvp'ing) through filters. Tracking both rsvps and confirmations will allow coordinators to see if there is a disparity between interest and attendance. It will help them to determine over time what they should expect when planning events. For instance, it can help them to determine that for a certain type of event, they typically only see 80% attendance compared to interest.

Another use for the date/time an event was created could be if a coordinator wanted to quickly go back to the last event they created because they think they might have made a mistake. Having a 'latest posted' event slot on the home page could also be a desirable tool for coordinators to drum up interest.

[NilsG-S]

@StephanieKeck You make a lot of really great points. All of the data that you've proposed we store has potential future applications. The only problem I have is that they are primarily for future applications. We can't have analytics unless we have an app, and we are less likely to have an app the more we get stuck on trying to figure out everything that we might need in the future. So I'm going to say, as a team leader, that we need to focus on the data required to implement basic functionality. But that doesn't mean we won't be implementing your ideas in the future. So I want you to keep track of them in an issue for database enhancement.

Here is the basic functionality that we should be going for:

• Calendar of events
  • Everyone can use this
  • Coordinators can create events that everyone can see
  • Mentors can create events that their mentees can see
• Filing of activity reports for events or other point worthy occasions
  • Only registered students can use this
  • Only coordinators can confirm activity reports
• Detect when students are qualified for scholarships

This is the core of what we need for the minimum viable product. The product info page of our wiki provides more in-depth information.

I'll be releasing a proposal with just the bare minimum of what I think we need. The following discussion should keep in mind that we are going for basic functionality only.

[StephanieKeck]

@NilsG-S Okay, so I assume this means no activity/profile routes or rsvp right now? Just log in/out, register, view/confirm/create events, submit activity reports, and basic coordinator management tools?

[NilsG-S]

Proposal

Event

Events would be stored in the events object. When a student user loads the "Events" page, the events object would be queried for both events created by coordinators and events created by their mentor. When a coordinator user loads the page, all events would be displayed.

• UID
  • A unique identifier for the event in our database
  • Will let us identify the event from among the many in the database
• Creator
  • The user that created the event
  • Important for determining who can see the event. The coordinator would also serve as the contact for the event
• Category
  • The "type" of the event. One of eight categories defined by the CPCEED program
  • Allow the correct category in the student's points to be incremented
• Date/Time
  • When the event will be held
  • Let users know when they should attend the event
• Location
  • Where the event will be held
  • Allow users to navigate to the event
• Title
  • A string that gives some descriptive designation for the event
  • Give users a way of referring to the event. This could be important for signage guiding students to events
• Description
  • An explanation of what the event is about
  • Give students more information to use when deciding whether they want to attend an event
• Images
  • Images related to the event
  • Give students more information to use when deciding whether they want to attend an event

Report

Reports would be stored in the reports object. When a student user loads the "Activity" page, the reports object would be queried for reports that are associated with their UID. When a coordinator user loads the "Pending Reports" page, the reports object would be queried for unapproved reports.

All Types of Reports

• UID
  • A unique identifier for the report in our database
  • Will let us identify the report from among the many in the database
• Type
  • Specifies whether the report is for an event or for another point worthy occasion
  • Depending on the type of the report, the database should store different information within the report object
• Approval Status
  • Whether or not the report has been approved by a coordinator
  • Allows coordinators to control who gets points
• Student
  • The UID of the student associated with the report
  • Allow the correct student's points to be incremented
• Verification
  • "Proof" that they attended an event or point worthy occasion. Possibilities include:
    • A professor's contact info if they had a meeting with a professor
    • A verification code from an event
  • Coordinators need to have some grounds for accepting/rejecting a report

Event Reports

• Event UID
  • The unique identifier for the associated event
  • Allows the report to be directly linked to its source

When the coordinator loads up the "Pending Reports" page, they would only see one item per event. All of the reports associated with that event would be visible as sub-items. The date would be retrieved from the event, for sorting purposes. When the coordinator approves the combined report, client-side code updates the indicated point values for all students that submitted reports, and toggles all associated reports to "approved" status.

When a student loads up the "Activity" page, the date of the report would be retrieved from the event, for sorting purposes.

Other Reports

• Category
  • The kind of occasion this report is linked to
  • Important for incrementing the correct category in a student's points
• Date/Time
  • When the report was created
  • Allow coordinators to sort occasion reports by oldest
• Location
  • Where the associated occasion took place
  • Allow coordinators to identify the associated occasion
• Title
  • A string that gives some descriptive designation for the associated occasion
  • Give users a way of referring to the occasion
• Description
  • An explanation of what the occasion was about
  • Give coordinators more information to use when deciding whether they want to approve the report

When the coordinator loads up the "Pending Reports" page, the date of the report would be used for sorting purposes. When the coordinator approves the report, client-side code updates the indicated point values for the associated student and toggles report status to "approved."

When a student loads up the "Activity" page, the date of the report would be used for sorting purposes.

[NilsG-S]

@StephanieKeck Points:

• I have no problem with the Activity route being in the MVP
• You are correct that RSVP isn't necessary at the moment
• Log in/out, register, and submit activity reports all sound good
• We won't have a mechanism to confirm Event Reports until we implement some kind of verification code system, which we don't need for now
• Coordinators basically need to be able to do two things:
  • Create events
  • Approve reports

[StephanieKeck]

@NilsG-S I have just a few thoughts on your proposal.

Firstly, I think we should completely get rid of recording approval status in the reports object and go with the receipts system we discussed earlier. It would simply be too easy for a bad actor to try to programmatically set the status to "approved" before submitting. Instead, coordinator approval or rejection would generate a receipt object which students only have read access to. The receipt would record status (rejected/approved), date/time rejected/approved, and any comments the coordinator wanted to add. The lack of a receipt object would indicate a "pending" status. The report object would have a uid reference to the receipt if it exists.

Also, I reccomend we create a separate activity object to hold the data associated with an activity report (category, details, etc., analogous to an event object). The report object can then reference its uid in the same way it would reference an event uid. I recommend eliminating the verification field in favor of a data field (which would contain the uid) and a confirmation code field (only relevant to events).

[asclines]

@stephaniekeck don't worry about bad actors. It's a good mentality, but for this MVP don't worry about it. As for the receipt, that can work in junction with the approval status. The receipt is only needed after a coordinator has responded. But we probably shouldn't worry about that yet. Not MVP material.

Also why do we need an activity? Won't an activity report be sufficient enough?

[StephanieKeck]

@asclines I just thought it would be cleaner to handle activity reports internally in much the same way we handle events. Event objects get posted to events, and activity objects get posted to activities. Report objects are more for requesting approval for an activity or event, but at least in the case of events, the actual data lives elsewhere. I thought it would make sense to have activity data live elsewhere as well. Both would be referenced from the report object in the same way by uid. It may be overkill. An alternative might be to have the data field hold the activity data

[asclines]

Yes but what I'm saying is we don't need activity objects. As the app, we don't care about activities, we aren't scheduling them or verifying them or nothing. All we care about with activities is the report so lets just have a report

[NilsG-S]

We've expanded events to cover all occasions that affect multiple students. So to me, the only reason we have an event object is as a planning tool. Multiple students need to see the information and they need to see it ahead of time. With other point worthy occasions there is only one student involved and they can plan it outside of our app, so generating an activity object would be a waste because all of the information is stored in the report.

[asclines]

Update, since the recent knowledge that a NodeJS server is going to be built, I do not think we really need a receipt object anymore except maybe as a sub-object of report for data organization purposes.

Thoughts?

[NilsG-S]

The main reason for having a receipt object was to prevent bad actors from setting approval status. Since that's now being handled through the back end I don't see a problem with the change.