Modify

Opened 9 months ago

Last modified 9 months ago

#16373 new enhancement

When opening new ticket from JOSM, pre-fill component field (if known)

Reported by: floscher Owned by: team
Priority: normal Milestone:
Component: Core bugreport Version:
Keywords: Cc: michael2402, floscher

Description

When a plugin throws an exception and JOSM asks you to report the issue as new ticket, at least the component field should be pre-filled with the right plugin.

This can be achieved by using the query string parameter component, additionally to pdata_stored. Then not so many issues have to be re-categorized, because not all JOSM users who create tickets are able to find out from the status report from which component the issue originated.

Maybe it would even be helpful to pre-fill other fields, like populating the summary field with the thrown exception and the class and line where it occured. E.g. UnknownHostException: wwww.example.org (thrown in SomeClass).

The URL that JOSM should open could then look something like this:
https://josm.openstreetmap.de/josmticket?component=Plugin%20wikipedia&summary=UnknownHostException%3A%20wwww.example.org%20%28thrown%20in%20SomeClass%29&pdata_stored=01234567890123456789abcd

Attachments (0)

Change History (5)

comment:1 Changed 9 months ago by floscher

Component: CoreCore bugreport

comment:2 Changed 9 months ago by Klumbumbus

While we are on bugreports, I suggest to change

==== What steps will reproduce the problem?
1. 
2. 
3. 

==== What is the expected result?

==== What happens instead?

==== Please provide any additional information below. Attach a screenshot if possible.

to

==== What steps will reproduce the problem? ====
1. 
2. 
3. 

==== What is the expected result? ====


==== What happens instead? ====


==== Please provide any additional information below. Attach a screenshot if possible. ====


About once every month we get a bug report where the users doesn't understand the meaning of ==== and writes his text directly behind the question "destroying" the layout. With this change this will be muss less likely happen.

comment:3 Changed 9 months ago by stoecker

Hmm. It's not so easy to get the right component. There are many cases where the JOSM detector detects the wrong plugin or plugins are blamed whereas this is a core issue and so on. I don't find that manual re-categorization a big issue for these reports where stack traces and information are complete.

comment:4 Changed 9 months ago by floscher

At least for plugins it should be relatively straightforward to determine the component. The dialog that asks the user to decide if a pugin should be disabled or kept seems to already know the source of the exception.

For other components this might be not as clear, then the component could still be Core.

comment:5 in reply to:  4 Changed 9 months ago by anonymous

Replying to floscher:

At least for plugins it should be relatively straightforward to determine the component. The dialog that asks the user to decide if a pugin should be disabled or kept seems to already know the source of the exception.

That's a guess based on the stack trace. It takes the first stack line asignable to a plugin and assumes this was the faulty code. That's fine for an update request (from developers point updates are never wrong), but I'm not sure it is enough for ticket assignment.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to floscher
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.