You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now we use a custom API to create groups (we must POST to the /_groups path)
However WAC groups can be created like any other resources. The only requirement in the specs is:
The acl:agentGroup predicate denotes a group of agents being given the access permission. The object of an acl:agentGroup statement is an instance of vcard:Group, where the members of the group are specified with the vcard:hasMember predicate.
It is up to the group owner to ensure that it is protected correctly.
They will probably be put in a /vcard/group container... which is where contacts groups are also located. It doesn't seem to be a problem (contact groups will be considered as valid WAC groups), but maybe we should do something on the frontend to not show automatically-generated groups (there are many of them, possibly one for every AS collection).
The text was updated successfully, but these errors were encountered:
Right now we use a custom API to create groups (we must POST to the
/_groups
path)However WAC groups can be created like any other resources. The only requirement in the specs is:
It is up to the group owner to ensure that it is protected correctly.
WAC groups should be on the own named graphs, like any other LDP resource. It will be possible once we get rid of the Fuseki WAC extension.
They will probably be put in a
/vcard/group
container... which is where contacts groups are also located. It doesn't seem to be a problem (contact groups will be considered as valid WAC groups), but maybe we should do something on the frontend to not show automatically-generated groups (there are many of them, possibly one for every AS collection).The text was updated successfully, but these errors were encountered: