Implemented filtering by repository on my tickets page #259
Conversation
jeyoung
changed the title
| // by repository | ||
| List<RepositoryModel> repositoryChoices = getRepositoryModels(); | ||
| RepositoryModel noneChoice = new RepositoryModel(); | ||
| noneChoice.name = Translation.get("gb.all"); |
There was a problem hiding this comment.
We can't use Transation. Instead do this:
getString("gb.all");
|
Aside from the little comments I made we have two larger problems. One is easily fixable. The other.... not sure.
|
… owned by the user. Also, minor refactoring to avoid code duplication.
|
@gitblit, re-submitted with changes based on your code review. Also changed the repository options to constrain to those relevant to the user's watched tickets. (Sorry about the changes of tabs to spaces, please ignore white-space differences when you compare.) |
| @Override | ||
| public void populateItem(final Item<RepositoryModel> item) { | ||
| final RepositoryModel r = item.getModelObject(); | ||
| PageParameters params = queryParameters(queryParam, milestoneParam, statiiParam, assignedToParam, sortBy, desc, r.getRID(), 1); |
There was a problem hiding this comment.
String rid = r == noneChoice ? null : r.getRID();Then use rid in the queryParameters call.
|
Good work. We are very close now and this will be a nice usability improvement. |
Removed default "watchedby" filter so that the default now includes "createdby", "responsible", watchedby" and "mention"
|
@gitblit These changes should be it. If no more review comments, I'll proceed with fixing the mentions bug, err, mentioned above. |
|
Thanks Eddy! Merged. |
|
A pleasure. I'd really like to look into implementing tickets across groups. Is that on the roadmap for 1.7.0? Otherwise, I can pick another 1.7.0 item. |
|
Tickets are intricately tied to repositories. It would take some heroic changes (i.e. likely not mergeable) to accommodate that. If you really wanted to explore that I would suggest implementing some sort of ticket-container object with it's own persistence mechanism and UI. Maybe this could be a plugin but I haven't spent more than 30 seconds thinking about this so maybe that is a dumb idea. ;) |
|
Hmm. I forgot about the integration of tickets within repositories, but your idea of a “repository group ticket service” is worth pursuing. I’ll think about that a bit more this week-end. From: James Moger [mailto:notifications@github.com] Tickets are intricately tied to repositories. It would take some heroic changes (i.e. likely not mergeable) to accommodate that. If you really wanted to explore that I would suggest implementing some sort of ticket-container object with it's own persistence mechanism and UI. Maybe this could be a plugin but I haven't spent more than 30 seconds thinking about this so maybe that is a dumb idea. ;) — |
OK, I think I got it right now. Pulled develop, then merged my ticket-57 changes on top of it.