Updating contacts forcibly sets exclusion state

[mrtsbt]

When updating a contact's properties with managemanycontacts on a mailing list, one can use the addnoforce option to preserve the contact's subscription state, but not the exclusion state. This is a regression from earlier behaviour, likely introduced by https://github.com/mailjet/mailjet-apiv3-go/issues/73

Using an older version without the IsExcludedFromCampaigns field, the exclusion state would not be touched by updating the contact. In newer versions, the exclusion state will be set to either true or false, but it's apparently not possible to simply keep the state. Library users are now forced to first read the state of all contacts and manually applying the correct value prior to updating other properties. (Tested with github.com/mailjet/mailjet-apiv3-go v0.0.0-20190115155311-e508c28bf116 versus github.com/mailjet/mailjet-apiv3-go/v3 v3.1.1)

Note that the api reference is not entirely clear on this topic, as it merely states with regard to the isExcludedFromCampaigns flag that

When true, the contact will be added to the exclusion list and will not be receiving any marketing emails. Default value: false

but doesn't mention any effect if the flag is false, nor that there actually might be a difference between false and not set.

Example Code

```golang mailjetClient := mailjet.NewMailjetClient(s.mailjetConfig.Public, s.mailjetConfig.Private) // only a single contact for demonstration purposes, usually this would be a large bulk update contacts := make([]resources.AddContactAction, 0, 1) addContactAction := resources.AddContactAction{ // Note that we don't set the IsExcludedFromCampaigns field here. // This contact will be removed from the exclusion list in newer library versions, // but would keep the existing state in older versions. Email: email, Name: name, Properties: struct{ ExampleProperty string }{ExampleProperty: "example value"}, } contacts = append(contacts, addContactAction) payload := resources.ContactManagemanycontacts{ Contacts: contacts, } if s.mailjetConfig.MailingList != 0 { payload.ContactsLists = []resources.ContactsListAction{ { ListID: s.mailjetConfig.MailingList, Action: "addnoforce", }, } } fmr := &mailjet.FullRequest{ Info: &mailjet.Request{ Resource: "contact", Action: "managemanycontacts", }, Payload: &payload, } var data []struct { JobID int `json:"JobID"` } if err := mailjetClient.Post(fmr, &data); err != nil { fmt.Println(err) return } ```

[tsidei]

Yeah, I see the issue. You're right about where the regression was introduced. We'll have to make that field as a pointer so it's not included if not set. I'll create a PR for that, thanks for submitting the issue

[tsidei]

fixed in the latest release

[mrtsbt]

@tsidei Big thanks for fixing this!

But the new release still poses problems for me:

$ go get github.com/mailjet/mailjet-apiv3-go/v3@v4.0.0
> require github.com/mailjet/mailjet-apiv3-go/v3: version "v4.0.0" invalid: should be v3, not v4
$ go get github.com/mailjet/mailjet-apiv3-go/v4@v4.0.0
> go: github.com/mailjet/mailjet-apiv3-go/v4@v4.0.0: go.mod has non-.../v4 module path "github.com/mailjet/mailjet-apiv3-go/v3" (and .../v4/go.mod does not exist) at revision v4.0.0

I think that's because go.mod still contains module github.com/mailjet/mailjet-apiv3-go/v3 and go's semantic import versioning expects a v4.0.0 release to be in a .../v4 module?

[tsidei]

yes, sorry, missed to change it. I'll release a fix release shortly.