Images fill up our MongoDB really quickly and becomes costly. Better to store it in a S3 or comparable bucket

• wanted to filter the experiences
• tried to click on the larger box to get more information
• wants more information on each experience
• didn’t really know what “subscribe”ing means
• what happens after subscribe?
• no feedback right now for not having images (e.g. if filter returns no images)
• “damn, I can share this!”
• didn’t realize there were more questions after the initial one (thought it was a toggle on and already on yes);

mLab will be updating their MongoDB version to 3.6 on July 20th for their sandbox databases, which we use. Meteor 1.7 already has support for MongoDB 3.6 and it looks like it'll be a pretty easy upgrade to do so after mLab takes care of the databases on their end.

Repro: run meteor reset and restart your server, throws an error

To reproduce: create an experience, start it to make an incident, go to home page, click on "participate" button in that experience's banner at the top.

• See the _sendPush or notify functions
• Based on our testing, I'm thinking send once in the morning, ~9am and once in the evening ~5pm?

On startup, the BackgroundGeolocation package receives a configuration object as follows (truncated for brevity):

{
      ...
      // HTTP / SQLite config
      url: `${ Meteor.absoluteUrl({secure: false}) }api/geolocation`, // submit location updates to
      backend route
      method: "POST", // submission method
      params: {
        userId: Meteor.userId()
      },
      ...
}

As part of the HTTP setup, we pass the reactive data source Meteor.userId() so that we know who the location updates are triggering for. Its value will update after a user logs in (since its a reactive data source), but the updated value is not sent to the location tracking package. This causes the current installation flow to become:

