@sur5r I actually think you don't even need to belong to two groups for this bug to happen, when I reproduced it my user belonged to one group only but my user did not have write access to stock items owned by his own group...

Can reproduce. @sur5r thanks for reporting it.

In general:
Fixing this should solely focus on getting documented behaviour up and running again. Permissions are due for a rework as described in #2323. That is a more significant conceptual change that should be discussed on a process level before changing the core mechanism.

@matmair Why wait 0.10.0? This should go into 0.9.x for bug fixing, no?

My understanding is that we are rolling 0.10.0 once Oliver is back so I tagged it for 0.10.0 - we can change it to 0.9.x but I do not think it will change anything

I just noticed I even get "read only" on stock items owned by my user directly. Something must be completely off here.

I just noticed I even get "read only" on stock items owned by my user directly. Something must be completely off here.

I guess that part was broken at some point... mind updating the title and comment of this issue to reflect your findings?

I just bisected on the stable branch and found 9841f47 to be the first bad commit.

Great pointer. Do you want to work on this or should I try to fix it?

As I haven't really looked into how the permission system works yet I think it's best if you do it.

Ok, I finally found the error and I am amazed we did not notice this earlier. All owner checks are returning false if you are not a superuser.

And it is kind of obvious once you discover it. We are comparing user objects with owner objects. That can only be false. Seems like most users (I too) deploy a lot of users as superusers.

return user in owner.get_related_owners(include_group=True)

@sur5r there is a fix in #4244 - it would be great if you could test that.
I think the current behaviour is kind of unintuitive - that should probably be addressed in #2323

It seems to work partially. Group membership for ownership works, but the permission bits are not respected at all. If I remove the ACD permissions for Stock Items and Stock Locations from the group, my user can still perform stock take actions. But maybe this is part of #2323. While it doesn't seem like a complete fix, it works for my use case.

@sur5r is your user a superuser or has ACD permissions for stock? Both should allow users to edit (at least that was the case in the original implementation).

My user is a regular user. The superuser could always perform any actions. Am I missing something regarding user permissions? I can only set permission bits for groups.

@sur5r you can also set permissions for users but that is a bit hidden. I will look into it again

Where is that? I didn't find anything in Django Admin.

@sur5r not in the admin interface, you can still set them on the objects themselves (via debugging, plugins, etc).

Ok, I'm pretty sure I didn't do that. But for completeness' sake: How can I inspect them? I tried this:

>>> um=InvenTree.models.User
>>> u=um.objects.get(username='jh')
>>> u.get_user_permissions()
set()
>>>