Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

admin_only property is not considered for fields in relationships #57

Closed
arnaud-morvan opened this issue Nov 27, 2014 · 2 comments · Fixed by #66
Closed

admin_only property is not considered for fields in relationships #57

arnaud-morvan opened this issue Nov 27, 2014 · 2 comments · Fixed by #66

Comments

@arnaud-morvan
Copy link
Member

excludes_user = self._get_fields_with_property(self._ADMIN_ONLY)

_get_fields_with_property only return top level excludes which is good because sub level excludes should be mixed with overrides parameters like this :
overrides : {
'myrelationname' : excludes: {...}}

@tsauerwein tsauerwein changed the title admin_only don't apply through sequences/relationship admin_only property is not considered for fields in relationships Nov 27, 2014
@tsauerwein
Copy link

_get_fields_with_property only return top level excludes which is good because sub level excludes should be mixed with overrides parameters

So you are ok with the current behavior?

I see three solutions on how to deal with this problem that the admin_only property is only taken into account for fields on the main model:

  1. It's not a bug, it's a feature. If the user wants to exclude fields for child models, he/she has to set 'overrides'. Which is confusing in my opinion.
  2. Check for the admin_only recursively and and set the excludes with the overrides property for child models when creating the schema. The problem is that the user might provide a custom overridesobject, so we would have to merge the user overrides with our overrides. This might be tricky but doable.
  3. Remove the admin_only property. The user would have to specify the includes or excludes via the overrides property. This also allows to hide fields in the user views.

Opinions welcome!

@tsauerwein
Copy link

We agreed to go for option 3, because it should be possible to use the same model with different schemas. And because this is also the way you would do it when directly using ColanderAlchemy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants