jcartwright / rally_api Goto Github PK

Build an example script of how to use the RallyApi to create a Defect

Build a script to get a list of "my work", which should include In Progress and Defined (Backlog) stories and defects.

As I'm building up some examples of usage, I noticed the difficulty of creating maps and extracting the _ref values where needed. It seems like we could have a more elegant way, such as duck-typing maps, to get the _ref values within pattern matches or inside functions.

Write an example script to "rename" a tag across all objects in a project

Rebuild tests and cassettes on a free community edition of Rally/AC

The RallyAPI supports the Fetch param on create and update calls to allow the user to specify which fields to return after the operation. Need to extend the functions to accept fetch \ "" and pass it thru to POST calls.

https://rally1.rallydev.com/slm/doc/webservice/authentication.jsp

Some actions (i.e. POST, PUT, and DELETE) require a security token. This token requires a HTTP Basic Auth header.

Support the ability to Create (Add), Read, Update, and Delete items from Rally Collections such as Tags, Attachments, Conversations, etc.

Collections can be summarized by suffixing a summarizable collection element name with the :summary keyword. The summary can optionally be grouped by one or more attributes by enclosing a semicolon-delimited list of summary groupable fields within square brackets.

Make sure we don't publish sensitive information to github since this is a public repo. See details for ExVCR here https://github.com/parroty/exvcr#removing-sensitive-data

[] Move API Keys into config/test.exs
[] Sanitize cassettes

Allow options to be used to scope queries to a specific workspace or a specific project.

Rally's API allows for an order clause in the query params. Ensure that this option is properly rallyfied and passed thru.

Basic ability to list workspaces using RallyApi.Workspaces.list

Add workspace and project values to the Client struct, and use them as defaults in all requests when they are set.

Review all Modules for complete and consistent documentation for both @moduledoc and @doc for public functions.

As common patterns and data emerge, I want to pull them out into a shared module. Not sure if a behaviour or protocol is the right implementation, or just a simple module.