possiblellama / worklog Goto Github PK

Describe the bug
When adding multiple of the same tags, they are all added. Instead only 1 of the same items should be added.

To Reproduce
Steps to reproduce the behaviour:

1. worklog create --title "foo" --tags "a, a, b"
2. worklog print -t
3. Tags: [a, a, b]

Expected behaviour
worklog print -t should print:
Tags: [a, b]

with the tags being deduplicated.

Environment (please complete the following information):

• Linux/Mac
• Version 0.6.0

Additional context
This fix should be applied when being saved, not on being printed.
This applies to creating and editing.

Fix

Following on from the export, we want to be able to import all work from the single file into the local repository.

worklog import /tmp/foo

This could allow also allow for easy transfer between repo types.

Get a high level of certainty that the service logic all works as expected.

This will include creating an in memory repo to support testing.

Allow elements of the app to push events, which can then be formatted as the user wants.

For instance printing to standard out in a given format can be expanded to complementary information such as "Saved worklog", "No worklogs found" etc. which are currently just plain text to standard out.

EDIT:
This can be used to provide debug information, and get feedback as to what the application is doing.
As part of this, can add in some logging off to NewRelic, passing in the key via an arg at build time.

As part of this work, will need to add in an opt out of collecting data when running configure, as well as hiding data that we want to log locally, but don't want to send off to NewRelic.

Having data being sent off to NewRelic will allow for analysis of how the CLI is being used to enable further enhancement.

Allow users to specify an author, without having an author in the config.yml.

Such as worklog create ... --author "bob"

At the same time, move the field author into the defaults with the configuration.

After a record of work has taken place. Save this to the default location.

Add a default location to the metadata within the ~/.worklog.yml file. Possibly this will change to ~/.worklog/config.yml, and the records will be saved to this location unless otherwise specified.

Add an ID, and a revision field into the worklog.
A NewWork() will generate a new UUID, and set revision to 1.

ID is unique for a worklog.
Revision is incremented with each edit.

The ID will enable selecting a specific worklog for printing, editing or removal.

The ID will be the same across all revisions of the worklog.

Within the yamlRepo, the filename will be <DATE>_<REVISION>_<UUID>.

Choosing between json, yaml, pretty formats.

As an argument to the CLI, ie print --yaml, using a default from the config, or defaulting to "pretty".

Whilst here, clean up the default pretty output to not print the entire object (leaving off createdAt).

Add implementation for the MySQL repo.

Config can specify a connection string.

Uses the MySQL repo as the default.

Makefile includes a command to start a MySQL docker container with the correct ports/volumes specified.

Starts an API server (probably using mux), that will run until interrupted.

This will allow for programmatic access by other applications such as a UI.

worklog api

Explicitly stating that there aren't any worklogs returned if the date range doesn't have any.

Get a high level of certainty that the repository logic all works as expected.

To get worklog print xxx to print what has happened today, you need to specify the day before.

You should be able to specify today's date, and get back everything that has happened since the start of the day.

Although it's most noticeable with today, to get any day's logs, you would have to put the day before.

This ticket will also add a --today and --thisWeek flag.

• --today Gets all from midnight tonight (not the last 24hours)
• --thisWeek Gets all from the most recent Monday

As a user, I want to be able to hit tab, and have autocomplete options appear/fill in what I am missing.

Add in repo from Bolt.

This will create a file on disk that will store all details of Worklogs.

Long term aim is to replace the custom yaml repo with this. The custom yaml repo has a lot of logic within it that is difficult to test.

Before replacing the yaml repo with this, the export and import functionality needs to be in place to allow transfer of Worklogs between repo types.

Print a specific worklog, or set of worklogs.

Options that should work after change.

• print --latest printing most recently created worklog
• print --today --tags "foo" Alongside the previous command (in this case --today), filter by those that contain the tag "foo"
• print --today --title "bar" Alongside the previous command (in this case --today), filter by those that contain in the title "bar"

worklog create ... --when "2021-03-29" from the UK, creates a "when" without a timezone.

When parsing the --when flag, use the computers timezone as the default instead of assuming UTC.

Is your feature request related to a problem? Please describe.
Given that the duration field is intended to be a time taken, build upon that to clearly be a time in minutes.

Describe the solution you'd like
The duration field within Work, being changed from an int to Time.Duration.

Additional context
When creating/editing, the parameter will still be an integer. This is then converted as number of minutes. Seconds and below are treated as 0's.

Take data input from the terminal as to what work has been done.

Get a high level of certainty that the models logic all works as expected.

Get the metadata of who has performed the work from a file.
Expecting the file to be in .yml format, with a name field.

Other details can be added later.

Get all the records that have been created since date, and show their titles.

yamlRepo's results from GetBetweenDates should be sorted by When.

worklog print currently has a --startDate, and it should also have an --endDate to allow for specific date ranges to be printed.

At the same time, the --today and --thisWeek flags should be restricted to just today and Sunday respectively.

As well as when it took place, a time taken to complete the action can be provided.

Get a high level of certainty that the command logic all works as expected.

Make sure that the commands are doing what we expect them to do, with each argument being passed in isolation and in combination.

This will be testing what the commands send to the services, not what the logic of the services do.

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behaviour:

1. Command
2. See error

Expected behaviour
When running worklog create "foo" --title "abc" it works as expected. This isn't causing any problems, but could be confusing.

