Closed aaj3f closed 7 months ago
I have a PR for the expansion portion here: https://github.com/fluree/db/pull/693
As for the second f:$identity
enforcement issue, I do not have a fix yet but have discovered a few things:
dbproto/-p-prop
lookup for the schema:age
iri here: https://github.com/fluree/db/blob/main/src/fluree/db/query/json_ld/response.cljc#L87. For some reason, that predicate is not present in the predicate cache at all, so it does not come back in the query results.@mpoffald -- I mentioned this to you directly but just to track here, at least in server
's implementation of your db
PR (fluree/db#693), I'm still unfortunately not seeing opts: { role }
working with compact, expanded, or "naive" IRIs (by "naive" I mean IRIs named like "@id": "rootRole"
).
Because I didn't mention this as a test case in the ticket above (I only realized it was being used by Nexus after your PR landed), I did just want to explicitly call out that we do want to make sure that if a user names a role (e.g. via f:targetRole: X
) with a naive IRI like rootRole
(instead of http://example.org/rootRole
) that opts: { role }
will still work with those naive IRIs
@mpoffald -- I mentioned this to you directly but just to track here, at least in server's implementation of your db PR (https://github.com/fluree/db/pull/693), I'm still unfortunately not seeing opts: { role } working with compact, expanded, or "naive" IRIs (by "naive" I mean IRIs named like "@id": "rootRole").
Because I didn't mention this as a test case in the ticket above (I only realized it was being used by Nexus after your PR landed), I did just want to explicitly call out that we do want to make sure that if a user names a role (e.g. via f:targetRole: X) with a naive IRI like rootRole (instead of http://example.org/rootRole) that opts: { role } will still work with those naive IRIs
After investigation w/ @mpoffald, we discovered that, in fact, her work to enable opts: { role }
with compact (and even "naive") IRIs is working fine. The real issue there is now captured by fluree/core#65
@mpoffald -- the buggy behavior with f:$identity
also seems to have been solved, by your PR on this issue or possibly by @dpetran's work to fix issues re: @type
with policy enforcement
I was going to make a separate issue for that, but no longer any need to do so
Closed by fluree/db#693
Description
There are two bugs that appear to exist currently when using
opts: { role, did }
to issue a query/txn as a particularrole
and/ordid
role
seems to only expand the IRI of a providedrole
viadefaultContext
Since we aren't using
defaultContext
any longer, if I provide the following query, this is a problem, as I would wantex:yetiRole
to expand tohttp://example.org/yetiRole
and yet it is not being expandedHowever, if I simply provide the expanded IRI, then it works fine
did
provided byopts: { did }
correctly, however policies that leveragef:equals
+f:$identity
are not currently working as expectedFor example, I have the following (1) Policy data, (2) User data, (3) Query as that user (and results)
Add policy data
Add user with ex:yetiRole
Query as user's did
This SHOULD return, for
freddy
himself, hisschema:age
, given thef:equals
+f:$identity
onschema:age
, but it doesn't (although it did used to do that)Query results