I should be able to make a Shared Invitation that only grants access to a specific Thing

(User Story, Investigate , Priority: High, Test Status: No automated tests yet , Reported By Justin du Coeur, )

Summary: The current Shared Invitation mechanism grants access to the entire Space. In some use cases (eg, LARP Casting Questionnaires) it would be better to limit that to a single Thing.

The trick here is that the initial Shared Invitation mechanism uses the coarse-grained security mechanism: it creates a Custom Role, and puts the desired permissions on that Role. That approach means that, by default, the invitees have those permissions throughout the Space.

Doing a Shared Invite to a specific Thing requires using fine-grained security instead: you shouldn't put any permissions on the Role, but instead should put the Role into those Permissions on the desired Model / Instance. The problem with this is that it potentially creates that Permission on the Thing -- and thus blocks inheritance, which may well be unexpected behavior. Remember that fine-grained security overrides coarse-grained, and folks will usually be using coarse-grained.

To fix this, I believe we have to enhance hasPermission() yet further. We would add a new permission tag named Inherit; if present, it means that these explicit permissions do not block inheritance. The implication is that hasPermission().checkPerms() needs to become Option[Boolean], returning Some(true) if permission is found, Some(false) usually if the permission is not found, and None if the permission is not found but Inherit is present, and then the callers need to flatMap over that result so that it keeps going up the permission-check chain.

The only reason I'm not immediately doing this is that it further complicates what is already probably the most-called function in all of Querki. We need to take an acid look at this with some profiling, and figure out if it is a hotspot, especially when a non-Owner looks at a Space -- my suspicion is that this is currently being extremely expensive.

After doing this, we also need to rewrite SecurityFunctionsImpl.makeShareableLink(). This needs a new parameter, an Option[TID] for the Thing that is being targeted. We need to request SpacePluginsMsg(GetinstancePermissionObject) on that Thing (or on the Space if not specified). On the resulting object (which will be the Instance itself iff the target is an Instance), we add the new Custom Role to all of the specified Permissions; if we are creating the Permission Property on that Thing, we also add Inherit. We do not put any permissions on the Custom Role itself.

I believe that, since all of this is setup at invite-creation time, it is entirely compatible with existing invitations using the old mechanism. That's why I'm not worrying about it right now -- we can leave the simpler implementation in place until we're ready to do this finer-grained one.

Also, this can be worked around for now, although it's a bit of hassle -- create a Shared Invitation whose permissions are Nothing, and then add it to the desired Thing Permissions by hand in the Security page. It won't have Inherit, but that can be adjusted by hand using the fine-grained security tags like Member.