[API] Issue set Subscription #4193

New Issue

GiteaMirror · 2025-11-02T05:41:54-06:00

GiteaMirror commented

2025-11-02 05:41:54 -06:00

Originally created by @6543 on GitHub (Oct 26, 2019).

as title came up in https://gitea.com/gitnex/GitNex/issues/174

Originally created by @6543 on GitHub (Oct 26, 2019). as title came up in https://gitea.com/gitnex/GitNex/issues/174

GiteaMirror closed this issue

2025-11-02 05:41:54 -06:00

GiteaMirror commented

2025-11-02 05:41:55 -06:00

@6543 commented on GitHub (Oct 26, 2019):

API for issue subscription:

add POST /repos/{owner}/{repo}/issues/{index}/subscription
add GET /repos/{owner}/{repo}/issues/{index}/subscription

Or add option's to

GET /repos/{owner}/{repo}/issues/{index}
PATCH /repos/{owner}/{repo}/issues/{index}

@lunny @sapk

@6543 commented on GitHub (Oct 26, 2019): API for issue subscription: - add POST /repos/{owner}/{repo}/issues/{index}/subscription - add GET /repos/{owner}/{repo}/issues/{index}/subscription Or add option's to - GET /repos/{owner}/{repo}/issues/{index} - PATCH /repos/{owner}/{repo}/issues/{index} @lunny @sapk

GiteaMirror commented

2025-11-02 05:41:55 -06:00

@guillep2k commented on GitHub (Oct 27, 2019):

If we're having an API for adding/removing subscriptions, I think the endpoint should be prepared for two use cases:

The user him/herself subscribes to the issue, via e.g. GitNex.
The site admin subscribes the user.

In any case, the name of the user to subscribe/unsubscribe should be part of the request, independent of the presented credentials.

@guillep2k commented on GitHub (Oct 27, 2019): If we're having an API for adding/removing subscriptions, I think the endpoint should be prepared for two use cases: * The user him/herself subscribes to the issue, via e.g. GitNex. * The site admin subscribes the user. In any case, the name of the user to subscribe/unsubscribe should be part of the request, independent of the presented credentials.

GiteaMirror commented

2025-11-02 05:41:55 -06:00

@blueworrybear commented on GitHub (Oct 27, 2019):

@guillep2k
Why could not we just use login user as the subscriber? I don't understand in what situation that a user will need to subscribe/unsubscribe an issue for other user. 🤔

@blueworrybear commented on GitHub (Oct 27, 2019): @guillep2k Why could not we just use login user as the subscriber? I don't understand in what situation that a user will need to subscribe/unsubscribe an issue for other user. 🤔

GiteaMirror commented

2025-11-02 05:41:56 -06:00

@6543 commented on GitHub (Oct 27, 2019):

@guillep2k so an potinal field "user: " wich changes the default ctx.userID to the new "user" if the ctx.userID is admin ...

@6543 commented on GitHub (Oct 27, 2019): @guillep2k so an potinal field "user: " wich changes the default ctx.userID to the new "user" if the ctx.userID is admin ...

GiteaMirror commented

2025-11-02 05:41:56 -06:00

@6543 commented on GitHub (Oct 27, 2019):

@guillep2k wich version do you like more?
I like the /repos/{owner}/{repo}/issues/{index}/subscription endpoint ... but this is my opinion

@6543 commented on GitHub (Oct 27, 2019): @guillep2k wich version do you like more? I like the `/repos/{owner}/{repo}/issues/{index}/subscription` endpoint ... but this is my opinion

GiteaMirror commented

2025-11-02 05:41:56 -06:00

@guillep2k commented on GitHub (Oct 27, 2019):

@blueworrybear I'm all for automation. For instance, I can think of a webhook that automatically assigns certain users when a particular label is added to the issue/PR. I might be wrong, but I think that in general API is more likely to be used but the site admin (or really power users) that the general users themselves.

@6543 I have no real preference on the way the endpoint is constructed (I don't mean that it's not important, but I'm not familiar enough with this and other services' APIs to defend an opinion).
But if you'd want my ideas, just for the sake of statistics, I'd go for:

GET /repos/{owner}/{repo}/issues/{index}/subscribers
PUT /repos/{owner}/{repo}/issues/{index}/subscription
DELETE /repos/{owner}/{repo}/issues/{index}/subscription

The GET method would return all subscribers if you're site admin, but only you as a subscriber if you're not the admin.

Subscriptions to repositories uses GET/PUT/DELETE as well.

@guillep2k commented on GitHub (Oct 27, 2019): @blueworrybear I'm all for automation. For instance, I can think of a webhook that automatically assigns certain users when a particular label is added to the issue/PR. I might be wrong, but I think that in general API is more likely to be used but the site admin (or really power users) that the general users themselves. @6543 I have no real preference on the way the endpoint is constructed (I don't mean that it's not important, but I'm not familiar enough with this and other services' APIs to defend an opinion). But if you'd want my ideas, just for the sake of statistics, I'd go for: ``` GET /repos/{owner}/{repo}/issues/{index}/subscribers PUT /repos/{owner}/{repo}/issues/{index}/subscription DELETE /repos/{owner}/{repo}/issues/{index}/subscription ``` The `GET` method would return all subscribers if you're site admin, but only you as a subscriber if you're not the admin. Subscriptions to repositories uses GET/PUT/DELETE as well.

GiteaMirror commented

2025-11-02 05:41:56 -06:00

@guillep2k commented on GitHub (Oct 27, 2019):

Mmm... Now I think DELETE should have no body, so it should better be:

GET /repos/{owner}/{repo}/issues/{index}/subscriptions
PUT /repos/{owner}/{repo}/issues/{index}/subscriptions/{user}
DELETE /repos/{owner}/{repo}/issues/{index}/subscriptions/{user}

@guillep2k commented on GitHub (Oct 27, 2019): Mmm... Now I think DELETE should have no body, so it should better be: ``` GET /repos/{owner}/{repo}/issues/{index}/subscriptions PUT /repos/{owner}/{repo}/issues/{index}/subscriptions/{user} DELETE /repos/{owner}/{repo}/issues/{index}/subscriptions/{user} ```

GiteaMirror commented

2025-11-02 05:41:57 -06:00

@6543 commented on GitHub (Oct 27, 2019):

and a sidenote: #7657 will add a new categorie of subscription 👍

@6543 commented on GitHub (Oct 27, 2019): and a sidenote: #7657 will add a new categorie of subscription :+1:

GiteaMirror referenced this issue

2025-11-02 12:31:29 -06:00

[PR #4193] [CLOSED] add .gpg url (match github behaviour) #17277

Sign in to join this conversation.