Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I think it makes more sense if new tickets does not offer to select different states - it should always be "new". I am using the JobTrack module now successfully for quiet a while and it turned out that people forget to change the status from "new" to "active" when they update a ticket. Thus, I would suggest not to offer the "new" status anymore once a ticket has been created. Instead, the status should default to "active" and only offer "pending" and "closed" as alternatives.
Comments
Comment #1
jeremy commentedAgreed, will implement before the next release.
Comment #2
jeremy commentedBy default, users are already only shown the "new" state when creating tickets. Only jobtrack administrators get access to all the other states. Thus, this portion of your recommendation is already the way things are -- and I will not remove states from admins.
Your second suggestion, that upon updating a ticket it should switch to the "active" state, I have implemented this in a way that makes sense to me. If the person that creates a ticket goes back and later updates it, I do not think it makes sense to automatically switch it to an "active" state. However, if another person comes along and edits the ticket, the module does now suggest moving the ticket state to "active". Hopefully this proves helpful, and doesn't result in confusion.
Comment #3
roball commentedI wasn't aware that users without the administer jobtrack permission are already only offered the new state at creating new tickets. This is 100% fine for me - there is currently only a bug with it: when you preview the new ticket before submitting it, then you no more have the new state, but have to select either active, pending or closed instead.
Comment #4
jeremy commentedI am unable to duplicate this. If who previews the new ticket? The only way "new" disappears for me is if I do _not_ have administer jobtrack permission, and I submit the updated ticket, moving it into an active state. Then I can not get back to new, which is the intended design. I do not see new disappearing when I press preview.
Comment #5
jeremy commentedNo further feedback, I believe this is working as designed. Closing.
Comment #6
roball commentedJeremy, the bug is still there. Login as a user that does not have the administer jobtrack permission. Create a new ticket. The "state" drop-down menu originally only offers "new". Fine. However, after clicking the [ Preview ] button, the unprivileged user can then select all the other 3 states, too. If he does so (eg. selects the "closed" state) and then once again clicks the [ Preview ] button, then the "new" state is no longer available before actually submitting the new ticket!
Comment #7
roball commentedJust found another problem: When an unprivileged user makes the first comment to a new ticket, the default state has changed to "active". Fine. However, "new" can still be chosen from the menu. I think the logical way should be not to offer "new" at all when non-admins comment an existing ticket.
Comment #8
jeremy commentedThanks, now I've duplicated it and committed a fix (for what you're reporting in #6).
As for what you report in #7, this is by design -- regardless of your permissions, you always have the ability to keep a ticket in whatever state it currently is in. The workflow I have in mind is Client A has User Foo and User Bar. User Foo creates the ticket, and user Bar updates the ticket with additional information before that ticket has been reviewed by an admin, thus the ticket should still be in a new state. This can be important if you're using the jobtrack_sms plugin.
Comment #9
roball commentedExcellent! Works great now in 1.6-rc1.