The ATI Broadcast app group is building a Facebook publishing app for the group America the Indivisible. Via this app an AITD trusted partner will be able to broadcast a message to multiply Facebook groups from one interface. This will allow the local groups in a region, of which there are many, to better communicate and mobilize toward specific actions.
1.0: If FB post is successful this message will appear. Assumes successful posting to all groups. 2.0: Takes use back to main screen (WF2) User story 6
If messages get throttled and/or fail, set up functionality to retry posting every hour. Figure out how this interacts with new message requests, i.e. how the queue works.
1.0: Text message to post goes here. TO Discuss: limits to size TO discuss: should we incorporate images here as well 2.0: Posts to groups in selected state User story 6
User should be able to post a message to a number of groups in the app.
This also involves dealing with potential server failures, e.g., if some messages fail to post.
@wtee has written a scraper that extracts group information from the Indivisible web site and finds the locations of the groups.
Currently, the scraper saves the data as a json file. It needs to be configured to save the data into the Mongo DB.
This is a continuation of #4
1.0: Assumes that the user can delete more than one post at a time; otherwise this switches to a radio button 2.0: Button becomes active upon selection of at least one post by user User story 8
1.0: State selected on previous page 2.0: Link to d/l a CSV file with group information including group name, FB group name and contact email; user story 3
Is there any need for an advisor configuration screen? For example, if we have e-mail notifications (which might be necessary in the case of retrying errors), we might want to allow the advisors to set the e-mail to use.
Our current testing platform on Google Cloud Platform is out of credits (due to some configuration mistakes by me... along with some misleading messages from Google). We need to either get more credits or switch, at least temporarily, to a different account.
1.0: User has logged in and been assigned to their state 2.0: User story 3 - triggers FB scrape from site; leads to wireframe 3 3.0: User story 6 - to FB post page, wireframe 4 4.0: User story 8 - to FB post deletion page, wireframe 5
The AITD partner group utilizes Google (GSuite) right now and wants to host there. We need to decide if that will be sufficient; my initial resource indicates that they may have to upgrade to the Google Cloud Platform which will require an additional expense from them. This is also tied to the language decision
1.0: Notification of intent to post. Includes number of groups included in this post. We should be able to tabulate based on active groups in the db. 2.0: Posts to groups in selected state 3.0 Returns user to edit screen User story 6
@alecfrancesconi @wtee
I have an idea for addressing the throttling issue.
To briefly recap the issue, Facebook throttles requests to 200 API call/user/hour. Posting a message to one group is 1 call, so posting to, e.g. 50 groups is 50 calls. A user is essentially someone who uses the app via Facebook. In the current proposed setup, there is only one Facebook user: the broadcast user.
Therefore, I propose that we use Facebook to log people in instead of Google. To stress, the people logging in won't need to grant the app any permissions. But this way, every trusted partner gives us another 200 requests / hour, lessening the risk we hit the limit.
If we adopt this, I apologize to @wtee , who has spent understanding Google login.
But switching now may help us in the future.
We need to build a way to scrape the group info with contact/social media information and download for a AITD trusted partner. Should be at the state level.
We know that the API supports multiple requests but can those requests span multiple groups in the same HTTP request and how will the access tokens work
1.0: User story 1. Assumes use of Google Security. Page flow may be different. App will authorize the user to the specific state they have permissions to post
1.0: If post only makes it to a subset of the listed groups 2.0: Listing of specific groups included in this post 3.0: Status of post to that group. Assumes we can get this level of granularity from FB API (it looks like we can). 4.0: Returns user to main selection screen (WF2) User story 6