<div dir="ltr">Thanks so much for the response! It is very much appreciated.<br>
<br>
How did it end up there was no record in CachedGroupMembers? To be honest, I don't know. I inherited this RT database from someone else, and I believe they made a number of changes blindly via SQL.<br><br>I sincerely appreciate your help. I apologize for the multiple posts -- my messages weren't appearing in the list archive, so I assumed they weren't going out to the list. If list members received multiples, I apologize profusely!<br>
<br>Hopefully this will help others should they find CachedGroupMembers missing records.<br><br><div class="gmail_quote">On Wed, Sep 10, 2008 at 11:28 AM, Ruslan Zakirov <span dir="ltr"><<a href="mailto:ruz@bestpractical.com">ruz@bestpractical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">And now you should do:<br>
UPDATE CachedGroupMembers SET Via = 81550 WHERE id = 81550;<br>
<br>
But major question is "how did it happen that there is no this record<br>
in CachedGroupMembers table?"<br>
<div><div></div><div class="Wj3C7c"><br>
On Wed, Sep 10, 2008 at 8:00 PM, RT <<a href="mailto:rt@ragweed.net">rt@ragweed.net</a>> wrote:<br>
> All -<br>
><br>
> I would like to get opinions on repairing my database using SQL. If<br>
> there is a more graceful way to accomplish this using the RT perl<br>
> modules (RT::CachedGroupMembers, etc) any help is appreciated.<br>
><br>
> From the "RT Essentials" book (<a href="http://is.gd/2rG6" target="_blank">http://is.gd/2rG6</a>), we find that in<br>
> CachedGroupMembers:<br>
><br>
> id == any incremental value<br>
> GroupId == requestor group id<br>
> MemberId == MemberId in question (requestor)<br>
> Via == usually equal to the CachedGroupMembers id<br>
> ImmediateParentId == requestor group id<br>
> Disabled == 0<br>
><br>
> I'm going to work from the values in Ticket #1 (see previous message).<br>
><br>
> insert into CachedGroupMembers values ('', '52', '34', '', '52', '0');<br>
><br>
> ** And Voila! ** The requestor appears in the regular Search as<br>
> expected, and is searchable by requestor in Query Builder.<br>
><br>
> And here is what it looks like in the end:<br>
><br>
> mysql> select * from CachedGroupMembers where GroupId='52' and<br>
> MemberId='34' and ImmediateParentId='52';<br>
> +-------+---------+----------+------+-------------------+----------+<br>
> | id    | GroupId | MemberId | Via  | ImmediateParentId | Disabled |<br>
> +-------+---------+----------+------+-------------------+----------+<br>
> | 81550 |      52 |       34 |    0 |                52 |        0 |<br>
> +-------+---------+----------+------+-------------------+----------+<br>
><br>
> Should the Disabled status be pulled from Principals? (select Disabled<br>
> from Principals where id = '34')<br>
><br>
> Any opinions on making these modifications is appreciated.<br>
><br>
> On Wed, Sep 10, 2008 at 10:08 AM, RT <<a href="mailto:rt@ragweed.net">rt@ragweed.net</a>> wrote:<br>
>> RT Users -<br>
>><br>
>> After some digging, I believe I've discovered why some tickets do not<br>
>> appear when searched by Requestor. It appears that some records are<br>
>> missing from CachedGroupMembers.<br>
>><br>
>> Can anyone recommend a way of querying for the requestor from<br>
>> GroupMembers and using that to populate CachedGroupMembers?<br>
>> GroupMembers contains the correct requestors -- but that doesn't seem<br>
>> to apply to the standard Search functions.</div></div></blockquote></div><br>
</div>