Screenshots
N/A

Environment (please complete the following information):

• OS: Darwin
• Version 0.6.0

Additional context
Not causing any issues when running.

This can be solved by setting the number of arguments that create accepts (does not count the named arguments) as 0.

As a user, I want to be able to easily specify the ID of an item of Work.
This will make it easier to write down

A generated ID should fit the regex ^[a-z0-9]{20}$.

Changed generated ID to fit regex ^[a-f0-9]{20}$.

Add in integration for

• Unit testing
• Building an artifact

This gives confidence that the application is working as expected, and will continue to do so when changes are made.

Allowing all items from the repo to be exported to a single file.

Example: worklog export /tmp/output.

This will allow for all worklogs on one computer to be moved to another, or stored in another location.

It could also allow transfer of worklogs between repo types in the future.

Getting a high level of confidence that the helpers do what they are supposed to do.

Add the ability to set a cloud provider (such as Google) as the backend repo.

This should allow for "backups" into the cloud via the import/export to different repo types.

Will need to look at how to authenticate against Google or any other providers.

Is your feature request related to a problem? Please describe.
Occasionally, the tests fail because the mocks are expecting the time to be a millisecond before the actual time.

Describe the solution you'd like
Use an interface for the time functions we need, and then mock them out when testing.

Additional context
This only needs to be in place for unit tests, everything else will use the real implementation.

Arguments are not behaving correctly.
Need to be able to accept single arguments (that don't cause an exit), along with pair arguments.
Tests for the arguments don't seem to be working correctly either.

Allowed

• exe -v
• exe --version
• exe --title "foo" --description "bar"

Not allowed

• exe -v "foo" The -v flag doesn't have a value "foo".
• exe --title "foo" --print "1970-01-01" The --title flag indicates a write operation. The --print flag indicates a read operation. Don't have both.

When creating a worklog with an empty tag, it should remove all empty tags. All tags should be trimmed of whitespace at the beginning and end of the string as well.

worklog create --title "foo" --tags "foo , \n, , bar"

Should result in

...
title: "foo"
tags: ["bar", "foo"]
...

Note: These values are switched due to them also being sorted alphabetically.

Add in SCA and SAST scans to pipeline.

When printing, can select by list of ID's.

worklog print <ID1> <ID2>

Any filter is applied on top of selecting the ID's.

A partial ID can be used. For example worklog print abc would print any ID with abc in it.

Ability to run worklog configure.

• create ~/.worklog/ directory
• create ~/.worklog/config file

There is a subcommand named defaults.
This accepts the following parameters:

• --author
• --duration

The full command to configure and add defaults would be the following:
worklog configure defaults --author "foo" --duration 10

Is your feature request related to a problem? Please describe.
Ability to specify conditions, which if the input doesn't match, it asks for stdin, or rejects.

Describe the solution you'd like
Within the config, a regex is supplied for each field (such as title), which is compared against when creating or editing. If the input doesn't match that, it seeks from stdin.

A command line arg (--verify-reject ?) can be used to ignore stdin and cause an exit code instead.

Use case

• When using a card system setting a regex that the title must match.
• Needing the when date to be within x days of now.

Add into Readme examples of:

• Creating a new worklog (simple)
• Creating a new worklog (complex)
• Printing all since date (specify format of date to be provided)
• Printing all today (specify since midnight, not 24 hours)
• Printing all this week (specify since midnight Monday, not 168 hours)

Generate a makefile with a series of commands for convenience.

• test
• build
• build binaries for each platform
• run
• format

worklog print --startDate "2021-02-11" gives the message that No work is found between 2021-02-11 00:00:00 +0000 UTC and 000-12-31 23:59:59 +0000 UTC with the given filter.

When only specifying the startDate (no endDate), the endDate should be as far in the future as it can be, so all items happening after the given date are returned that match the filter.

Allow for worklogs to be edited.

worklog edit <UUID>

This UUID could be partial, eg if the full ID is 20 characters, if the first 4 characters are unique and that's what is parsed then that can be used.

When creating and displaying work, sort lists (such as tags), alphabetically.

The app should have started with a more MVC pattern to it, with the separation of concerns between the input, output, logic and storage layers.

The app should be refactored to address these concerns, and increase testability at the same time.

Is your feature request related to a problem? Please describe.
We should be using the latest (currently 1.17) version of GoLang.

Describe the solution you'd like

• Upgrade version in GitHub Actions.
• Ensure nothing breaks.

There should be --all tag that can print all fields that are normally hidden by printing a 'pretty' version of the work.

Ability to add tags to a record.

This is a list of comma separated strings.

The use case here would be for filtering by projects.

Get a high level of certainty that the systems logic work as expected.

This will cover calling the commands with the real implementations, checking that files are created properly, with correct details, and that they are returned correctly when printed.

There will be a new command in the makefile, which runs the integration tests.

There will be a new step in github to run the integration tests.

Is your feature request related to a problem? Please describe.
Since #73 is starting to introduce real databases and filestores, we should start sanitising input strings.

Describe the solution you'd like
All input from creation, editing or search terms should be sanitised before using them.
bluemonday's would be a good example parser to use. bluemonday.StrictPolicy() will work well here, as we don't need to care about formatting any HTML, as this will primarily be a CLI application.

Additional context
This should be done before the 0.7.0 release.