Integration with other bug tracking systems.

[Flone-dnb]

Allow reporter to be used to send reports to other bug reporting systems (and similar issue tracking systems) instead of our server/database, such as:

• GitHub issues (supports report attachments?),
• GitLab issues (supports report attachments?),
• Gitea (supports report attachments?),
• YouTrack (supports report attachments?),
• Trello (supports report attachments?).
• Mantis Bug Tracker (supports report attachments?),
• Jira (supports report attachments?),

Leave a comment with your bug tracking (and similar issue tracking) system if it's not listed here. Will see how long it will take for me to implement this. :)

[LoipesMas]

For GitHub you could use REST API from the server: docs. IIUC this would require the server-owner to get and set the personal access token in the server config.
Or you could have your own (centralized) bot that handles that, but I assume that's not what you want.

[Flone-dnb]

@LoipesMas Hey great idea, I'm thinking on what we should do, at first I though when the user wants to use Github Issues (for example) we should only use reporter so that there is no need to host a dedicated server (which is great!). Now I realized in this case we will keep access token somewhere in game code (gdscript for example) which is pretty much public (does encrypting your gdscript make it protected enough?). So, the question: is there a way to create access token that will only be able to create issues and nothing else (I haven't looked into that yet)? Even if yes this sounds a little dangerous (or no?).

On the other hand having an access token on server is fine, but this requires a dedicated server (which is not so great).

So, what do think about this?

[LoipesMas]

That was pretty much my thought process.
Here it is explained more:

keep access token somewhere in game code

Bad idea, because even if it was encrypted, it gets decrypted at some point and code of the reporter is open so it would be easy to reverse engineer the packets and get the token (or maybe even just a http proxy would work, not sure). Or read it from RAM.

create access token that will only be able to create issues and nothing else

It might be possible but...

this sounds a little dangerous

Yep. You don't want your GitHub issues spammed (this is something that I will get back to)

On the other hand having an access token on server is fine, but this requires a dedicated server

If you could forgo database, you could have it "serverless" (I don't like that term...), which should be pretty cheap, but maybe a bit harder to set up (never actually did it myself). This could also do some filtering or something, which brings us to my last point:

You don't want your GitHub issues spammed
Whether you send a GitHub request from reporter or through a server, if every report automatically goes to GitHub issues, that could easily cause a lot of issues. I think you can easily expect a majority of reports to be duplicates.

Solution proposal: move issue creation to the client.
Client-user could have the ability to create an issue from the report with a single click. Maybe even add linking reports to issues in client. Or adding as comments to existing issues for context?
I think this is a pretty safe and solid solution, what do you think?

(Also, I have a few more ideas/questions. Should I create issues, or would you open discussions for this repo, or some other way?)

[garyritchie]

https://gitea.io also has an API: https://docs.gitea.io/en-us/api-usage/

[Flone-dnb]

@garyritchie I've added it to the list. Thanks for the tip.

[Flone-dnb]

@LoipesMas Hey great idea! I think we should totally do this: server receives a report but the clients decide whether to create an issue from this or not. Also, as you've mentioned we should probably have 2 options: create an issue from report or link report to an existing issue (as a comment to an issue).

So, when the client decides what to do with the report (create issue or link existing) we should probably delete the report from the database. What do you think? I'm thinking this way: server_config.ini will have fields for Github Issues, when they are filled Github Issues will be used automatically and all reports in the client application will have a few additional buttons for Github Issues. When decided what to do with the report, it will be deleted from the server database.

About more ideas/questions feel free to create new issues, I'm more used to that rather than opening discussions.

[LoipesMas]

I don't think deleting the reports is a good idea. It would be better to mark them as "linked"/"archived"/"exported" or something else, so they can be filtered out but still can be accessed later if needed.

[Flone-dnb]

@LoipesMas Good. We should display report status ("linked"/"archived"/"exported") when Github Issues are used. We then need to add filtering in client. We should probably implement filtering via keywords like YouTrack or Github has, for example:

status: linked  // shows all reports with linked status
status: linked && archived // linked and archived
game: My Cool Game // games with the specified name
game: My Cool Game && status: linked
game_version: ...
etc.

Wanted to implement this long time ago.

If you're wanting to contribute feel free to work on this issue. Last few weeks I've spend working on the latest update now I want to work on my other project a little so I probably won't work on this project next month. Although maybe I will, but I will probably work on the other issue. You just need to combine all ideas and details about implementing Github Issues support, so it will be approved by all of us, then you can start working on this if you want.

[LoipesMas]

We should probably implement filtering via keywords

Something like this should work.

I can give it a shot if I find time.

[Flone-dnb]

@LoipesMas We should look at this crate.

P.S. Found a better crate.