Labels: area/ui/web
git-bug webui unconditionally opens the status:open page on startup. It would be nice to allow a custom query, so e.g. git-bug webui status:closed would open status:closed by default.
If the idea makes sense, I don't mind taking a look at this myself, probably reasonably straightforward.
Hmmm, at least what would make sense is to have the query as part of the URL (if that doesn't work already like that, can't check now). That way you would bookmark that, or send it to someone.
I guess you idea also make sense, but maybe just as a flag instead of an argument?
Actually, if you can pass the query in the URL, it's going to be much easier to implement this jump from the CLI.
Hi @vmiklos ! It´s already possible to change status with one click as shown in the figure below. Isn´t it better than type the status filter at command line? Could You please tell a little bit more about the use case You have?
@MichaelMure in the image mentioned before You can see that We already have the filter in the url. 😉
Actually, if you can pass the query in the URL, it's going to be much easier to implement this jump from the CLI.
Yes, that would be the idea. So something like git-bug webui -q status:closed could influence what URL is opened once the webserver is up & running.
Could You please tell a little bit more about the use case You have?
My use-case is when I have a git checkout for a project cloned from github, then I use the git-bug bridge to also download the issues. Now when a commit message or comment refers to an issue with its full URL, then I can look up the details of that issue nicely, offline. But getting there is a bit annoying, I have to manually search for metadata:github-url:"https://github.com/author/project/issues/42". It is much more handy if I can fire up the webui in a way that it opens the relevant issue out of the box. More or less a follow-up to https://github.com/MichaelMure/git-bug/issues/567.
That make complete sense to me. The goal of having CLI tools is to allow this kind of programmability: users can have their scripts/macros and build their own weird workflow out of the common building blocks.
Another goal is to allow integrating git-bug within whatever editor people are using.