The behavior you face is default behavior for project, that is difficult to avoid (and we won't change this behavior).
Solution proposed by alainforma is a ggod one.
You can extend it with some DB update : after you have created the new list value, go to the corresponding table (for instance, table priority for list of priorities) and manually change the id of the value to zero (0). This way, selected value will be understood as "no value".
This solution has its drwbacks :
- you won't be able to see (and change) the corresponding item in its dedicated screen.
- for some fileds that share same table (for instance Ticket Type is stored on table type, like all other types : Activity type, Ticket Type,....) you'll be able to have only 1 item with value 0, (so in the exemple with ticket type, this may work for tickets, but then won't be possible with Activities)
Saving the ticket works even if I save with "Select Priority" which I changed in DB as id=0.
The whole workaround, therefore, I don't see the point of it really.
We have customer creating tickets to report bugs in our solution. Lack of qualification from those customers has led us to purchase the "customization screen" plug in which seemed to be the solution for changing attributes on fiels and force customers to qualify their tickets better.
When you select "Responsible" as mandatory, the default value is the first active user in alphabetical order. This is not correct to me. Especially as that field is empty when not mandatory. That doesn't make much sense to me honestly...
I tested it on type and it worked fine.
I did it on Urgency on demo instance : yoju can test it works fine.
Possibly you just forgot to define sortOrder so that this item comes first in the list.
For responsible, yes oprder is alphabetical (as it is the best way to find a resource in the list). You just have to set name of resource as "_select nresposible" or starting with any character that comes before A.
Yes, behavior is different for mandatory and not mandatory fields.
Selecting a default value is the behavior requested by most users : don't have to select a value when default is the best in 90% of the times.
My opinion is that default value is the best, and the best is to set as default the value that will set the less constraints.
For instance, default urgency is "not urgent", so that users have to change value if they consider is is urgent.
Okay, I'll check but I understand what you say and I agree for such fields as urgency, priority, criticity. Lowest value is best and will be in our advantage.
For the responsible, I'm not quite confident setting up something like this as most users may not even pay attention to it (dummies....) and saved the ticket with that default responsible and we'll loose chain of communication (email notification and so on).
So my point is, and I need your help for this:
Can I have "assigned" status as default upon ticket creation ? If yes, that solve my problem, as "assigned" status will pop up an error if responsible not selected
In my opinion, it is not up to the requestor to define the responsible.
In the simple ticket form (that is dedicated to requestor-only profiles), responsible is readonly.
What is the best, is to request for product impacted. Then use ProjeQtOr feature (see configuration screen) to automatically set ticket responsible from product responsible.
En poursuivant votre navigation, vous acceptez le dépôt de cookies tiers destinés au bon fonctionnement et à la sécurisation du site (gestion de session, reCaptcha) et à une analyse statistique anonymisée des accès sur notre site (Google Analytics). Si vous vous inscrivez, les informations que vous fournirez ne seront jamais divulguées à un tiers sous quelque forme que ce soit. En savoir plus
Cookies settings
×
Functional Cookies
Ce site utilise des cookies pour assurer son bon fonctionnement et ne peuvent pas être désactivés de nos systèmes. Nous ne les utilisons pas à des fins publicitaires. Si ces cookies sont bloqués, certaines parties du site ne pourront pas fonctionner.
Session
Please login to see yours activities!
Other cookies
Ce site web utilise un certain nombre de cookies pour gérer, par exemple, les sessions utilisateurs.
Support us on Capterra
