halprin / fcli Goto Github PK

To simplify distribution and usage of the fcli tool, please consider adding Docker scaffolding to build an image that can be run independent of installed Python versions, package versions, etc. on the host system.

This way, to use the tool, one would run the appropriate image such that fcli executed in the context of the container like so:

docker run -v ~/.fcli:/.fcli halprin/fcli fcli version

To that end, I put together a Dockerfile that builds a ~90mb image that provides this functionality; it's included in a PR I just submitted:

#39

The current commands will create either a triage task or a backlog task, but there's no way to create a story. Let's add the ability to create a story.

Add a label to an issue
Also add an option to add a label to a ticket when it's created

when the date needed on a triage issue is in the past, the date score should be 10

Add a CLI option to automatically put the created task into In Progress. By default the task should still be created in To Do.

A user must reenter his or her credentials for every ReST request if they choose to provide credentials via keyboard. Have the credentials saved in memory between the requests so the user does not need to repeatedly enter the credentials.

Sometimes for a story the cost of delay significantly increases or decreases at a particular time. Add the ability to define a max or min cost of delay value. The fcli backlog score command will use the due date of the story plus the min or max cost of delay value defined to calculate what the cost of delay is at the current point in time, then recalculate the VFR value of the story accordingly.

I'd like the fcli tool provide a method to update the fixed version/s field of a JIRA story.

The JQL queries are rather specific for FC team needs. A step to take to make things a bit more generic would be to add a way to configure the custom fields that are queried upon.

Set-up CI to run PEP 8 on the source code to ensure PEP 8 compliance. Fail the PR if compliance fails.

Add the ability to quickly reschedule a triage issue