1. Install application and give necessary permissions (this causes the BackgroundGeolocation to be configured with Meteor.userId() as undefined).
2. Log in or create account
3. Force quit application and launch again (this time, Meteor.userId() will be the logged in user's ID and the BackgroundGeolocation package is configured correctly).

Instead, BackgroundGeolocation should reset its configuration every time it detects a user has logged in/out of the application. There is already logic on the server to handle if location updates are coming from an application without a user logged in.

This is a known bug, and does not affect location tracking. Regardless, this issue should be fixed before larger-scale deployments.

For experiences like sunset, we won't have their updated weather information unless they are moving... do we care about this? just something to think on as we could have non location affordances update separately?

:(

Requirements:

• users
• experiences
• example participation (e.g. images + text)
• sample geolocation data

• fix up debug page (.5)
• once a user participates remove them from the experience (.5)
• end the experience once it is done (1)
• show a user's previous experiences on the results page (.25)
• wait times between experiences (.25)

Calls to it are currently commented out, since it was doing wonky things with adding more submissions than situation.number specifies.

Kapil:

Critical incident! I’m currently commuting up on lakeshore drive and got a Notification to participate in half half travel. But my location updated before I could participate, so when I go into the app all I see is a blank screen

Leesha

She opened the new experience (it was a blank white screen), she opened and reclosed the app. Opening it again, she got the experience but then was immediately taken off.

Logs

018-07-25T15:57:19.087277+00:00 app[web.1]: �[32m[info]: user drgd3XW5Dmp6DLw7M | userAvailability: {"rDuzhNBNmKLWEHJZn":["Hand Silhouette"]} | can participate? true�[39m

2018-07-25T15:57:19.161428+00:00 app[web.1]: �[36m[cerebro]: Sending push notifications to drgd3XW5Dmp6DLw7M�[39m

2018-07-25T15:57:19.161488+00:00 app[web.1]: �[36m[cerebro]: {"title":"Event Body Mirror is starting!","text":"Your situation made you available to participate in Body Mirror!","iid":"rDuzhNBNmKLWEHJZn","route":"apiCustom/rDuzhNBNmKLWEHJZn/Hand Silhouette"}�[39m

2018-07-25T15:57:20.189824+00:00 app[web.1]: �[32m[info]: POST to api/geolocation: {"location":{"coords":{"speed":-1,"longitude":-87.64014906963257,"floor":null,"latitude":41.939711757587574,"accuracy":65,"altitude_accuracy":10,"altitude":183,"heading":-1},"extras":{},"is_moving":true,"odometer":216990.3,"uuid":"5B0233E5-CD88-46F6-B8F6-9B1EF2A187E5","activity":{"type":"on_foot","confidence":66},"battery":{"level":0.9200000166893005,"is_charging":false},"timestamp":"2018-07-25T15:57:19.856Z"},"userId":"drgd3XW5Dmp6DLw7M"}�[39m

2018-07-25T15:57:20.191282+00:00 app[web.1]: �[32m[info]: Location update for drgd3XW5Dmp6DLw7M: removing them from all availabilities and getting new affordances.�[39m

2018-07-25T15:57:20.242337+00:00 heroku[router]: at=info method=POST path="/api/geolocation" host=ce-platform.herokuapp.com request_id=956d3ccc-c47e-43af-ad02-95e177ef8a80 fwd="174.221.16.201" dyno=web.1 connect=1ms service=57ms status=200 bytes=1205 protocol=https

2018-07-25T15:57:20.698249+00:00 app[web.1]: �[32m[info]: Affordances successfully retrieved for drgd3XW5Dmp6DLw7M at 41.939711757587574, -87.64014906963257.�[39m

2018-07-25T15:57:20.709531+00:00 app[web.1]: �[32m[info]: triggering internal location update for: drgd3XW5Dmp6DLw7M�[39m

2018-07-25T15:57:20.722052+00:00 app[web.1]: �[32m[info]: user drgd3XW5Dmp6DLw7M cannot participate yet.�[39m

Solutions

• Might need finer grained logic for when someone should not be available. For example, if someone is notified, but didn't participate, they should unavailble for a small amount of time (like 2 minutes) vs if you did successfully participate, the amount should be longer (like 1 hour)

Problem

I've waited > 5 minutes for things to load the app, but I bet its downloading a WHOLE bunch of client assets.

Possible Solutions

How do we notify people to download the newest version of the app? Does sending a "notify" push, with a link to the bit.ly/install-ce work?

Change the loading screen so there is progress meter on how long its taking?

Can we manage hot code push more effectively? https://blog.meteor.com/meteor-hot-code-push-with-great-power-comes-great-responsibility-7e9e8f7312d5

1. making sure the client side files are really small, and that the files that don't really need to be client side are put to other folders.
2. managing which files we do hot code push. See nucleuside:live-update, which lets you hot code push specific files without reloading the whole app.

Primary Steps

http://www.amarendrasingh.com/tutorial/rename-xcode-9-project-completely-with-pods-and-bridging-header/2/

Extra Steps

CollectiveExperiencesEnterpriseExport.sh:

#!/bin/bash
xcodebuild clean \
    -workspace CollectiveExperiences.xcworkspace/ \
    -scheme CollectiveExperiences

xcodebuild \
    -workspace CollectiveExperiences.xcworkspace \
    -scheme CollectiveExperiences \
    -archivePath build/CollectiveExperiences.xcarchive \
    archive

xcodebuild \
  -exportArchive \
  -archivePath build/CollectiveExperiences.xcarchive \
  -exportOptionsPlist exportOptions.plist \
  -exportPath CollectiveExperiences-export

Had to use "+" to find the NewName equivalent. Then used "-" to remove the OldName version

There was an extra OldName.a file, so I made it optional? Not sure if this was neccessary.

Had to change OldName -> NewName in pods-release.xcconfig and pods-debug.xcconfig

Had to change OldName -> NewName in Compilesources.
by looking for old references to plugin sources grep -r ce-platform/Plugins ., going into the file vim CollectiveExperiences.xcodeproj/project.pbxproj and then changing every instance to the NewName :s/ce-platform/CollectiveExperiences/g

Idea from Haoqi at the end of Spring 2016: We should have a set of experiences that demo the capability of the API, like how D3.js has a bunch of demos on their homepage.

We could set these as the fixtures so that on server start you get a variety of experiences that touch all the existing functionality.

I've seen 3 or 4 submissions created, when situation number is 2.

Look for when submissions are updated

[info] Submissions DB Changed sometimes gets printed 3 times or 4 times

The issue in inserting extra submissions, and with new _ids, happens along these chains of funcitons

adminUpdatesForRemovingUsersToIncidentEntirely
adminUpdatesForRemovingUsersToIncident
->  _removeUsersFromAssignmentDb
----> checkIfNeedFailed
------> addEmptySubmissionsForNeed gets called, and adds needNumber submissions everytime

My question is when should 1) be called, 2) what does need failed mean, 2) why delete needs and recreate them? 3) why add empty submissions if so?

• checkIfNeedFailed gets called twice, since _removeUsersFromAssignmentDb gets called multiple times, since admintUpdatesForRemovingUsersToIncident

Problem: Need a human readable name to display in templates. Jan-pingpongposeur might be okay, [email protected] is not really great... Not sure yet if people can identify the people participating.

Possible Solutions

• New fields where you type your name
• Check on username before creation
• OAUTH Login with FB or Google

get the error message: 'Can't get executor for query { files_id: ObjectId('5a07798f6ce25b0800871962'), n: { $gte: 0 } }'

This is because of how we set a single active experience on experience ids.

It seems like the home screen is waiting on some subscription that isn't loading, causing the "Loading..." message to display permanently.

Repro: Logout and go to home screen, create a new account and go to home screen

docker image doesn't have graphicsmagick on it, so right now each time we need to do

$ docker exec -it ce-platform apt-get update
$ docker exec -it ce-platform apt-get install graphicsmagick -y

which sucks. Also, I had to dump our old db for this work so need to restore that at some point

1. Since its already being sensed, why not add it in?

The obstacle it would overcome right now, is that many people were getting notified while in a car. So it would potentially cut down the false-positive rate (based on the anecdotes)

This gets logged currently, from the background location package. Its a matter of capturing the JSON output, and storing it in the user's affordances, and updating the detector building blocks to include is_moving or in_vehicle, etc.

I believe that MongoDB supports the storage of functions directly in the collections (see https://stackoverflow.com/questions/36466462/storing-functions-in-mongodb-in-different-collections), which would allow us to store callbacks and detectors there and not need to eval them within the progressor or the detector evaluation.

This is quite minor, but it may be easier to maintain code by building it this way rather than the string eval we do currently.

See: createNewExperiences.js

/* FIXME: Experiences are not workable, as the detector ids have changed
 * TODO: Write a storytime construction helper / macro which can generate different versions of storytime structure

this causes error

This is being called on the participate and result templates occasionally. Seems to be as a result of some needed subscription refactoring (namely this.data is undefined) -- this happens specifically when navigating back from results to participate.

Detectors in imports/api/Testing/testingconstants.js should be re-written using the new categories for Yelp v3. I think the best time to do this will be after Ryan finishes up with Affinder's transition, but note that we will not be able to test once the endpoints shut down on June 30, 2018.

but mobile app is fine. Weird. Low priority, since works in mobile app.

this happens on local in the browser as well

affordanceaware is already giving us city names through the Weather API. Although "Dexter, US" is not really all that helpful. "Dexter, MI, US" would be more helpful.

'pressure': 993.1, 'sea_level': 1026.16, 'grnd_level': 993.1, 'humidity': 42, 'temp_kf': 0}, 'weather': [{'id': 500, 'main': 'Rain', 'description': 'light rain', 'icon': '10n'}], 'clouds': {'all': 76}, 'wind': {'speed': 3.56, 'deg': 93.0067}, 'rain': {'3h': 0.07}, 'sys': {'pod': 'n'}, 'dt_txt': '2018-08-01 00:00:00'}, {'dt': 1533092400, 'main': {'temp': 294.387, 'temp_min': 294.387, 'temp_max': 294.387, 'pressure': 993.11, 'sea_level': 1026.03, 'grnd_level': 993.11, 'humidity': 55, 'temp_kf': 0}, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01n'}], 'clouds': {'all': 0}, 'wind': {'speed': 3.02, 'deg': 125}, 'rain': {}, 'sys': {'pod': 'n'}, 'dt_txt': '2018-08-01 03:00:00'}, {'dt': 1533103200, 'main': {'temp': 290.214, 'temp_min': 290.214, 'temp_max': 290.214, 'pressure': 991.97, 'sea_level': 1024.93, 'grnd_level': 991.97, 'humidity': 81, 'temp_kf': 0}, 'weather': [{'id': 801, 'main': 'Clouds', 'description': 'few clouds', 'icon': '02n'}], 'clouds': {'all': 24}, 'wind': {'speed': 0.65, 'deg': 148.002}, 'rain': {}, 'sys': {'pod': 'n'}, 'dt_txt': '2018-08-01 06:00:00'}, {'dt': 1533114000, 'main': {'temp': 288.559, 'temp_min': 288.559, 'temp_max': 288.559, 'pressure': 991.54, 'sea_level': 1024.75, 'grnd_level': 991.54, 'humidity': 83, 'temp_kf': 0}, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01n'}], 'clouds': {'all': 0}, 'wind': {'speed': 1.3, 'deg': 234.005}, 'rain': {}, 'sys': {'pod': 'n'}, 'dt_txt': '2018-08-01 09:00:00'}, {'dt': 1533124800, 'main': {'temp': 291.467, 'temp_min': 291.467, 'temp_max': 291.467, 'pressure': 991.28, 'sea_level': 1024.46, 'grnd_level': 991.28, 'humidity': 78, 'temp_kf': 0}, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01d'}], 'clouds': {'all': 0}, 'wind': {'speed': 1.81, 'deg': 250.508}, 'rain': {}, 'sys': {'pod': 'd'}, 'dt_txt': '2018-08-01 12:00:00'}, {'dt': 1533135600, 'main': {'temp': 299.573, 'temp_min': 299.573, 'temp_max': 299.573, 'pressure': 991.28, 'sea_level': 1024.12, 'grnd_level': 991.28, 'humidity': 55, 'temp_kf': 0}, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01d'}], 'clouds': {'all': 0}, 'wind': {'speed': 3.22, 'deg': 291.504}, 'rain': {}, 'sys': {'pod': 'd'}, 'dt_txt': '2018-08-01 15:00:00'}, {'dt': 1533146400, 'main': {'temp': 302.461, 'temp_min': 302.461, 'temp_max': 302.461, 'pressure': 990.39, 'sea_level': 1023.1, 'grnd_level': 990.39, 'humidity': 40, 'temp_kf': 0}, 'weather': [{'id': 801, 'main': 'Clouds', 'description': 'few clouds', 'icon': '02d'}], 'clouds': {'all': 12}, 'wind': {'speed': 5, 'deg': 298.504}, 'rain': {}, 'sys': {'pod': 'd'}, 'dt_txt': '2018-08-01 18:00:00'}, {'dt': 1533157200, 'main': {'temp': 302.447, 'temp_min': 302.447, 'temp_max': 302.447, 'pressure': 989.7, 'sea_level': 1022.34, 'grnd_level': 989.7, 'humidity': 34, 'temp_kf': 0}, 'weather': [{'id': 803, 'main': 'Clouds', 'description': 'broken clouds', 'icon': '04d'}], 'clouds': {'all': 76}, 'wind': {'speed': 5.36, 'deg': 269.007}, 'rain': {}, 'sys': {'pod': 'd'}, 'dt_txt': '2018-08-01 21:00:00'}], 'city': {'id': 4990797, 'name': 'Dexter', 'coord': {'lat': 42.3384, 'lon': -83.8886}, 'country': 'US', 'population': 4067}}}

To reproduce: create a new experience, start it, and go to the home page. It does not show up with a big "participate now!" button in blue at the top, but it does show up as an experience a person can view the results of below.

CE Platform should be the execution engine alone while another tool exists for OCE composition. This tool may include Affinder and other features to interact with Collective Narratives

This is not helpful, its irritating to the user. Remove this notification from happening daily.

Will work on this after #57

e.g. avoid dem white screens, images disappearing, etc.

We should expect people to have possibly a lot of these, so even though they won't be modified that often this could get bad.

• show that a photo is loading in results page
• if a user's location hasn't updated in a while remove them from availability
• send notifications to open/close app in the morning/evening to restart location tracking

Currently difficult for me to debug push notification based bugs, since I can't do it during development.

WIP: See dev-push-notif branch. Currently struggling with the keys/certs, they make the app crash.

See push.js, where the key and cert data are imported. Some how alter the build-dev script to use development certs instead of production?

Specifically, cerebro and location-engine have some issues, but we need to audit for 1.3 compatibility and proper imports.

(so we know freshness of data / how long they've been there)

https://github.com/NUDelta/ce-platform/blob/stablestudy1.0/imports/api/testing/testingconstants.js#L386

Not sure if this matters for functionality

From a previous PR, we should capture these changes and make sure these fixes are guarded by tests.

Fixes to Cerebro Server:

• Progressor [progressor.js] now imports methods like notify and adminUpdates [progressorHelpers.js] which were being called in this file, but were failing before here. Now, people are notified after an experience is finished (notify) and people's participation now is recorded in the appropriate places (adminUpdates)

Suggested Test Cases:

it('should notify all participants after experience has ended')

// covered by end-to-end test
it('should remove the incident from active incidents in users profile')

// covered by end-to-end test
it('should add the incident to past incidents in users profile')

// ??? - not sure about current functionality
it('should remove the uid from the availability for that incident, since they are not eligible after participating')

it('should remove the uid from the assignment for that incident')

it('should set users profile to last participated to pretty recently')

CE currently makes a query to Affordance Aware, which is a Flask app running on another Heroku server.

To make the system easier to maintain, Affordance Aware should be integrated directly into CE. This would require a bit of re-writing code into Javascript, but since its mostly requests it shouldn't be too bad.

just hangs at the meteor screen

/admin/location doesn't work and there are way too many locations in the locations db (e.g. duplicates from the same person and from people who don't exist anymore)