Bitwise | in Permission Classes Isn't Working Properly

[decaf-dev]

I have found a weird behavior in my custom permissions that I have setup for my user model view set. I have a model view set with the methods: GET, PUT, and PATCH. The goal of my behavior is to allow an administrator to GET, PUT, and PATCH for any User object. I also want a User to be able to GET, PUT and PATCH ONLY if their id matches the id of the User object that they're trying to edit, basically if they're the owner.

Here are my permissions:

The issue is that when I use the & operator to combine permissions, Django seems to ignore the 2nd operation and default to True, even though the permission resulted in false

As you can see, the isAdmin class returned False and the isUser class was never checked, but the patch method wasn't denied.

Now, if I remove the isUser permission, it will still evaluate False but it will restrict permissions and deny the patch method.

I believe this is a bug because Django is not evaluating the 2nd permission, the isUser permission, when it should. I have tried reversing the order of the permissions and the same thing happens. My authentication is fine and the IsAuthenticated permission works great.

Please let me know if you need more information

[SpookyGlitches]

Hi, any updates on this? I'm trying to do the same where admins and object owners are able to do safe and unsafe methods while other users are only allowed to do safe methods.

I have 2 permission on my class too and the 2nd class permission will not be called (I call print too to check if it's called).

To visualize, here's the row in our good old friend truth table where it is wrong:

CanModifyOrDelete (custom permission)	IsAdminUser	CanModifyOrDelete | IsAdminUser	Expected Behavior	Actual Behavior
F	F	F	Unauthorized	Authorized

Reversing the order to IsAdminUser | CanModifyOrDelete also has the same results as above.

My custom permission CanModifyOrDelete and the IsAdminUser provided by the framework works fine too. So yeah, maybe it's the bitwise | that isn't working properly?

Update: Found an issue disccusion here #7117