I'm allowing users to send requests to other users inviting them to use my app.
The requests are sent out fine and invited users can find their way back to my app. The problem I have is deleting the requests once the user returns.
Firstly - When the user clicks on the request I'd like to delete it whether they interact with my application or not. This would involved sending a DELETE to this object on the graph: request-id_recipient-id. However, because the user might not have interacted with my app I don't have their user_id so I can't do this - the user is left to clean up my request themselves (not nice).
Secondly - Even when a user does interact with my app, I get their user-id and do the call to DELETE request-id_recipient-id I get this response:
(#200) The entity (class EntAppRequest) backed by id 267270596647001 cannot be seen by the current viewer 500****** (EntID: 267270596647001)
This suggests that the recipient of a request doesn't have permission to delete it with their access token? Is this correct because it seems a bit backwards to me. Or is this a situation in which I require the manage_requests extended permission? That too would seem strange to me because it would add extra permissions to the Auth box which the user might reject.
EDIT - Forgot to mention its a new app so its using Requests 2.0 and Requests 2.0 Efficient
Any help would be appreciated.
On the first problem. Given that you do not have the user-id for users who have not interacted with you app, there seems no way to delete the request sent to them. It seems like a "hole" in the design of facebook requests.
However, there seems to be one work around to clean up the requests. When you send the request using Javascript, you have access to user_ids of all users the request was sent to:
{
request: ‘request_id’
to:[array of user_ids]
}
You could cache that and after some pre-determined period, just remove that requests for all users.
Update: [Jan 12th 2012] This bug has been accepted and assigned here https://developers.facebook.com/bugs/202883726463009
Update: the bug has been marked as by design