Re: RT 4.4.1 - Change owner on corrospond Scrip - Strange issue
Shawn M Moore <[email protected]> Thu, 23 Feb 2017 12:06:48 -0500
| Newsgroups | gmane.comp.bug-tracking.request-tracker.user |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_005A8D1D-EDA4-48CB-98E7-6F77AFBB59E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Robert, Alex, > Is this just a display bug or are we not using the proper method to = change the owner of the Ticket? You're not using the proper method. > # do the actual 'status update' > my ($status, $msg) =3D $self->TicketObj->_Set(Field =3D> 'Owner', = Value =3D> $Actor, RecordTransaction =3D> 0); Should instead be: my ($status, $msg) =3D $self->TicketObj->SetOwner($Actor); > What works: When user is first to correspond, Scrip executes and in = Ticket view the Owner is set as expected. >=20 >=20 > What doesn=E2=80=99t work: If we go into the queue and list all the = open tickets, the owner will be listed as =E2=80=9Cnobody=E2=80=9D in = this view, but if you open the ticket, there is an owner. If you change = the owner to someone else and change it back, then it seems to fix this = issue. The reason you need to use SetOwner is that the owner of a ticket is = represented in two different database tables. The first is in the = GroupMembers table, alongside Requestors, Ccs, and AdminCcs, and custom = roles. This is what provides features like permissions. It's also what's = used when you display the "Owner" column in search results. Tickets = _also_ store their owner denormalized in the tickets table. This is used = in, among other places, displaying the owner on ticket display, and in = email notifications. ->Set(Field =3D> 'Owner') only updates the latter. ->SetOwner updates = both. This explains the inconsistencies you're seeing. Please try switching = your scrip to ->SetOwner and seeing if it helps for tickets going = forward. For existing tickets with this problem, you'll need to address = the consistency issue. It turns out that, for different reasons entirely ( = https://issues.bestpractical.com/Ticket/Display.html?id=3D32381 = <https://issues.bestpractical.com/Ticket/Display.html?id=3D32381> ), RT = 4.4.2 adds an upgrade step and an rt-validator rule that detects and = fixes such inconsistencies. You can find them here: = https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f56fd91f20c5= 73108c1ab = <https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f56fd91f20c= 573108c1ab> = https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a79d68271941= d4cdca159 = <https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a79d6827194= 1d4cdca159> Best, Shawn= --Apple-Mail=_005A8D1D-EDA4-48CB-98E7-6F77AFBB59E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">Hey Robert, Alex,<div class=3D""><div><div><br = class=3D""></div><div class=3D""><div><blockquote type=3D"cite" = class=3D"">Is this just a display bug or are we not using the proper = method to change the owner of the Ticket?<br = class=3D""></blockquote><div><br class=3D""></div>You're not using the = proper method.</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""># do the actual 'status update'<br class=3D"">my ($status, = $msg) =3D $self->TicketObj->_Set(Field =3D> 'Owner', Value = =3D> $Actor, RecordTransaction =3D> 0);<br = class=3D""></blockquote><br class=3D""></div></div><div>Should instead = be:</div><div><br class=3D""></div><div>my ($status, $msg) =3D = $self->TicketObj->SetOwner($Actor);</div><div class=3D""><br = class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div= class=3D"">What works: When user is first to correspond, Scrip executes = and in Ticket view the Owner is set as expected.<br class=3D""><br = class=3D""><br class=3D"">What doesn=E2=80=99t work: If we go into the = queue and list all the open tickets, the owner will be listed as = =E2=80=9Cnobody=E2=80=9D in this view, but if you open the ticket, there = is an owner. If you change the owner to someone else and change it back, = then it seems to fix this issue.<br = class=3D""></div></div></blockquote></div></div><div><br = class=3D""></div><div>The reason you need to use SetOwner is that the = owner of a ticket is represented in two different database tables. The = first is in the GroupMembers table, alongside Requestors, Ccs, and = AdminCcs, and custom roles. This is what provides features like = permissions. It's also what's used when you display the "Owner" column = in search results. Tickets _also_ store their owner denormalized in the = tickets table. This is used in, among other places, displaying the owner = on ticket display, and in email notifications.</div><div><br = class=3D""></div><div>->Set(Field =3D> 'Owner') only updates the = latter. ->SetOwner updates both.</div><div><br = class=3D""></div><div>This explains the inconsistencies you're seeing. = Please try switching your scrip to ->SetOwner and seeing if it helps = for tickets going forward. For existing tickets with this problem, = you'll need to address the consistency issue.</div><div><br = class=3D""></div><div>It turns out that, for different reasons entirely = ( <a = href=3D"https://issues.bestpractical.com/Ticket/Display.html?id=3D32381" = class=3D"">https://issues.bestpractical.com/Ticket/Display.html?id=3D32381= </a> ), RT 4.4.2 adds an upgrade step and an rt-validator rule that = detects and fixes such inconsistencies. You can find them = here:</div><div><br class=3D""></div><div><a = href=3D"https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f56f= d91f20c573108c1ab" = class=3D"">https://github.com/bestpractical/rt/commit/58bacce6ada754657c7f= 56fd91f20c573108c1ab</a></div><div><a = href=3D"https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a79d= 68271941d4cdca159" = class=3D"">https://github.com/bestpractical/rt/commit/20d8daf6855e3c53ee8a= 79d68271941d4cdca159</a></div><div><br = class=3D""></div><div>Best,</div><div>Shawn</div></body></html>= --Apple-Mail=_005A8D1D-EDA4-48CB-98E7-6F77AFBB59E1--