Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
) There are two parts to this: 1. The test is a bit funny, because it didn't create any projects. When there are no objects to test permissions against, tutelary pretends that there's a `None` object, and that gives a 403. When there are project instances around, the permissions checking works and you get a 200 and a project list as the result. I've split the test into "no projects" and "has projects" cases. 2. The `users` field appearing in the project list results came from a problem with the `DetailSerializer` class. This serializer mixin is intended to remove specific fields from model instance serialization results in "non-detail" views. For a view that returns a list of objects of a model class that has a `DetailSerializer` mixin, detail-only fields (specified by a `Meta` option) are removed from each instance in the serializer result. However, if the model class has a *member* that also has a `DetailSerializer` mixin, the detail-only fields of the object contained in each member of the result list *aren't* removed. The effect of this is that detail-only fields appear in nested objects in the serializer results. In this case, the user list is a detail-only field. To fix this, I've added an extra `hide_detail` keyword argument for `DetailSerializer` that can be used to force the mixin to hide detail-only fields in contexts where it normally wouldn't do so. Adding that to the place in `ProjectSerializer` where the serializer for the organization is defined prevents the user list from appearing in the serializer results.
- Loading branch information