Access Control

_isDefined not respecting Who Can Read?: I created a Thing (with model Root Model, a bare-bones model), then went to the Thing's Sharing page and set every single permission to "Owner", including "Who Can Read". On another account, when I use the Name of that Thing in QL, I get the expected "there is no thing with that name" error... but if I test _isDefined on that same name, it yields True.

As an Owner, I can *easily* manage the broad permissions of my Space: At the moment, the system permits very fine-grained security. This is lovely in practice, but overkill in 90+% of cases, and harder to use than most users want. We need to boil it down to a few common patterns, and present the user with a simple radio-button choice that they pick at Space creation time, and can update later.

As an Owner, I can accept or reject requests to Join my Space: That is, when someone asks to Join my Space, I receive a notification to that effect. From there, I can choose to accept the request, or ignore it. If I accept, it should send an email to the requester, and at that point they follow the usual invitation pathway.

When I accept a request, I choose which Role this Member will have.

As an Owner, I can describe my Space: This Description should probably be a Summary / Details pair, and should be specified when creating the Space, and modified under Sharing and Security. It is used in public listings of the Space, and on the Ask to Join page.

As an Owner, I can specify whether people can ask to Join this Space: This is a new permission on the Space.

I can ask to Join a Space: If I am not a Member of a Space that I am looking at, I should be able to ask to join it.

I can't allow only some Members access to the Space Thing: This is a side-effect of the fact that we only check Roles if the permission is not set on this specific Thing. So if I restrict Space to Owner-only, Collaborators still can't see it, because the Space Thing says not to.

Read Access is much too leaky: At the moment, given a Thing that you don't have Read access to, you can still see it in listings and such. This implicitly makes security far too haphazard -- I just plain don't trust the read security yet.

Turning off Who Can Read on a Type Model is likely to cause errors: That is, if User U can't see a Model (due to Who Can Read), which is used by a Type used by a Property used by a Thing that U can see, they're going to get errors.

Who Can Read: Public isn't working right?: Noticed by Chad: this page -- the Public Blurb for A Respectful Calm -- isn't actually Anonymous-readable. That probably means something is badly broken in security, and needs to be fixed ASAP.

As a QL author, I can declare that I want to use Things that the reader might not otherwise see: 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.

As an Owner, I can *easily* control the Conversation permissions: Closely related to the depended-upon Story, but specific to Conversation permissions. There should be a single, easy, clear button for defining the usual access-control patterns.

As an Owner, I can define Space-specific Roles: A Role is essentially a set of Permissions. The built-in ones should be good enough for most purposes, but I should be able to tune my own versions, with greater or lesser rights.

As the Owner of a Space, I can assign other Moderators of Conversations: Requires that we have the concept of security groups first.

As the Owner, I should be able to turn off certain permissions for myself: The canonical example here is Can Comment, which controls a bunch of UI. It should be possible for me to turn off comments in the Space completely, including for myself, so that I don't waste pixels on it.

I can control who can see all of the User Values: I should be able to control whether, eg, Members have access to the _userValues function and suchlike.

I should be able to override security for a specific display: That is, I should be able to build a page that includes data that the viewer would not normally be allowed to see.

I should be able to see what a Thing looks like to a lower-security user: This will be necessary to make it easy enough to use access control effectively: I should be able to downgrade my view to "Member" or "Public", or a member of any specific Group.

As an Owner, I can say what the default Role for Members of my Space should be: That is, I can say that most of my Members should be Commentators, or Editors, or even Managers.

As a Manager, I should be able to do most Owner tasks: This has been defined more or less forever, but becomes critical for the Arisia project.

There are standard Roles that I can use in my Space: For now, this is "Commentator", "Contributor", "Editor" and "Manager".

When I invite someone to join my Space, I can assign them a Role: That is, I should make the initial decision about which Role this person has when I am dealing with their membership.

I should be able to change the Role of someone who has been invited, but not yet accepted: This is simply a gap in the design -- we don't provide a UI to edit someone who is in this in-between state.

I should be able to assign multiple Custom Roles to a person: I think this is just a UI enhancement? Custom Roles should probably be displayed as checkboxes.

As an Owner, I can assign Users to the standard Roles: This should initially happen in Sharing and Security: for each Member, I can easily set which Role they have.