Not all subjects with permissions are shown

[elsdvlee]

Not all subjects with permissions are shown in the list to edit the permissions.
E.g. login with oidc provider https://onto-deside.ilabt.imec.be/css11/, webid https://onto-deside.ilabt.imec.be/css11/construction_user2/profile/card#me, email construction_user2@example.com and password construction_user2.
The list shows only public access, while the logged in user (construction_user2) has rwc right, and following users have read rights: https://onto-deside.ilabt.imec.be/css11/construction_user3/profile/card#me, https://onto-deside.ilabt.imec.be/css11/construction_user4/profile/card#me, https://onto-deside.ilabt.imec.be/css11/construction_user5/profile/card#me.

[NuttyShrimp]

It seems like the that the inrupt SDK is unable to properly use the parsed quads from the ACL files for the resources in the ceon folder. I think it is most likely the identifier (I don't know the correct term for it) that creates the problem. E.g. here the "_:0":

_:0 a <http://www.w3.org/ns/auth/acl#Authorization>;
  <http://www.w3.org/ns/auth/acl#accessTo> <https://onto-deside.ilabt.imec.be/css11/construction_user2/ceon/data>;
  <http://www.w3.org/ns/auth/acl#agent> <https://onto-deside.ilabt.imec.be/css11/construction_user2/profile/card#me>;
  <http://www.w3.org/ns/auth/acl#mode> <http://www.w3.org/ns/auth/acl#Control>, <http://www.w3.org/ns/auth/acl#Read>,
    <http://www.w3.org/ns/auth/acl#Write> .

I tried to pinpoint where it happens in the inrupt SDK, but to no avail.
Keep in mind that it has the following warning in the docs of the SDK:
"If access to the given Resource has been set using anything other than the functions in this module, it is possible that it has been set in a way that prevents this function from reliably reading access"

[elsdvlee]

Indeed, https://waceditor.patrickhochstenbach.net/ can also not read this acl correctly. I will look into this.

[elsdvlee]

Strangely, Comunica and pod browers can still grant access to the correct users for https://onto-deside.ilabt.imec.be/css11/construction_user2/ceon/data

[elsdvlee]

Using a named node instead of a blank node as subject in the acl resolves this issue....

[Dexagod]

Offending lines are

https://github.com/inrupt/solid-client-js/blob/main/src/acl/acl.internal.ts#L188-L192

That looks for things in the ACL resource dataset and

https://github.com/inrupt/solid-client-js/blob/main/src/thing/thing.ts#L118-L141

that has an explicit flag on if they need to take blank nodes into account as things.

If this is not by design that flag needs to be set to true, but not sure on if this is by design or not :)

[elsdvlee]

We put this issue on hold. We know now the root cause and know how to work around (no blank nodes as subject of acl rules). Let's prioritize the other issues.