Inconvenience with AutoSetOwner: Owner field defaults to Nobody on unowned tickets

Hi. By way of background, we recently migrated from RT 3.8 to RT 4.4 (via a hideous, slow, kludgy, incomplete script based on the rt command-line tool, since we had problems migrating the database directly). We implemented the AutoSetOwner scrip at https://rt-wiki.bestpractical.com/wiki/AutoSetOwner, to take effect “On Correspond”, so that a sysadmin automatically gets a ticket assigned to them when replying to the ticket.

That works fine when we reply via email. But when we reply to an unowned ticket via the “Reply” web interface, the “Owner:” field in “Ticket and Transaction” at the top gets pre-populated with “Nobody”, and that takes effect after the scrip runs. So I reply to a new ticket, the reply goes out and triggers auto-assignment of the ticket to me, and then the ticket immediately gets reassigned to “Nobody” because that was in the “Owner:” field.

Obviously taking the ticket first, or manually setting the owner under “Ticket and Transaction”, or just deleting the “Nobody” value there, is a workaround, but I’m trying to minimize my colleague’s need to use the mouse and their likelihood of forgetting to do that and leaving tickets unowned (and perhaps resolved).

In 3.8, the corresponding ownership field was a drop-down, and appended " (unchanged)" to the username for the current owner of a ticket, in which case no change was applied. So it was possible to leave the “Nobody (unchanged)” (or “Ann Q. Sysadmin (unchanged)”) default value and not have it override a scrip that set the owner, but it was also possible to manually choose “Nobody” from the drop-down and make a ticket unowned if you wanted to.

Is there an elegant way to accomplish something similar in RT 4? It seems like it would be most useful for that field to default to blank if the current owner is Nobody. (Or maybe always, and the user can set it if they want to make a change.)

This old forum post had the same issue but doesn’t seem to have any replies, and this thread from 2018 has code changes to just take out the “Owner:” field, but that’s not The Right Way™.

Possibly related: The “Owner:” field seems to autocomplete regardless of the value of the “Use autocomplete to find owners?” preference. (Maybe the 4.4 drop-down interface still supports " (unchanged)" as the old one did.)

Jay

I just tested on 4.4.4 and I see the owner set correctly, is it possible another scrip is running?

I don’t think so. If I manually clear the Owner: field before submitting the page, nothing changes the owner after the AutoSetOwner scrip runs. I think the issue is just that the “Ticket and Transaction” updates get applied after the scrips run.

I did figure out why I was getting autocompleting text forms to select the owner rather than a dropdown – if you have more than 25 privileged users you automatically get autocompleting forms regardless of your preference and site default.

We were over that. I was able to prune some old privileged users and get us back under and get the dropdowns, which still have the old “Nobody (unchanged)” or “Pat M. Sysadmin (unchanged)” behavior, so for anybody who hasn’t chosen autocompletion in their preferences, things work as expected. But we may not be able to stay under 25 privileged users long-term.

I guess I’d like for autocompleted Owner: fields to default to blank (meaning no change), which would make the workflow identical whether you use autocompletion or drop-downs – the owner doesn’t change unless you explicitly choose to change it. (Alternatively, it could default to the current owner with “(unchanged)” appended, and that could be interpreted to mean don’t make any changes even if something else changes the owner in the interim, as happens with dropdowns.)

Anyway, the mystery is solved, but it’s a slightly clumsy quirk. I may look into a workaround somebody else found of just removing the owner field/dropdown from that page.

Jay

Good call, I didn’t realize the autocomplete input was different than the drop down maybe the fix is as simple as setting the $value from the SelectOwnerAutocomplete component to a placeholder instead?

--- a/share/html/Elements/SelectOwnerAutocomplete
+++ b/share/html/Elements/SelectOwnerAutocomplete
@@ -55,14 +55,14 @@ $TicketObj      => undef
 <%INIT>
 $ValueAttribute = 'Name' unless $ValueAttribute =~ /^(?:id|Name)$/;

-my $value = '';
+my $placeholder = '';

 if ( $Default and not $Default =~ /\D/ ) {
     my $user = RT::User->new( $session{'CurrentUser'} );
     $user->Load($Default);
-    $value = $user->$ValueAttribute;
+    $placeholder = $user->$ValueAttribute;
 } elsif (defined $TicketObj) {
-    $value = $TicketObj->OwnerObj->$ValueAttribute;
+    $placeholder = $TicketObj->OwnerObj->$ValueAttribute;
 }

 # Map to a string of RT::Ticket-1|RT::Queue-5|...
@@ -74,7 +74,7 @@ my $query = $m->comp('/Elements/QueryString',
 );
 </%INIT>

-<input type="text" name="<%$Name%>" id="<%$Name%>" value="<% $value %>" />
+<input type="text" name="<%$Name%>" id="<%$Name%>" placeholder="<% $placeholder %>" value="" />
 <script type="text/javascript">
     jQuery(function() {
         var cache = {};

What happens if you make the scrip a batch scrip?

1 Like

Thanks, that works! I think running the scrip (which sets the owner iff the ticket is currently unowned) in batch stage would prevent people replying to a ticket and simultaneously manually setting it to be unowned, but that’s a pretty unusual situation!