1234- / gitblit

Automatically exported from code.google.com/p/gitblit
Apache License 2.0
1 stars 0 forks source link

Option to "subscribe" to new tickets #425

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
This is my last issue for a while, I promise :)

So it's pretty important for reviewees to get notified of new tickets. ATM the 
only automated way to notify one particular reviewee is to set her as 
responsible, but that's not possible if:

- the ticket creator doesn't have RW access to the repo
- the repo has anonymous push enabled

In those cases the "responsible" dropdown is missing. Additionally, there might 
be several people interested in new tickets while the responsible dropdown 
allows for just one user.

Starring the repo or being the owner of it doesn't trigger notification emails 
for new tickets either.

Would you please consider adding a way to "subscribe" to new tickets per repo, 
something like this:

- Any number of reviewees subscribe to Repo X. A trivial means to do so is to 
extend the starring feature to do this as well. (If I understand it correctly, 
all starring currently does is that it makes those repos linked on "my 
dashboard".) Although this wouldn't be as intuitive as having a separate button 
just for this - there can be several ways of doing this, not sure which is the 
best.

- When a dev opens a new ticket in Repo X, all the subscribers get a 
notification of the fact that a new issue has been created. They aren't 
automatically added to the watchers of the ticket coz they'll want to 
individually decide if that particular ticket's relevant to them or not. If 
it's not relevant they don't want to get all the additional noise of 
comment/commit notifications.

- Those who are interested either add themselves to the watchers list or get 
responsible and from then they get all the other notifications, too (commits, 
comments).

What do you think?

Original issue reported on code.google.com by sundayfu...@outlook.com on 9 May 2014 at 6:48

GoogleCodeExporter commented 9 years ago
Agreed.  Gitblit needs repository watchers.

https://github.com/gitblit/gitblit/blob/master/src/main/java/com/gitblit/tickets
/TicketNotifier.java#L574

As for anonymous pushes... you shouldn't be able to push anonymously to 
tickets.  That is specifically prohibited.  I'll look into the responsible 
part.  I don't remember it working that way - but I write alot of code so 
maybe.  :)

Original comment by James.Mo...@gmail.com on 9 May 2014 at 6:57

GoogleCodeExporter commented 9 years ago
Nah, I didn't mean that users can push to tickets anonymously. I meant that the 
"responsible" dropdown is missing on the "new ticket" page when anonymous 
pushes (in general) are enabled for the repo under access permissions. I don't 
see the exact reasoning behind this, but that's the way it is currently.

Original comment by sundayfu...@outlook.com on 9 May 2014 at 8:46

GoogleCodeExporter commented 9 years ago
The responsible selection when anonymous push is enabled is a corner-case I 
didn't see.  A hotfix has been pushed to master and develop.

Original comment by James.Mo...@gmail.com on 12 May 2014 at 12:52

GoogleCodeExporter commented 9 years ago
Thanks! Could you please explain the reason for the other case? I.e. when the 
ticket creator has no RW access?

Original comment by sundayfu...@outlook.com on 12 May 2014 at 12:58

GoogleCodeExporter commented 9 years ago
Sure:  Go to any github repo that you don't own & create an issue.  Same thing.

Original comment by James.Mo...@gmail.com on 12 May 2014 at 1:00

GoogleCodeExporter commented 9 years ago
Well, yeah, come to think of it, it makes sense. Those who are not allowed to 
push are prolly not the ones to decide who's gonna merge it either. I was 
thinking a bit differently, e.g. when code review is required (enforced) for a 
dev to get a commit into the repo, but devs tend to have RW access when they 
are active contributors of a repo anyway. Thanks!

Original comment by sundayfu...@outlook.com on 12 May 2014 at 1:05

GoogleCodeExporter commented 9 years ago
The code review "requirement" is loose.  You can still merge client-side and 
push that.  The current purpose of tickets is not strict code review 
enforcement, it's light-weight collaboration and communication.  I am sure it 
will evolve to be more sophisticated in future releases.

Original comment by James.Mo...@gmail.com on 12 May 2014 at 1:10

GoogleCodeExporter commented 9 years ago
Now with 1.6.1-SNAPSHOT (8c0c9ae48f) it seems that repo owners do get a 
notification for new tickets which I didn't see mentioned in the changelog but 
is a welcome addition. It kinda solves this issue. It's not really intuitive 
but I can settle with it :)

Original comment by sundayfu...@outlook.com on 2 Jul 2014 at 11:38

GoogleCodeExporter commented 9 years ago
They always did - at least that is the way it was written.  I always got 
emails. :)  This matches the behavior of GitHub et al.  If it is your repo you 
should be notified of what is going on - that is part of ownership.

Eventually I'll code-up the personal watch/subscribe functions.  It's not hard, 
but there is a precursor change that must happen first which I am less than 
thrilled to do - but needs to be done.

Original comment by James.Mo...@gmail.com on 2 Jul 2014 at 1:54

GoogleCodeExporter commented 9 years ago
Strange, coz earlier I stated that "Starring the repo or being the owner of it 
doesn't trigger notification emails for new tickets either." Hm, maybe it 
coincided with #423, dunno.

Original comment by sundayfu...@outlook.com on 2 Jul 2014 at 2:00

GoogleCodeExporter commented 9 years ago
Which precursor change would that be?
Because repository watches for new tickets is a feature I'd be interested in, 
too. It has been requested here and the current solution is that everyone 
interested is set as repo owner. Which is not the way I would want to keep it.

Original comment by f.zscho...@gmail.com on 18 Nov 2014 at 10:36

GoogleCodeExporter commented 9 years ago
Florian, I think I was referring to Bootstrap.  The Bootstrap button bar as 
used by Gitblit has bugs which prevent use of a dropdown within the bar.  A 
dropdown would be quite useful here and would be familiar for Github/Bitbucket 
users.  I think Gitblit uses 2.1.x which is pretty old considering the pace of 
trendy web development.  So I think I meant the precursor would be to update to 
the final 2.x version or update to 3.x version.  Either one would require some 
effort - hence I'm less than thrilled.  :)

Original comment by James.Mo...@gmail.com on 19 Nov 2014 at 2:56

GoogleCodeExporter commented 9 years ago
All I can say is that this is definitely the most requested feature at my 
workplace ATM.

Original comment by sundayfu...@outlook.com on 19 Nov 2014 at 10:44