An interface to the RequestTracker API.
install.packages("rt")
To start using the rt
package, log in to your RT instance by setting the server URL in using Sys.setenv
and use rt_login()
to log in and store your session locally.
Below, we log into Best Practical’s demo installation of RT:
library(rt)
Sys.setenv("RT_BASE_URL" = "https://demo.bestpractical.com")
rt_login() # Enter demo/demo
Once you are successfully logged in, you’re all set to use the package. The rt
package supports all of the RequestTracker REST API:
rt_login()
rt_logout()
rt_ticket_properties()
rt_ticket_links()
rt_ticket_attachments()
rt_ticket_attachment()
rt_ticket_attachment_content()
rt_ticket_history()
rt_ticket_history_entry()
rt_ticket_search()
rt_ticket_create()
rt_ticket_edit()
rt_ticket_history_reply()
rt_ticket_history_comment()
rt_ticket_links_edit()
rt_user_properties()
rt_user_create()
rt_user_edit()
rt_queue_properties()
Note: Most of these functions support being chained together (for example, with the %>%
).
See the included vignettes for more information about usage.
A test suite is provided that is comprised mostly of integration tests that are configured to run against a local installation of RT. By default, running devtools::test()
will only run a small subset of the full test suite: those that do not depend on being able to call out to an RT installation (i.e., unit tests).
To run the full test suite locally,
Start a local RT installation with Docker:
Turn on integration tests for your session
Sys.setenv("RT_INTEGRATION" = TRUE)
Run devtools::test()
from the same session as (2)
rt_api
objectsAll API calls go through an intermediate state as an rt_api
object, which is made up of three parts:
content
, generally returned as a tibble/data framepath
or URL that was accessedresponse
from the API.This is mainly to help normalize out some of the inconsistencies in the RT API itself and make implementing the API call wrappers easier.
Let us know about any issues or bugs.