[Rt-commit] rt branch, 4.4/reduce-cached-ticket-role-group-members, updated. rt-4.4.4-377-g9d8ce46fb0

Jim Brandt jbrandt at bestpractical.com
Fri Apr 23 16:54:16 EDT 2021


The branch, 4.4/reduce-cached-ticket-role-group-members has been updated
       via  9d8ce46fb06607dd4c20e500a90743e47fd3209e (commit)
       via  8a291a52d822687f5a196a9169514816fd81ce60 (commit)
       via  2d292484f9825fe9dd05765350442e956bf2fb2e (commit)
      from  e926e786c5f97e2df5802a782cbce4a9a77f459a (commit)

Summary of changes:
 docs/UPGRADING-4.4     | 18 +++++++++++
 docs/query_builder.pod | 87 +++++++++++++++++++++++++++++++++++++++++++++-----
 2 files changed, 97 insertions(+), 8 deletions(-)

- Log -----------------------------------------------------------------
commit 2d292484f9825fe9dd05765350442e956bf2fb2e
Author: Jim Brandt <jbrandt at bestpractical.com>
Date:   Fri Apr 23 15:25:31 2021 -0400

    Document shrink-cgm-table upgrade step

diff --git a/docs/UPGRADING-4.4 b/docs/UPGRADING-4.4
index 870e682c99..9c712c57d6 100644
--- a/docs/UPGRADING-4.4
+++ b/docs/UPGRADING-4.4
@@ -649,6 +649,24 @@ This has been fixed to correctly use the user's timezone.
 Note that this change may modify results for some saved searches for users
 with a different timezone than RT's global setting.
 
+=item * Script to reduce records in CachedGroupMembers
+
+When adding groups to roles on tickets, we have found that caching the
+members of these added groups in the CachedGroupMembers table makes
+performance worse rather than improving it. This release includes updates
+to no longer add these members recursively.
+
+If you use groups in ticket roles, it's likely your CachedGroupMembers table
+has a large number of now unnecessary records and these can hurt performance.
+To delete these extra records run the following script:
+
+    /opt/rt4/etc/upgrade/shrink-cgm-table
+
+Depending on how many records your system has, this may take a while to run.
+After you run this, you may have significantly reduced the number of records
+in your CachedGroupMembers table, and may need to tell your database to
+refresh indexes/statistics.
+
 =back
 
 =cut

commit 8a291a52d822687f5a196a9169514816fd81ce60
Author: Jim Brandt <jbrandt at bestpractical.com>
Date:   Fri Apr 23 16:00:17 2021 -0400

    Add context to the CF searching documentation

diff --git a/docs/query_builder.pod b/docs/query_builder.pod
index 6c6d1e27bb..e53b5e83d3 100644
--- a/docs/query_builder.pod
+++ b/docs/query_builder.pod
@@ -139,16 +139,7 @@ The same pieces of information are now spread across the display next to one
 another, which can be harder to read. So when you tell RT to display a lot of
 columns, it's usually worth adding a well-placed NEWLINE.
 
-Let's say, for example, you have a custom field named 'TransportType' that takes
-the values, 'Car', 'Bus' or 'Train'. If you were to search for all tickets that
-do not have 'TransportType' set to 'Car', this would result in a list of tickets
-with 'TransportType' values of 'Bus', 'Train', and '(no value)'. In order to ensure
-that custom fields with no set value are not included in the your search results,
-add the following to your query:
-
-AND CF.{TransportType} IS NOT NULL
-
-=head1 Searching Custom Fields
+=head1 Searching Custom Fields on Tickets
 
 If you use custom fields on your tickets, you might initially load the Query
 Builder and not see them listed. If your custom fields are applied to
@@ -166,6 +157,50 @@ Using the Advanced tab, you can also type one other criteria to search for queue
 by their lifecycle. TicketSQL supports "Lifecycle = 'support'" if you type it
 directly into the Advanced search box.
 
+=head2 Basic Custom Field Searches
+
+Once you add a queue to your search using one of the options above, you'll see
+any custom fields applied to those queues at the bottom of the list of values in
+the Add Criteria section. To search for all tickets with a custom field that
+has some value, pick the comparision ("matches", "is", etc.), add a value,
+and click "Add these terms" to build the search.
+
+If you have a custom field named "Transport Type", for example, that has
+the values, "Car", "Bus" or "Train", you can search for all tickets that
+reference cars by picking "is" next to "Transport Type", typing "Car"
+and clicking Add these terms. You should then see a search term like:
+
+    'CF.{Transport Type}' = 'Car'
+
+For custom fields that have a dropdown with values to pick from a list,
+the Query Builder will show the available values as a dropdown and
+you can pick from the options without typing a value.
+
+When searching for custom fields, you can also add them as a column in
+your search results as described above.
+
+=head2 Searching for Empty Custom Fields
+
+Sometimes you want to search for all tickets where a given custom
+field doesn't have a particular value. For example, you might search
+for all tickets where "Transport Type" is not set to "Car" using the
+"isn't" option, and that would create:
+
+    'CF.{Transport Type}' != 'Car'
+
+The search would contain all tickets in that queue with "Transport Type"
+values of "Bus", "Train", and no value.
+
+To remove tickets where Transport Type has no set value, add the
+following to your query:
+
+    AND 'CF.{Transport Type}' IS NOT NULL
+
+Similarly, to see all tickets where "Transport Type" hasn't be set,
+you can search for :
+
+    'CF.{Transport Type}' IS NULL
+
 =cut
 
 =head1 Learn More

commit 9d8ce46fb06607dd4c20e500a90743e47fd3209e
Author: Jim Brandt <jbrandt at bestpractical.com>
Date:   Fri Apr 23 16:53:52 2021 -0400

    Add docs for new shallow search option

diff --git a/docs/query_builder.pod b/docs/query_builder.pod
index e53b5e83d3..eb13e8c915 100644
--- a/docs/query_builder.pod
+++ b/docs/query_builder.pod
@@ -139,6 +139,42 @@ The same pieces of information are now spread across the display next to one
 another, which can be harder to read. So when you tell RT to display a lot of
 columns, it's usually worth adding a well-placed NEWLINE.
 
+=head1 Searching for Users on Tickets
+
+The Query Builder provides ways to search for tickets based on how a
+given user is related to the ticket. This works for all ticket roles,
+so you can find all active tickets where a given user is the Requestor,
+meaning they opened the ticket. You can also search for all tickets
+with a given user as the owner, meaning that's what they are working on.
+
+=head2 Groups on Roles
+
+Ticket roles, except for Owner, can also accept a group as a value.
+When you search for a user, by default the Query Builder does a
+recursive or "deep" search, meaning it searches the role and it checks
+the membership of any groups it finds in the role as well.
+
+For example, assume you have a group "Helpdesk", the staff1 user is a
+member, and Helpdesk is set as an AdminCc on a ticket. If you perform
+this search:
+
+    AdminCc.Name = 'staff1'
+
+the results will contain that ticket.
+
+=head2 Shallow Searches
+
+In some cases you may want to see tickets only when the user you are
+searching for is a direct member of a role and not if they are in
+any groups. For that case, use the "shallow" options, like "shallow is"
+to generate a search like this:
+
+    AdminCc.Name SHALLOW = 'staff1'
+
+That will show tickets where 'staff1' is directly in the AdminCc role,
+but not the ticket from the previous example where staff1 is in the
+Helpdesk group on the AdminCc role.
+
 =head1 Searching Custom Fields on Tickets
 
 If you use custom fields on your tickets, you might initially load the Query

-----------------------------------------------------------------------


More information about the rt-commit mailing list