I have a category that returned 1072 percent complete, this won't fit into unit8.

context: unplanned expense that had to be funded, which pushed it way over the monthly goal.

Your FOSSA integration was successful! Attached in this PR is a badge and license report to track scan status in your README.

Below are docs for integrating FOSSA license checks into your CI:

• CircleCI
• TravisCI
• Jenkins
• Other

First of all, thanks a lot for creating this package! It's a good change for me to save some money using YNAB while learning the golang at the same time. :) So on to my problem:

I'm trying to use ynab.go to add transactions to my YNAB account. I'm currently stuck with this error when I try to client.Transaction().BulkCreateTransactions()

api: error id=400 name=bad_request detail={"transactions":["This field is required."]}

I'm not really sure how to best debug this issue. I've tried copying the code from TestService_BulkCreateTransactions(), filling out my account and budget IDs, but I still get the same error.

Inspecting the payload that ynab.go creates in BulkCreateTransactions it seems that everything looks fine (I've masked my account id):

{
  "transactions": [
    {
      "account_id": "MY-ACCOUNT-ID",
      "date": "2018-11-13",
      "amount": -9000,
      "cleared": "cleared",
      "approved": true,
      "payee_id": "0d0e928d-312a-4bcd-89c4-e02f40d1fe46",
      "payee_name": "bla bla bla",
      "category_id": "f3cc4f55-312a-4bcd-89c4-db34379cb1dc",
      "memo": "nice memo",
      "flag_color": "blue",
      "import_id": "asdfg"
    },
    {
      "account_id": "MY-ACCOUNT-ID",
      "date": "2018-11-13",
      "amount": -9000,
      "cleared": "cleared",
      "approved": true,
      "payee_id": "0d0e928d-312a-4bcd-89c4-e02f40d1fe46",
      "payee_name": "bla bla bla",
      "category_id": "f3cc4f55-312a-4bcd-89c4-db34379cb1dc",
      "memo": "nice memo",
      "flag_color": "blue",
      "import_id": "asdfg"
    }
  ]
}

Not quite sure where to go from here? It sure looks like the transactions field is included in the payload. So maybe the actual error is something else?

Support of ID field in the TransactionPayload struct. Needed for UpdateTransactions() method. Official YNAB doc: https://api.youneedabudget.com/v1#/Transactions/updateTransactions

See https://goreportcard.com/report/github.com/brunomvsouza/ynab.go#golint

warning: redundant if ...; err != nil check, just return error instead. (golint)

Closes https://github.com/brunomvsouza/ynab.go/issues/5

Mea culpa :) Thank you @askielboe for finding the issue and for the through report (https://github.com/brunomvsouza/ynab.go/issues/5) you created. It helped to solve this quickly.

All API's PUT and POST requests need to be sent with Content-Type: application/json.

• Add the fix
• Add regression tests so it doesn't happen again

After the CI run I'll create a new release so ppl can use.

Code below should behave as expected after this PR is merged.

func ExampleClientServicer_Transaction_fix() {
	c := ynab.NewClient("<API-TOKEN>")

	bucketID := "<BUCKET-ID>"
	transactionDate, err := api.DateFromString("2018-01-01")
	transactions := []transaction.PayloadTransaction{
		{
			AccountID: "<ACCOUNT-ID>",
			Date:      transactionDate,
			Amount:    int64(-10000),
			Cleared:   transaction.ClearingStatusUncleared,
			Approved:  true,
		},
		{
			AccountID: "<ACCOUNT-ID>",
			Date:      transactionDate,
			Amount:    int64(-10000),
			Cleared:   transaction.ClearingStatusUncleared,
			Approved:  true,
		},
	}

	r, err := c.Transaction().BulkCreateTransactions(bucketID, transactions)
	if err != nil {
		log.Fatal(err)
	}

	fmt.Printf("%#v\n", r)
}

func ExampleClientServicer_Transaction_fix2() {
	c := ynab.NewClient("<API-TOKEN>")

	bucketID := "<BUCKET-ID>"
	transactionDate, err := api.DateFromString("2018-01-01")
	if err != nil {
		log.Fatal(err)
	}

	tt := transaction.PayloadTransaction{
		AccountID: "<ACCOUNT-ID>",
		Date:      transactionDate,
		Amount:    int64(-10000),
		Cleared:   transaction.ClearingStatusUncleared,
		Approved:  true,
	}

	r, err := c.Transaction().CreateTransaction(bucketID, tt)
	if err != nil {
		log.Println(err)
	}

	fmt.Printf("%#v\n", r)
}

In order to implement money transfer transactions between accounts, the transfer_payee_id field from the account must be accessible within the Account struct

• Backward incompatible changes to entities that use budget.DateFormat and budget.CurrentFormat as per changes in the YNAB API both types are now nullable.
• Add two new service calls for fetching and updating a category for a given month.

"We’ve soft-deprecated POST /budgets/{budget_id}/transactions/bulk. It still works and we still support it, but POST /budgets/{budget_id}/transactions with a transactions array is likely the more future-proof way of creating multiple transactions."

Source: https://www.youneedabudget.com/release-notes/

As seen here the structure updated to be:

{
  "category": {
    "budgeted": 0
  }
}

Fixes https://github.com/brunomvsouza/ynab.go/issues/24

When using this code to update the budgeted amount the call succeeds but it doesn't update the budgeted amount in YNAB:

client := ynab.NewClient(globals.AccessToken)
budgets, err := client.Budget().GetBudget(globals.BudgetID, nil)
if err != nil {
	panic(err)
}

for _, ynabCategory := range budgets.Budget.Categories {
	// 14504ffc-ae7a-48b6-a030-65d4e20fa830
	payload := category.PayloadMonthCategory{Budgeted: 1500}

	updatedCategory, err := client.Category().UpdateCategoryForCurrentMonth(globals.BudgetID, ynabCategory.ID, payload)
	if err != nil {
		panic(err)
	}
	fmt.Println(reflect.TypeOf(updatedCategory))

}

https://api.youneedabudget.com/v1#/Transactions/createTransaction

According to the documentation the api support adding sub transactions when making a transaction. It doesnt look like this feature is present in the library. Any reason in particular it isnt? Any complaints with me adding and opening a PR?

Background

The github.com/brunomvsouza/ynab.go uses Go modules and the current release version is v2. And it’s module path is "github.com/brunomvsouza/ynab.go", instead of "github.com/brunomvsouza/ynab.go/v2". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2. https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v2.0.0 of the brunomvsouza/ynab.go:

$ go get github.com/brunomvsouza/[email protected]
go: finding github.com/brunomvsouza/ynab.go v2.0.0
go: finding github.com/brunomvsouza/ynab.go v2.0.0
go get github.com/brunomvsouza/[email protected]: github.com/brunomvsouza/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

run go get github.com/brunomvsouza/ynab.go, the version will stuck in v1.3.0:

$go get github.com/brunomvsouza/ynab.go
go: downloading github.com/brunomvsouza/ynab.go v1.3.0
go: github.com/brunomvsouza/ynab.go upgrade => v1.3.0

SO anyone using Go modules will not be able to easily use any newer version of brunomvsouza/ynab.go.

Solution

1. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules). Ensure compatibility for downstream module-aware projects and module-unaware projects projects

2. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/brunomvsouza/ynab.go/v2 as per the specs. And adjust all internal imports. The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

If you don't want to break the above repos. This method can provides better backwards-compatibility. Release a v2 or higher module through the major subdirectory strategy: Create a new v2 subdirectory (github.com/brunomvsouza/ynab.go/v2) and place a new go.mod file in that subdirectory. The module path must end with /v2. Copy or move the code into the v2 subdirectory. Update import statements within the module to also use /v2 (import "github.com/brunomvsouza/ynab.go/v2/…"). Tag the release with v2.x.y.

3. Suggest your downstream module users use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/brunomvsouza/ynab.go@version-tag, module users need to use this following way to get the brunomvsouza/ynab.go: (1) Search for the tag you want (in browser) (2) Get the commit hash for the tag you want (3) Run go get github.com/brunomvsouza/ynab.go@commit-hash (4) Edit the go.mod file to put a comment about which version you actually used This will make it difficult for module users to get and upgrade brunomvsouza/ynab.go.

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 2 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

• https://github.com/golang/go/wiki/Modules#semantic-import-versioning
• https://golang.org/cmd/go/#hdr-Module_compatibility_and_semantic_versioning
• https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher