RT::Cl...Object(3pm)

📦

version 0.73 · 6 versions

0.73 · ubuntu stonking (latest)
0.72 · fedora 43
0.60 · ubuntu jammy
0.72 · fedora 44
0.60 · debian bookworm
0.72 · debian trixie, ubuntu noble, ubuntu resolute

💖 RT::Client::REST::Object — the BASE CLASS of the whole little RT object family 💖

okay so bestie, welcome to RT::Client::REST::Object, straight out of the User Contributed Perl Documentation collection, running on perl v5.40.1 — this is the main character superclass that every RT client object you build is gonna inherit from 🫶

✨ VERSION ✨

version 0.73 💅

🎀 SYNOPSIS 🎀

the vibe is: make a new type, inherit from the base, tell it your attributes, tell it your rt_type, and you're done fr fr

# Create a new type
package RT::Client::REST::MyType;

use parent qw(RT::Client::REST::Object);

sub _attributes {{
  myattribute => {
    validation => {
      type => SCALAR,
    },
  },
}}

sub rt_type { "mytype" }

1;

🌸 DESCRIPTION 🌸

So. RT::Client::REST::Object is a superclass, and like… it does SO much for you? It hands you a whole entire pile of class methods and object methods so that building RT's REST client interface is actually not a nightmare. it's giving "I did the boring parts so you don't have to" energy, periodt ✨

💅 ATTRIBUTES 💅

Your attributes get defined by a method called _attributes — and you gotta define it in your class, okay? That method returns a reference to a hash, and the keys of that hash are the attributes. The values? Those are the attribute settings, and they go like this:

list — if this is set to true, congrats, it's a list attribute 🎉 go see "LIST ATTRIBUTE PROPERTIES" down below for the tea.
validation — a hash reference. This gets passed straight to the validation routines whenever the associated mutator gets called. For reference, look at Params::Validate 👀
rest_name — this sets the attribute's REST name. Like… attribute final_priority corresponds to RT REST's FinalPriority. And lowkey you can just omit this whole option if the only difference between the two is the first letter capitalization ✨
form2value — converts a form value (the one that comes from the server) into something the attribute can actually digest.
value2form — converts the value into REST form format. the reverse baddie 💅

Example time, look at this:

sub _attributes {{
  id  => {
      validation  => {
          type    => SCALAR,
          regex   => qr/^\d+$/,
      },
      form2value  => sub {
          shift =~ m~^ticket/(\d+)$~i;
          return $1;
      },
      value2form  => sub {
          return 'ticket/' . shift;
      },
  },
  admin_cc        => {
      validation  => {
          type    => ARRAYREF,
      },
      list        => 1,
      rest_name   => 'AdminCc',
  },
}}

🦋 LIST ATTRIBUTE PROPERTIES 🦋

List attributes come with these properties, no cap:

When they're called as accessors, they return a list of items 📋
When they're called as mutators, they only accept an array reference (yes, only, don't try anything cute) ⚠️
Convenience methods add_attr and delete_attr are available! For example:

# Get the list
my @requestors = $ticket->requestors;

# Replace with a new list
$ticket->requestors( [qw(dude@localhost)] );

# Add some random guys to the current list
$ticket->add_requestors('randomguy@localhost', 'evil@local');

👑 SPECIAL ATTRIBUTES 👑

id and parent_id are the special ones, the VIPs, the main characters. Various DB-related methods use them, and these three are especially reliant on them:

autostore
autosync
autoget

🔥 METHODS 🔥

new — the Constructor, obviously 💅
_generate_methods — this class method generates accessors and mutators based on the _attributes method that your class should provide. And for items that are lists? It creates 'add_' and 'delete_' methods too. So for instance, these two attributes specified in _attributes will generate the methods 'creator', 'cc', 'add_cc', and 'delete_cc':

creator => {
  validation => { type => SCALAR },
},
cc => {
  list => 1,
  validation => { type => ARRAYREF },
},

