improve error message about missing priority field
One of my users has reported that could not create issues using Redmine Java API:
org.redmine.ta.RedmineException: Priority can't be blank
I was trying to reproduce the problem on several different Redmine installs with Postgresql, MySQL, different Redmine versions, ...
It turned out the user didn't have a "default Issue priority" set in his Redmine administration panel.
A good solution here is for REST API to provide a list of existing priorities with IDs so that remote clients can use them. This is requested in #8596.
A minor easy fix would be to improve the error message: change it from
Priority can't be blank
Priority can't be blank. No default priority is set in the Redmine server settings. please use menu "Administration -> Enumerations -> Issue Priorities" to set the default priority.
Users will really appreciate nice error messages!
Etienne, I hope you don't mind if I assign this to you?
#1 Updated by Etienne Massip almost 10 years ago
- Assignee deleted (
I would prefer you don't, as a general rule you should not assign issues.
Since there is a default priority set in default configuration, it seems that removing this default setting is a deliberate move from your user's administrator to force users to select a priority.
If the user then don't set a priority when creating an issue, either via web GUI or API, he'll get this validation error message as expected, so I don't think you should consider this as an issue, user should have select a priority.
Also, the message you suggested is intended for an admin user, which is not the role of a validation message.
#3 Updated by Etienne Massip almost 10 years ago
Alexey Skor wrote:
the problem is that the external clients do not know the available priority IDs, which means you can't create tasks via REST API if the default priority is not set.
Agreed, this is blocking for these instances.
#5 Updated by Etienne Massip almost 10 years ago
Alexey Skor wrote:
Priority can't be blank when no default Issue Priority is defined on the server
is a good idea anyway. - and it's very easy to implement :)
Not difficult at all, but I still don't think it's the right place as this validation message will also be displayed in web GUI form and because if there is a default priority set or not is still not of the user's concern.
Wouldn't documenting this behavior for API be sufficient?
#6 Updated by Alex Last almost 10 years ago
I don't really care that much as long as I can retrieve the list of available statuses and priorities for the project. it's up to you :)
several people are waiting for this REST API improvement, they can't use remote clients (based on my Java API) without that...