• this could cover EL issues as well (or could be fcli el reschedule
• by default will bump date forward 2 weeks
• can take an optional date in the future

As a QPP Engineer, so that I can automate the creation and maintenance of pages found in Confluence, I would like FCLI to be able to write to pages in Confluence.

Consider the following example:

./generate_qoe_report.py | fcli --confluence --update-page --page-id=123456789

This example is meant to demonstrate a workflow rather than any particular syntax or command line options.

Here, the results of running a report are piped to FCLI which would then update Confluence. This would allow offline or batch creation or updating of pages using logic from outside of Confluence; that is, it would provide a channel by which other sources may be indirectly integrated with Confluence.

Create a new function that will automatically create a triage task for each product team based on a summary and description. e.g.: Create an SIA task for each product team for a PI

By default assign the triage task to the creator. If this is a task for the standard backlog, this issue does not apply - do not assign the task to the creator.
Create the --no-assign option to not assign the task.

Be able to create and score EL tasks. Also update the README.md.

Add a new command that will display all of the authenticated user's assigned issues across all of JIRA.

Given a ticket number and a comment, add said comment to ticket.

Currently, Parent Story is required because the CLI will create a task and associate it with the Parent Story entered. But, there are use cases where a user will want to just create a task not associated to a story for the backlog. If the Parent Story is not entered, then an unassociated task should be created.

Include the following sections.

• Installation via pip. Perhaps need to outline installing Python 3.
• Ways to specify credentials.
• Usage.

Must be well formatted and look pretty, oh so pretty!

Be able to specify a title, description, and master story ID.

That will create a new task on the main FC board. It will prepend the master story ID to the task's title. It will associate the task to the master story through a to-be-determined relationship. Do not automatically assign the story to the creator. The CLI command needs to be determined.

Be able to specify an issue ID (e.g. QPPFC-178) and an ends state. That issue will then be moved into that end state.

As a User, I want the FCLI to parse a formatted User Story and output a formatted JIRA ticket connected to the associated meta data.

• Link the ticket to the persona defined in the story
• Link the ticket to an Epic related to the story details
• Generate labels based on the story details

it appears that the dates are not being parsed correctly and are all being assigned a score of 0

Add a new command that will display all the unassigned issues (stories or tasks in the current sprint on the backlog, EL board, or triage board). In displaying the issues, provide the ID and the name. This will only work for the QPPFC project.

As a happy user of this tool, I would like Dependabot configured for the packages in this tool. If you need help investigating if the tool understands inline setup.py info and not pip requirements.txt (which this project does not use at this time), let me know and I will try and help.

If only one is entered, use that string for both.

I will be implementing this per the forum post here so I can begin watching 1 or more related Jira issues at a time.

Publish this project in PyPI so one can easily install the CLI.

So they are not unassigned.

As suggested, parameterize Jira instance URL and other custom Jira field items to allow using a Jira instance other than the default.

As a QPP Engineer, so that I may interact with content found in Confluence, I would like the ability to read / search pages in Confluence using FCLI.

This is similar to #84 (read tickets from Jira), but for Confluence. As with the Jira ticket, there would be a single read function that would accept CQL and return the results in some format that could be further processed (e.g., JSON). A "read" would be a search where the CQL specifies a single pageid and multiple (most?) fields; a typical "search" would return a default subset of fields from what a typical "read" would return.

Now that QPPFC is moving towards specifying Importance, LOE (Level of Effort), and Due Date to all triage tickets, we should likely add these as parameters as a user can hand off and add to the bottom of the description to avoid the need to do manual edits in the browser after the fact.

I would like to work on this if you think it is a useful addition.

We had discussed this outside of Github, are you still interested in this?

Currently, you can authenticate with a --username parameter and typing in the password interactively or via pipe. However, it might be more conducive for password managers to allow the use of environment variables so a user can use something like JIRA_USER and JIRA_PASS so you do not need to enter passwords or do weird piping with additional parameters.

I will start a branch and work on a PR if you are interested.

Add the ability to assign a jira ticket to a specific person
Also add an option to do this when creating a jira ticket in the various ways allowed

• Allow a username to be specified on the command line.
• Do not allow a password to be entered in on the command line.
• Allow a . file to be read in the home directory that contains the username and password. For example ~/.fcli.

As a QPP Engineer, so that I can interact with existing tickets in Jira, I would like FCLI be able to read a ticket from Jira and present it to me.

A possible implementation could be to have FCLI accept a ticket id and return the result, possibly in JSON format. It may be nice to be able to specify which fields to return.

Initially, my thinking was that one would send FCLI a ticket id for a "read" function and have a separate function to perform searches. The read function would accept a ticket id and return many (most) of the fields; the search function would accept a series of criteria and return ticket ids or some subset of fields.

Now, I'm thinking that they're actually one function. A ticket "read" could be a search where the ticket id == (some value) and the list of fields is (most of the fields).

To simplify and or permit expressive searching, perhaps we allow arbitrary JQL.

This is unlike allowing arbitrary SQL because:

1. JQL doesn't have the ability to write or update -- it can only read
2. requests are performed with the user's access level -- one can't "trick" the system into returning anything that the user wouldn't otherwise be able to access
3. when you perform a search in Jira, the resulting URL (hence, GET) includes the URL-encoded JQL -- we wouldn't be doing anything that Jira doesn't already do

We update tasks' scores even if they are the same. As in we make the ReST call even if nothing would change. Change this to determine whether the score is changing and only make the ReST call if the score changes.

When an issue is moved to Closed or Resolved state a reason should be added to the issue so that the UI crosses off the issue.

If a Closed or Resolved issue is moved back to any other state then remove the reason.

The help output is displayed even on a successful invocation of fcli. It should only be displayed on an incorrect invocation or if --help is specified.

There is the handy feature to link tickets. It is a separate metadata field and a little more useful in ticket references than just BOARID-1234 type links in the comments for reviewing ticket history. I use it a lot and think a CLI subcommand to link other issues to yours would be helpful.

If the parent story is in an active sprint, put the issue also in the same active sprint.

Specific fields for importance, effort, and due date were added for triage and EL tasks. Use these when creating and scoring the tasks.

When getting a story or task that isn't in the QPPFC Jira project, a BacklogStory or BacklogTask is still created. Instead an Issue should be created.

Add flag to backlog score to avoid transition

something like --no-transition