_mark_dirty($attrname) — marks an attribute as dirty 😈
_dirty — returns the list of dirty attributes. yes, we're keeping track, always watching 👀
_mark_dirty_cf($attrname) — marks a custom flag as dirty.
_dirty_cf — returns the list of dirty custom flags.
to_form($all) — converts the object to 'form' (this is the thing the REST protocol uses). It's done based on the _attributes method. If $all is true, it creates a form from all of the object's attributes and custom flags. Otherwise it uses only the dirty ones (peep the _dirty method). Defaults to the latter, so dirty-only unless you say otherwise 💖
from_form — sets the object's attributes from a form received from the RT server 📥
param($name, $value) — sets an arbitrary parameter.
cf([$name, [$value]]) — this one's got layers, bestie. Give it no arguments and it returns the list of custom field names. Give it one argument and it returns the value of custom field $name. Give it two arguments and it sets custom field $name to $value. And if you hand it a reference to a hash, it uses that as a list of custom fields and their values, returning the new list of all custom field names 🌈
rt — get or set the 'rt' object, which should be of type RT::Client::REST.

💀 DB METHODS 💀

These are the methods that have to do with reading, creating, updating, and searching objects. the whole lifecycle, periodt.

count — takes the same arguments as search() but returns the actual count of the found items. And it throws the same exceptions. equal opportunity drama 😭
retrieve — retrieves the object's attributes. but heads up: the 'id' attribute must be set for this to work, no id no service 🚫
search (%opts) — this one's used for searching objects. It returns an object of type RT::Client::REST::SearchResult, which you then use to process your results. %opts is a list of key-value pairs, and they go like this:
- limits — a reference to an array containing hash references with limits to apply to the search (think SQL limits, iykyk).
- orderby — specifies the attribute to sort the result by (in ascending order) ⬆️
- reverseorder — if set to a true value, it sorts by the attribute specified by orderby but in descending order ⬇️

⚠️ If the client can't construct the query from the arguments you specified, or if the server can't make it out either, then RT::Client::REST::Object::InvalidSearchParametersException gets thrown. so be careful with your params fr fr

store — store the object. If 'id' is set, this is an update; otherwise a new object gets created and the 'id' attribute gets set 🎉 And note that only changed (dirty) attributes are sent to the server — efficient queen 💅

⭐ CLASS METHODS ⭐

use_single_rt — takes a single argument — an RT::Client::REST object — and makes this class use it for all instantiations. For example:

my $rt = RT::Client::REST->new(%args);

# Make all tickets use this RT:
RT::Client::REST::Ticket->use_single_rt($rt);

# Now make all objects use it:
RT::Client::REST::Object->use_single_rt($rt);

use_autostore — turn autostoring on and off. Autostoring means you don't have to explicitly call store() on an object — it just gets called automatically when the object goes out of scope. the laziest, most iconic feature 🫶

# Autostore tickets:
RT::Client::REST::Ticket->use_autostore(1);
my $ticket = RT::Client::REST::Ticket->new(%opts)->retrieve;
$ticket->priority(10);
# Don't have to call store().

use_autoget — turn the autoget feature on or off (it's off by default, okay). When it's set to on, retrieve() gets automatically called from the constructor if it's called with that object's special attributes (go peek at "SPECIAL ATTRIBUTES" above) ✨

RT::Client::Ticket->use_autoget(1);
my $ticket = RT::Client::Ticket->new(id => 1);
# Now all attributes are available:
my $subject = $ticket->subject;

use_autosync — turn the autosync feature on or off — again, off by default. When it's set, every time an attribute is changed, the store() method gets invoked. and like… that may be pretty expensive, so just know that going in 😬
be_transparent — this turns on autosync and autoget together. Transparency is a neat idea, ngl, but it may be expensive and slow. Depending on your circumstances, you may want a finer control of your objects. What transparency does is make your retrieve() and store() calls invisible:

RT::Client::REST::Ticket->be_transparent($rt);

my $ticket = RT::Client::REST::Ticket->new(id => $id); # retrieved
$ticket->add_cc('you@localhost.localdomain'); # stored
$ticket->status('stalled'); # stored

# etc.

🚨 Do not forget to pass the RT::Client::REST object to this method. seriously. don't forget.

🌈 SEE ALSO 🌈

RT::Client::REST::Ticket, RT::Client::REST::SearchResult.

💜 AUTHOR 💜

Dean Hamstead <dean@fragfest.com.au>

🍓 COPYRIGHT AND LICENSE 🍓

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

and that's the whole page bestie 🎀 mwah 💋 this was perl v5.40.1, dated 2026-04-21, from the RT::Cl...Object(3pm) page in User Contributed Perl Documentation — go build something iconic with it ✨👑

📦 where this page comes from

ubuntu stonking: librt-client-rest-perl 1:0.73-1 · Artistic-1.0-Perl OR GPL-1.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash on 2026-11-03: a language model's rewrite of the original, under its terms