new Permissions()
- Source:
- Tutorials:
-
- Tutorial: tests/permission/PermissionTest.js
Properties:
| Name | Type | Description |
|---|---|---|
admins |
Permission | Users who can perform admin operations on the corpus/datalist/datum/datumField. |
exporters |
Permission | Users who can export the items in a corpus/datalist/datum/datumField. |
writers |
Permission | Users who can modify the items in a corpus/datalist/datum/datumField. |
commenters |
Permission | Users who can comment on the items in a corpus/datalist/datum/datumField. |
readers |
Permission | Users who can read the items in a corpus/datalist/datum/datumField. |
viewAsBasePermissionSystem |
Object | This is just syntactic sugar which points to the actual permission system. The actual permission system should be used by apps who want provide a power user or fine grained and open ended control over the permissions, or whose users want to understand the fine graned control at a lower level. - Kind of like Unix permissions. |
viewAsDataBasePermissionSystem |
Object | This is syntactic sugar which makes the permission system look like there is an implicative relationship betwween roles. - Kind of like PhP/MySQL systems. |
viewAsGroupedPermissionSystem |
Object | This is syntactic sugar which shows users in only one category (readOnly, writeOnly, read/write, admins) it also makes the permission system look like there is an implicative relationship betwween roles, but with some hint that there are some rare roles (such as write only) for crowdsourcing/non-standard data entry contexts. - Kind of like PhP/MySQL systems. |
viewAsEmailingTeamPermissionSystem |
Object | This might be the way that some computational linguistics teams will understand the permission system best, but the words `collaborator` and `contributor` are so similar that thus far no one has used these terms (that we know of). - Kind of like GitHub. |
A collection of open ended permissions which can be applied to any object
(usually a corpus, but could be a datalist, or datum, or datumField). A permission
can be thought of roughly as a phrase:
User [{username: "lingllama", gravatar: "123"}]
has permission ["admin","write","read","comment","export","import",etc]
to "corpus"/"datalist"/"datum"/"datumField"
Extends
Members
adminOnlys :Permission
- Source:
Syntactic sugar for apps who want to show users in one category, not in each low level permissions.
This permission is side effect of when a user has only admin permission.
In this case the user can only access to only admin functionalities such
as adding new users to the database. This role is used by project managers or IT staff
who dont know anything about the data itself, and are only setting up the corpus for
the team to use if the PI or corpus owner doesnt know how to do the permissions.
set-up themselves.
Type:
collaborators :Permission
- Source:
Syntactic sugar for users who have reader+commenter permissions.
This is a common permission used by research teams where an external reviewer,
or a second language consultant can review and coment on the data,
but cannot modify the data itself.
Email collaboration analog: This is for users who would be in a BCC category
for emails (they can read the paper, but they arent supposed to send back a
version which they modified for the team to accept),
Dropbox analog: This is for uswers who would be given a URL to a folder in Dropbox
(but cannot download the files and modify them with the others)
Type:
commentOnlys :Permission
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This permission is side effect of when a user has only comment permission.
This is a rare case which might be used in a web widget external to the data entry apps
where users or anonymous visitors can leave a comment on data if it is presented to them,
but cannot browse the database.
Type:
contributors :Permission
- Source:
Syntactic sugar for users who have reader+commenter+writer permissions.
This is a common permission in version control systems
where the user can do everything, including categorize data, assign data cleaning
to team members, edit information about the database but cannot perform
except admin functions such as adding other users to the database.
This should be the default permission for most users on the corpus, as the corpus
is version controlled any action can be undone if users use their power too much,
they can be downgraded to a collaborator or read only role.
Email collaboration analog: This is for users who would be in a
To or CC category for emails,
Dropbox analog: This is for users who would be invited to join a shared
folder on Dropbox.
Type:
currentPermissions
- Source:
A list of "hats" which team members can wear in this team.
owners :Permission
- Source:
Syntactic sugar for users who have reader+writer+admin permissions.
This is a common permission used by most data base management systems meaning the user can do anything.
Email collaboration analog: The person who initiates the email thread
Dropbox analog: The person who creates the folder in dropbox and adds others to it.
Type:
populate
- Source:
Accepts an object containing permission groups which are an array of
users masks which have this permission. This simple object is used to populate the permissions model.
readAllWriteOwnDataOnlys
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This is a rare permission provided for team members who have been editing other people's
data either to update it to their own dialect (when it was supposed to be the dialect
of the original source) or other sorts of 'destructive' edits which the team wants to
prevent the user from doing this without making the user uncomfortable. A user with this permission
will know that they have been limited to editing their own data only (similar to Facebook) and cannot
edit other people's data.
This permission should not be a default permission among research teams, instead the readerCommenterWriter
permission should be used to reduce territoriality in the data and makes it harder for the database to be kept clean
because users cannot update/comment on data when they notice a problem. All data is versioned so any
mistakes can be undone.
readCommentAllWriteOwnDataOnlys
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This is a rare permission provided for team members who have been editing other people's
data either to update it to their own dialect (when it was supposed to be the dialect
of the original source) or other sorts of 'destructive' edits. A user with this permission
will know that they have been limited to commenting on others' data, and editing their own
data only (similar to Facebook).
This permission should not be a default permission among research teams, instead the readerCommenterWriter
permission should be used to reduce territoriality in the data and makes it harder for the database to be kept clean
because users cannot update/comment on data when they notice a problem. All data is versioned so any
mistakes can be undone.
readerCommenterOnlys :Permission
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This permission is side effect of when a user has only read and comment permission.
This is a common permission used by research teams where an external reviewer,
or a second language consultant can review and coment on the data,
but cannot modify the data itself.
Type:
readerCommenterWriterAdmins
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
Often refered to as "admins" in traditional databases permissio ns
It means the user can write data, read data and comment on data, and perform any operation on the data.
readerCommenterWriters
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This permission is side effect of when a user has only read comment and write permission.
This is syntactic sugar which is often refered to as "writers" in traditional databases permissions.
It means the user can write data, read data and comment on data
readerWriters :Permission
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This permission is side effect of when a user has only read and write permission.
This is a rare permission where the user has been leaving abusive comments,
and are thus only permitted to browse and edit the data itself, not add or edit comments.
If you want to give someone access as a reader+writer, use readerWritersComenters.
Type:
readOnlys :Permission
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This permission is side effect of when a user has only read permission.
In this case the user might be part of a grant commitees or the general public (for
the aspects of the corpus which have been made @publicic),
language consultants who might leave mean comments on other consultant's data,
or other sorts of external viewers of the data who the team doesnt want to leave
comments.
Type:
readOwnDataWriteOwnDataOnlys
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This is a permission provided for teams who want many language consultants to contribute to one
database without seeing the data other consultants have added. We expect this may be a common
permission especially for teams where there is no `standard` dialect and speakers of other dialects
are very prescriptive and think others are making `errors` which need to be corrected, this permission prevents them from `correcting` others data.
removeUser
- Source:
Removes user from roles on this permissions team, or removes user entirely if only a username is supplied.
viewAsBasePermissionSystem
- Source:
This might be used by teams who want to have fine grained control over the
permissions, or who want to understand the fine grained control at a lower level.
viewAsDataBasePermissionSystem
- Source:
This is the way most field linguistics apps present the permissions system.
viewAsEmailingTeamPermissionSystem
- Source:
This might be the way that some computational linguistics teams will
understand the permission system best, but the words
`collaborator` and `contributor` are so similar that thus far no one
has used these terms.
viewAsGroupedPermissionSystem
- Source:
This view will be missing some members of the corpora since not all combinations of
permission have syntactic sugar methods in this library. This shoudlnt be used
unless the app dev is sure that the users wont be using corpora for psycholinguistics or
crowdsourcing or computational linguistics.
writeOnlys :Permission
- Source:
Syntactic sugar for apps who want to show users in one category, not grouped by low level permissions.
This permission is side effect of when a user has only write permission.
In this case the user can add new data to the database, but cannot
review or read or see existing data. They can edit data if it is specifically
presented to them, they cannot query the database. As all data is version
controlled edits can be undone so this user is not able to destroy a database that they cant read.
This is not a common permission to use in the system.
This permission can be used for psycholinguistics or crowdsourcing experiemnts
where users are anonymous (identified anoymously by session or by device)
and visit a given website or Android app and can respond to stimuli and their responses
become new data points in the system. These users cannot access fieldlinguistics apps
which permit browsing of the data, but is a rare permission used by web widgets or other smaller apps which write to a corpus.