-
Notifications
You must be signed in to change notification settings - Fork 308
Conversation
From #3460 (comment)
payment_instruction.json doesn't support batch subscription creation and it also exposes some extra information not relevant to this endpoint. So, I thought I'd leave it alone and ditch the redirection thing and add all functionality directly to this. |
So if that sounds good @rohitpaulk , @whit537, I'll go ahead and add |
Would appreciate a quick code review as well. :) |
raise Response(403, _("Please sign in first.")) | ||
|
||
else: | ||
participant = user.participant |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use get_participant
here to make sure the user exists, and that the authenticated user has the necessary permissions to access the endpoint. The current way this is implemented, looks like hitting www/~/aandis/subscriptions.json.spt
is not going to give me (logged in as rohitpaulk
) a 403/404, it is going to return my own subscriptions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah. I was yet to change that.
@rohitpaulk |
a97c089
to
2a35603
Compare
Added changes discussed. Yet to find a way around #3460 (comment) |
Alright. Fixed #3460 (comment). 💃 Ended up modifying this after digging for a couple of hours. Looks correct to me. Not really sure if this will happen on prod too. If it does, we should fix this in aspen. |
btw Fixing #3460 (comment) made github and other provider's sign up redirects to stop working. I am sensing it's an ssl thing. But it's way easier for development compared to setting up ssl. 😉 |
What users are subscribed to? |
Giving to teams @techtonik. See #3460 for details. :) |
!m @aandis :) |
@aandis First thing I notice is that we'll need some tests for this endpoint. |
Yep. That's next. Figured I should first review then write tests. :) |
That sounds strange. When I subscribe to something (especially for something), I expect to receive something. If I have a lot of subscribers, I automatically feel obliged to do something in exchange. If we are still for "giving with no strings attached" then maybe there is a better term? Facebook has "liking", newspapers and lists have "subscribing", and when we send money the closest term is "supporting", but if we want more involvement and more positive value on the receiver's end, how do we call it? "links" to the causes, so we "link" people with "projects" and use "routes" to send them gratitude in the emotionless form of money that can be used to do something good for them. =) |
@aandis Gotcha. |
@techtonik You raise a good point: over in gratipay/inside.gratipay.com#117 we decided to go with "payment instructions" instead of "subscriptions" (gratipay/inside.gratipay.com#117 (comment) notwithstanding). Presumably #3460 predates that decision. @aandis Let's go ahead and switch from "subscription" to "payment instruction" here. That'll line up with the database table and |
(Though we are no longer "for 'giving with no strings attached,'" post-gratipay/inside.gratipay.com#180 and pre-gratipay/inside.gratipay.com#423 .) |
|
||
slug = request.qs.get("team_slug", "") | ||
|
||
if slug: # Filter subscription info only for this team from the list. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this intended to related to the existing %team/payment-instruction.json.spt
API? Looks like it at least partially duplicates the functionality over there. Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only thing similar between them as of now is GET
with team filter. But team/payment-instruction.json.spt returns a different response which isn't really relevant to this api. This endpoint offers an additional GET
without a team filter to show all subscriptions of a user. Per #3909 (comment), we should maintain consistency in the api responses. Hence everything is implemented right here.
Alright, will do. :) |
8db0f72
to
eebf8f8
Compare
@aandis Yeah that's most of it. We'd need some tests to land a PR in Aspen, and Aspen is undergoing big changes right now so you can decide if you want to spend time on that. :) The workaround would be to do |
Cool. I'll look into it. Thanks :) |
Readme updated. 💃 |
@aandis Nice! Can you rebase this PR branch onto the latest master? Seems we have conflicts. |
0b3c069
to
d2d848a
Compare
d2d848a
to
7cce577
Compare
👍 |
README looks fine. I hard-wrapped the new paragraphs and added a missing space in 63c74dd. I think this is ready to go! Except that ... @rohitpaulk Didn't you say somewhere that you want to move to |
Not a blocker |
!m @aandis |
@whit537 If you have deployed this, can you confirm that |
(The second payment instruction is the one that changes in those screenshots—I guess including 0.00 tips is okay, so we can use this for the "Canceled" tab on the Giving page if we want. The first one to sudo room demonstrates the runaway dues.) |
Heh okay! I see now. All this time I had been hitting |
Learnt about http redirect methods in depth while overcoming this though. So all good in the end I guess. ;) |
The doc instructs to hit |
Ideally though, all these routes should work with |
Oh no! 🙀 Glad you figured it out. :)
#3916, ya? |
Still WIP.
Added
GET
to show all subscriptions of a user along with filtering on team slug.References #3460