Groups are not applied correclty in slices.

[masseelch]

I have the following structs:

type Job struct {
	ID int `json:"id,omitempty" groups:"job:list"`
	Edges JobEdges `json:"edges" groups:"job:list"`
}

type JobEdges struct {
	Users []*User `json:"users" groups:"job:list"`
}

type User struct {
	ID int `json:"id,omitempty"`
	Edges UserEdges `json:"edges" groups:"user:read"`
}

type UserEdges struct {
	Sessions []*Session `json:"-"`
	Jobs []*Job `json:"jobs" groups:"user:read"`
}

type Session struct {
	ID go_token.Token `json:"token"`
	Edges         SessionEdges `json:"edges"`
}

type SessionEdges struct {
	User *User
}

Calling sheriff.Marshal(&sheriff.Options{Groups: []string{"job:list", "user:list"}}, job) on a Job-struct results in the Edges property of the attached users to be included in the resulting map. I'd expect it not be there since the groups given to sheriff.Marshal() are job:list and user:list but the Edges-property has none of the given groups attached.

Example output:

{
  "id": 1,
  "edges": {
    "users": [
      {
        "id": 1,
        "edges": {
          "jobs": null
        }
      }
    ]
  }
}

[mweibel]

I'm not sure I undestand. You give job:list as groups to marshal and the Edges property has the job:list group, so it's correctly attached?

Would be great if you'd give me a link to an example playground (e.g. on play.golang.org) with the buggy behaviour 👍

[masseelch]

I am confused myself now. I tried to reproduce the behaviour, but now its behaving correctly.

This is my example so far. I will try to get it to show the behaviour i described. Don't close yet pls.

[masseelch]

In my machine this is returning:

{
  "edges": {
    "users": [
      {
        "edges": {},
        "id": 1
      }
    ]
  },
  "id": 1
}

Running it on the play.golang.org site however correctly returns:

{
  "edges": {
    "users": [
      {
        "id": 1
      }
    ]
  },
  "id": 1
}

I do not get it.

[mweibel]

Which Go version do you use?
Which sheriff version do you use (go.mod/go.sum)?

I copied your example and it works correctly on my machine.

[masseelch]

Tried with go 1.15 and 1.14.9 (which is the same as the playground uses).
sheriff is on 0.9.0.

I think we can close it then. If i get it to reproduce on playground i will notice you here.

[masseelch]

It is reproducible on here.

You need to run go generate ./ent, ./refresh_db and go run main.go serve. In this case the bug still is there. But it might have to do with one of the other libs i am using there. I am not able to extract a smaller reproducible example. I just recently started go.

Add this to the root for database-config.

// config.yaml
database:
  host: "localhost"
  password: "nopass"
  name: "todo_ent"
  user: "root"
  port: "3308"

[mweibel]

I found the issue: https://github.com/liip/sheriff/blob/master/sheriff.go#L194

Your entities implement Stringer: https://github.com/masseelch/go-api-skeleton/blob/3c0c2b8dcebf22cc72176a46cdd15d7d4b4ed868/ent/user.go#L127

You can implement sheriff.Marshaller on your entities to circumvent that. E.g.

func (u *User) Marshal(options *sheriff.Options) (interface{}, error) {
	return sheriff.Marshal(options, u)
}

This is a bit unfortunate In your case I guess 🤔 Can you adjust the generated code? (well, you can always add this code in another file in the same package, but that's probably a bit ugly).
Otherwise we might need to find a way to prevent this case in a configurable way. I'm open to proposals.

[masseelch]

You can implement sheriff.Marshaller on your entities to circumvent that. E.g.

That'd be a solution. But it is indeed a bit ugly. Maybe there is a way to not generate the String-method.

Otherwise we might need to find a way to prevent this case in a configurable way. I'm open to proposals.

I have no idea how. But i am not very experienced (yet).