Create endpoints to connect meetings to places

[darmai]

These endpoints will allow a user to approve of a place for a meeting or remove approval of a place for a meeting.

The information needed to make these endpoints functional:

1) meeting 2) place 3) user

Structure to be expanded upon below

[darmai]

I think this can be simplified to a single endpoint. The idea is to create an endpoint with the following structure

/meetings/[SHARE_CODE]/locations/[PLACE_ID]

This endpoint will accept POST requests with JSON as the body. The expected data will be a dictionary with one key: user. This value should correspond to the user id of the user submitting the approve/disapprove request for this location.

The API code will check for the presence of the location referenced by [PLACE_ID] in the meeting_locations table for this user and meeting id (referenced by share code). If the record is present, it is removed from the table. If the location is not present for this user, location, and meeting, the location (via place id) is added for this user and meeting

[mrpaulmason]

a) does the the user id get returned by the plan URL and is therefore available in the background? b) what's the pro/con of using the ID in the plan URL (which we've discussed is unique to each user in the plan) instead of the more 'generic' SHARE_CODE you have here?

maybe we should refer to the unique plan URLs as PURLs?

[darmai]

a) Either the user id will be in the plan URL or some other id that connects to the user will be available. As long as there is some id that connects directly to the user, we can obtain the user id to be used with this endpoint

[darmai]

b) Is a "plan" a distinct object from a "meeting"? I dont think we have enough of the technical details of how a plan is represented on the backend to discuss pros and cons just yet.

[mrpaulmason]

this is one reason why 'meeting' isn't the best name :) its really a 'connection' linking 2 or more people who make multiple plans to meet up and a SHARE_CODE makes sense for the single instance of 2 people texting.

However for "plans", we need a unique ID in a plan URL that reflects the user & plan -- which together implying a connection. So its starting to feel like this "plan ID" would make the SHARE_CODE unnecessary but let me know what you think when you read the rest of this.

Also -- important that user ID is obfuscated in the URL to prevent others from snooping into their other plans. DON'T want: meetable.ai/user1/plan2 MORE LIKE: meetable.ai/[USERSPLANID]

The pro-con question was for these 2 options /meetings/[SHARE_CODE]/locations/[PLACE_ID] key: user /meetings/[USERSPLANID]/locations/[PLACE_ID] (no key?)

per above, i'm not sure we even need SHARE_CODE anymore maybe using it with a key makes it harder for someone to reverse engineer?

[darmai]

After discussion with @mrpaulmason, we decided to use the endpoint structure suggested by Paul:

/meetings/[USERPLANID]/locations/[PLACE_ID]

this structure removes the need for sending the user id to the API. The user_id will be linked to the [USERPLANID] in the meeting_participants table. The USERPLANID will be a column in the meetings_participants table called plan_code. It will be a 6 character alphanumeric code that is unique to the meeting_participants table

[darmai]

This has been implemented following the approach above in #175

1) Added a plan_code column to the meeting_participant table 2) Implemented an endpoint with the following structure: /meetings/[USERPLANID]/locations/[PLACE_ID]

• creates an approval for a place (referenced by PLACE_ID) if approval not present
• removes approval for a place (referenced by PLACE_ID) if approval is present 3) Approvals stored in the newly created meeting_location table

Closing ticket