Alphacast Permissions

The present document describes the way that users can interact with content within Alphacast, based on their permissions levels.

Entities within Alphacast

• User: an individual user logged in to the Alphacast platform that can access and create content.
• Team: a group of users within Alphacast. Content can also be published under a team name instead of individual users.
• Account: A user or a team, can be referenced as accounts. Every account has an id and an account type (User / Team).
• Dataset: A group of data, usually including multiple variables, with time-series data.
• Chart: A visual representation of data that can include variables from on or multiple datasets.
• Insights: A text description of a scenario, that can include references to data, charts or links on the web.
• Repository: A repository is the unit level under which content permission is established. A repository can include Datasets, Charts, Insights, and eventually other entities, and its permission is affected based of the repository permission configurations.

Personas

To describe the different interactions with each entity, we will be the following Personas:

• Alex: He is a social media star, creating content to boost his social capital. All his content is free and open for everyone to access.
• Matias: Matias also publishes some online content in social media, but he is mostly focused on the enterprise business, working with different customers in a consulting firm. Matias may eventually collaborate in some of the work Alex makes.
• Jorge: He leads a research team within a bank. As a team, they require data from multiple datasets and repositories, and they might create their own content, both to use internally within the company, as well as sharing publicly with their customers.

Content characteristics:

Each piece of content can be described based on the following characteristics:

• Discoverability: If the content can be searched and found by someone navigating the Alphacast platform. In general, content can be described as Listed or Unlisted, and this property is applied to repositories, and inherited by the content within (this is a proposed change to the current Insight implementation, where each insight can be marked as listed or unlisted)
• Privacy: Repositories can also be indicated as Public, or Private.
  • When the content is Public, anyone can access, download, or create new content based on the public content, without requesting any time of permission from the content owner.
  • When the content is Private, the owner needs to allow access to individual accounts to access the content. Public content created based on Private content will not change the private content characteristics, and users seeing the newly created public content may be required to ask for permission from the original private content creator. Permission to private content may also be granted by the means of paid subscriptions.
• Production stage: Content can also be considered Draft, or Published. When the content is Draft, it will only be visibly by whoever has edit access over the content. Insights, Datasets, Charts can be marked as Draft or Published, and such indication has no impact over its privacy or discoverability, as they are different characteristics.
• Ownership roles: An account can be considered the Owner of a repository, its Admin, a Publisher, an Editor, or a Viewer of the content. Public content grants Viewer access to anyone by default.

Scenario:

Based on the personas, entities, and content characteristics described above, we can cover the following scenario:

• Social Sharing: Alex creates a public repository, uploads datasets, creates charts, and writes insights on it. Everyone can see the content, which is marked as listed, so more users can reach it. Alex may leave some insights or charts momentaneously as drafts until he considers them perfect to be shared with the world.
• Social Collaboration: Alex may require some help form Matias to review some datasets he wants to share on twitter. Datasets will still belong to Alex public repo, but Alex may give Editor role to Matias to work on data. Alex will still have the final word on what to publish, since Matias is not given an Editor role.
• Brand positioning: Matias works in the Fabrikaam consulting firm, and as such, he publishes all sort of content under the Fabrikaam team. The content is Public and accessed by everyone, just like Alex shares the work he does on his own account. Brand positioning may be a paid feature of the Alphacast platform.
• Customers relation: Matias and the Fabrikaam team publishes some exclusive content, that are only visible by their enterprise customers. Repositories and then marked as Private, and Matias can choose whose customer account (user or team) may have access over each repository. Customer relation may be a paid feature of the Alphacast platform.
• Team internal collaboration: Jorge works with multiple datasets, they handle internally within the bank team. Everyone in the team can have View Access over every team repository. If Jorge for any reason needs to keep some content away from his team eyes, he might choose to create a private repository on his own account. Jorge can then set higher ownership roles over individual repositories to individual team members, indicating other admins, or editors.

Other Ideas:

• Users within a Team could potentially have a designated role that might apply to any repository within the team. For example, the team owner could delete any repository created by any team member, specially considering cases where employees leave an organization.

Implementation Details

A Repository has the following properties:

• Privacy: Public / Private
• Discoverability: Listed / Unlisted.

Content within the repository (Insights, Datasets, Charts) can be marked as Draft, or Published.

Repositories belong to an Account, either a User or a Team. Their URL is formed by /accountSlug/repoSlug

If a repository belongs to a Team, it still has a User as an Owner, which is part of that team. If the user leaves the team at any point, content needs to be realocated to another team member, or deleted.

The Owner of a repository, can set other ownership roles to other accounts: Viewer, Editor.... These accounts can be part of the team, or could eventually be part of other teams or individual users (see Customer relation scenario). Roles are defined in the Repository_Permissions table, and they are established over accountIds, so they may affect both users and teams.