As a QL author, I can declare that I want to use Things that the reader might not otherwise see
Summary: This story compensates for the consequences of
Read Access is much too leaky. The first cut of that will make it impossible to summarize data that the reader can't see; this is a way to allow that.
Depends Upon:
The right way to do this probably isn't as a function, but a property of a page/Thing.
Add a new security menu, probably as a lock icon; move Sharing and Security into that. Add a new menu pick called "Grant Access" (which is what I normally think of as "bless"). This shows a dialog, saying "Allow everyone who can read this page to read it the same as you do, even if they can not normally see the Things it refers to?". Or words to that effect: the notion is that I am extending the permission so that anyone who can read this Thing can also read all of its contents to the same degree I can.
This calls an API, which sets a Property called BlessedBy, which contains a link to the Identity that blessed it. There can only be one blessing on any given Thing. (I don't know what it would mean to have more, and it would certainly be confusing.) There should also be an API to revoke this blessing; if BlessedBy is set on this page, the menu pick gets replaced with Revoke Access.
In getThingPage, it checks for the presence of this property. If found, and the blessing is not from the current user, it forwards the request to the UserSpaceSession of the blessing user. This way, we leverage UserSpaceSession instead of fighting it.
As a future enhancement, the code for Who Can Edit might also check this flag, so you can extend limited write access, but that's likely to be tricky to implement. For now, read access is much higher priority.
OLD (superceded, 1/20/15): This will probably take the form of a new QL function, _withMyReadAccess or something like that. It basically says that, for the rest of this QL pipeline, the author's view of the world will govern what is readable, instead of the reader's view. This doesn't seem too inconvenient, and makes it harder to expose data accidentally.
Implementing this will require a clear concept of "author", and it is possible that this should be implemented as a Property on the Thing instead. Think carefully about how authorship is handled when the Thing gets edited -- the advantage of doing it as a Property would be that we could set "author" each time that Property changes.
