History: Permissões

Source of version: 3 (current)

! Configurações de Permissões
^ Páginas relacionadas: {TranslationOf(orig_page="Groups" translation_lang="pt" translation_page="Grupos") /}, {TranslationOf(orig_page="Groups Admin" translation_lang="pt" translation_page="") /}, {TranslationOf(orig_page="Category" translation_lang="pt" translation_page="Categoria") /}, {TranslationOf(orig_page="Category Admin" translation_lang="pt" translation_page="Admin de Categoria") /}, {TranslationOf(orig_page="Permissions List" translation_lang="pt" translation_page="Lista de Permissões") /} ^

{maketoc}

!! Compreendendo as Permissões no Tiki
Depois de configurar os ((Recursos)), a configuração das permissões é a parte mais importante da administração do Tiki. Esta página descreve os conceitos básicos do sistema de permissões do Tiki e como elas interagem.  Uma lista completa de permissões pode ser encontrada na página {TranslationOf(orig_page="Permissions List" translation_lang="pt" translation_page="Lista de Permissões") /}.

!!! Como as Permissões funcionam
^ -=Alguns fatos básicos que você precisa saber para compreender o sistema de permissões do Tiki.=-

*Administradores podem criar e editar {TranslationOf(orig_page="Groups" translation_lang="pt" translation_page="Grupos") /}.
**Cada grupo pode ter total acesso personalizado a todos os recursos do site.
**Usuários podem ser colocados em um ou vários grupos.
** Grupos podem ter sub-grupos.
** Permissões são dadas aos Grupos, NÃO usuários.
*Administradores podem criar e editar uma  {TranslationOf(orig_page="Category" translation_lang="pt" translation_page="Categoria") /}.
**Objetos (Após versão 1.9) podem ser adicionados às categorias.
** uma categoria pode, então, ser atribuída a um grupo.
** as permissões base de uma categoria, quando usada (avançado), dá aos membros do grupo as permissões atribuídas a eles.
*Objetos individuais podem ter permissões atribuídas a eles diretamente.
* Se nenhuma permissão for atribuída a um Grupo , a um objeto ou ao conteúdo de uma categoria, então as permissões globais são aplicadas.

Quando o Tiki é instalado, há pelo ao menos dois grupos pré-definidos:
*Anônimos (Anonymous): Usuários que não estão logado (fora) do sistema pertencem automaticamente ao grupo Anônimos.
*Registrados (Registered): Usuários que logados (dentro) do sistema automaticamente pertencem a este grupo.^


=====Tradução interrompida neste ponto ======

__What order are permissions settings applied?__

It is important to understand that Tiki uses several types of permissions:
*__Global__ permissions: Each site visitor belongs to a __Group__ (such as Anonymous or Registered). The permissions you assign to the group define the ''global'' permissions for that user.
*__Category__ permissions: These permissions define the actions that users can take for objects in a ''specific category''. 
*__Object__ permissions: These permissions define the actions that user can take for an ''individual object''.

Permissions are inherited from from the top-down, but override from the bottom-up.
{img src="http://twbasics.tikiforsmarties.com/img/wiki_up/tiki_permissions.png" width="450" desc="This image illustrates the relationship among Group, Category, and Object permissions." alt="The relationship of Group-Category-Object permissions"}

Tiki's permissions model may look like complex... but may also be ''very'' customizable.

{REMARKSBOX(type="note")}Starting with Release 4.x, Tiki has a dramatically different (and friendlier) method of assigning permissions than earlier versions.{REMARKSBOX}
{VERSIONS(nav=>y,title=>y,default=>Release 4.x)}
~tc~ Release 4.x ~/tc~

!!! Permissions Example
Consider the following example for a company using Tiki:
You have the groups:
* Anonymous
* Employees
* Board of Directors
{img src="http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_0_40.png" width="450" desc="The Groups for ABC Company" alt="Listing Groups page"}

Notice that some groups ''include'' other groups. For example, members of the __Board of Directors__ group will include, in addition to their own permissions, the permissions from the Employees, Registered, and Anonymous groups.

You have the categories:
* Financial Information
* Press Releases

You want to give:
* Everyone permission to read most pages
* Employees permission to edit most wiki pages
* Board Members only, access to the company's financial information.


!!! Global (Group) Permissions
First, you need to define the global permissions for each group.
{img src="http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_1_40.png" width="450" desc="Defining the Global permissions for each group." alt="Global Permissions"}

!!!! Anonymous
* To let the general public (that is, anonymous visitors) view wiki pages, assign __tiki_p_view__ to __Anonymous__.


!!!! Employees
* The Employee group includes the __Anonymous__ group (that is, everyone) and __Registered__ group (that is, users who are logged in). Therefore, the Employee group ''inherits'' the __tiki_p_view__ permission from these groups.
* To let employees edit pages, assign __tiki_p_edit__ to __Employees__.


!!!! Board of Directors
* The Board of Directors group includes the __Anonymous__, __Registered__, and __Employees__ groups. Therefore, the Board of Directors group ''inherits'' the __tiki_p_view__ and __tiki_p_edit__ permission from these groups.
+This group does not require any additional permissions.


!!! Category Permissions
Now that the Global permissions are set, you can adjust the permissions for each category. These settings will ''override'' the Global permissions.

^ __Note__:
Remember that Category permissions are an advanced feature only recommended for experienced users of Tiki, mastering already how Global and Object permissions work. ^

!!!! Press Releases
Currently, Anonymous can view press releases, and Employees can edit them (as defined by the Global permissions). To allow only the Board of Directors to edit press releases, you must assign permissions to the category. This will override the default group (global) permissions:
* For the Press Releases category, remove __tiki_p_edit__ from __Employee__. Now only the  __Board of Directors__ group can edit wiki pages in the category.
* Anonymous visitors (and all groups that ''inherit'' the Anonymous group's permissions) can still __view__ the pages.
{img src="http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_2_40.png" width="450" desc="Defining the Category permissions for the Press Releases category." alt="Category Permissions"}


!!!! Financial Information
Currently, Anonymous can view Financial Information, and Employees can edit them. But we want ''only'' the Board of Directors to have access (both view and edit) to these pages. You'll need to make the same adjustments to the Financial Information category's permissions:
* Remove __tiki_p_edit__ from __Employee__. Now only the  __Board of Directors__ group can edit wiki pages in the category.
* Remove __tiki_p_view__ from __Employee__, __Registered__, and __Anonymous__. Now only the Board of Directors can see the pages.


!!! Object Permissions
But what if you want one item in the Financial Information category, to be visible to the public? You can override all other permissions, by assigning specific permissions to the ''object'' itself. For example, the ABC Company may have a public disclosure form, issued by the government, that it needs to make public (but that only the government can change or update):
* For the individual item, remove __tiki_p_edit__ from the __Employee__ and __Board of Directors__ group. Since this form is issued by the government, no one should be able to change it.
*Anonymous visitors (and all groups that ''inherit'' the Anonymous group's permissions) can still __view__ the pages.
{img src="http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_3_40.png" width="450" desc="Assigning object-specific permissions to the PublicDisclosure page." alt="Object Permissions"}

Object Permissions can be tricky.

For example using version 10, if you wanted to hide one wiki page made by admin from the Anonymous group you would select the page's permissions (from the admin menu : Wiki/List Pages/then click the Key icon for your page in the list).

Using the object permission page of the wiki page, you turn off the ''"Can view page/pages (tiki_p_view)"'' attribute and save.
However, after loging off, and connecting as Anonymous you can still see the page.

It turns out that you have to turn off the ''"Can view page/pages (tiki_p_view)"'' __AND__ ''"Can admin the wiki (tiki_p_admin_wiki)"'' attributes to hide the wiki page from the Anonymous group.
---(Release 3.x, 2.x)---
!!! Permissions Example
Consider the following example for a company using Tiki:
You have the groups:
* Anonymous
* Employees
* Board of Directors
{img src=http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_0_33.png alt="Listing Groups page" desc="The Groups for ABC Company."}

Notice that some groups ''include'' other groups. For example, members of the __Board of Directors__ group will include, in addition to their own permissions, the permissions from the Employees, Registered, and Anonymous groups.

You have the categories:
* Financial Information
* Press Releases

You want to give:
* Everyone permission to read most pages
* Employees permission to edit most wiki pages
* Board Members only, access to the company's financial information.


!!! Group Permissions

!!!! Anonymous
* To let the general public (that is, anonymous visitors) the ability to view wiki pages, assign __tiki_p_view__ to __Anonymous__.
{img src=http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_1_33.png alt="Group Information" desc="The Group Information page for the Anonymous group."}


!!!! Employees
* The Employee group includes the __Anonymous__ group (that is, everyone) and __Registered__ group (that is, users who are logged in). Therefore, the Employee group ''inherits'' the __tiki_p_view__ permission from these groups.
* To let employees edit pages, assign __tiki_p_edit__ to __Employees__.
{img src=http://twbasics.tikiforsmarties.com/img/wiki_up/permissions_example_2_33.png alt="Group Information" desc="The Group Information page for the Employees group."}

!!!! Board of Directors
* The Board of Directors group includes the __Anonymous__, __Registered__, and __Employees__ groups. Therefore, the Board of Directors group ''inherits'' the __tiki_p_view__ and __tiki_p_edit__ permission from these groups.
+This group does not require any additional permissions.


!!! Category Permissions

!!!! Press Releases
Currently, Anonymous can view press releases, and Employees can edit them. To allow only the Board of Directors to edit press releases, you must assign permissions tothe category. This will override the default group (global) permissions:
* For the Press Releases category, assign __tiki_p_edit_categorized__ to __Board of Directors__
But this will override ''all'' global permissions -- no one will be able to ''view'' the press releases. To let the general public read the press releases, assign __tiki_p_view_categorized__ to __Anonymous__.


!!!! Financial Information
Currently, Anonymous can view financial information, and Employees can edit them. To allow only the Board of Directors to edit ''and'' view these pages, you must assign permissions to the category. This will override the default group (global) permissions:
* For the Financial Information category, assign __tiki_p_view_categorized__ and tiki_p_edit_categorized__  to __Board of Directors__

But what if you want one item in the Financial Information category, for example, a public disclosure form, to be visible to the public? You can override all other permissions, by assigning specific permissions to the ''object'' itself.
* For the individual item (such as a wiki page), assign __tiki_p_view__ to the __Anonymous__ group and __tiki_p_edit__ to the __Board of Directors__ group.

{VERSIONS}

!! Managing permissions
{BOX(title="Warning" bg="lightyellow" width="30%" float="right")}While entering a filter, JQuery will rebuild the list. Do not press enter or you'll start all over.{BOX}Starting in {TranslationOf(orig_page="Tiki4" translation_lang="pt" translation_page="") /}, a new interface has been designed to manage object and category permissions. 

In this new interface there are three tabs. The first one to allow assigning permissions.

{img src="tiki-download_file.php?fileId=178" alt="" link="tiki-download_file.php?fileId=178&display" rel="shadowbox[g];type=img" align=center}

the second tab is to select which groups should be included in the table for assigning permissions, since when the list of groups is too big, assigning permissions could be too slow.

{img src="tiki-download_file.php?fileId=179" alt="" link="tiki-download_file.php?fileId=179&display" rel="shadowbox[g];type=img" align=center} 

The third tab is also to filter the number of features that should be shown in the interface. This is specially needed when managing category permissions, to avoid having a list far bigger than needed for our purposes in specific cases.
 
{img src="tiki-download_file.php?fileId=180" alt="" link="tiki-download_file.php?fileId=180&display" rel="shadowbox[g];type=img" align=center} 

In addition, this new interface to manage permissions includes several features:

{SPLIT()}{img src="tiki-download_file.php?fileId=177" alt="" link="tiki-download_file.php?fileId=177&display" rel="shadowbox[g];type=img" align=center} 
---
# You can assign or remove all object permissions on all child categories if this box is checked.
# You can filter the whole list of permissions dynamically to list only those containing some text
# You can expand or collapse at will any of the sections of permissions
# You can select one by one the permissions to be assigned or checking the box at the column title (group name) level, and that selection will propagate to all the checkbox shown in that column. 
{SPLIT}

!! Permissions by section
{TRACKERLIST(trackerId=>7,fields=>62:70:71:103,showtitle=>n,showlinks=>y,showdesc=>n,showinitials=>n,showstatus=>n,status=>opc,filterfield=>93,exactvalue=>Section, max=-1)}{TRACKERLIST}

!! Demo site for testing
* {TranslationOf(orig_page="info:demo" translation_lang="pt" translation_page="") /}

!! Category permissions
There is also a new feature in Tiki 1.9.x to restrict permissions via the category feature. Basically, you can already assign all the permissions you need as described above. However, permissions via the category feature is just to make it faster to assign permissions. This feature is little tricky to understand. We are working to improve it. There are only two levels ("view" & "admin") in Tiki 1.9.4, and the third level ("edit" category contents) has been introduced in starting from 1.10.

Starting in 3.0, category permissions are in addition to Groups permissions.  So if tiki_p_read_categorized allows reading items which are in a category, the user must also be in a group which allows reading the specific kind of object.  The category can not grant access to an object which the user's groups do not give him access to.

In {TranslationOf(orig_page="Tiki4" translation_lang="pt" translation_page="") /}, the full granularity of permissions can be assigned to categories (and thus inherited when objects belong to a given category). The permissions granted to objects are the sum of all the permissions granted to categories in which they belong.

Because adding a category to an object can provide additional rights, it is important to protect who can assign categories to prevent undesired escalation. For example, if the site contains public and private information, someone with access to edit private information should not be able to make it available publicly by changing the categories. To resolve this issue, multiple permissions can be assigned to the categories.

To begin with, tiki_p_modify_object_categories allows to determine if the user is allowed to modify the categories of the object at all. Without this permission, it will be impossible to modify the categories. Typically, it is safe to grant this permission widely.

Then, there is higher granularity available for each category. tiki_p_add_object and tiki_p_remove_object determine if the user can add or remove elements from the category. Categories on which permissions are specified should also specify who can assign or remove  those categories. When the operation is not available, the checkbox will be marked as disabled.

Additionally, some category changes may be allowed in certain contexts by defining {TranslationOf(orig_page="Category Transitions" translation_lang="pt" translation_page="") /}, which would allow to change a category only from a certain state. A group of transitions create a workflow. Note that until {TranslationOf(orig_page="Tiki6" translation_lang="pt" translation_page="") /}, category transitions are only available through {TranslationOf(orig_page="Profiles" translation_lang="pt" translation_page="") /}.

!! Workspaces
Workspaces are coming to {TranslationOf(orig_page="Tiki4" translation_lang="pt" translation_page="") /} to further facilitate management of large & complex Tiki sites.

!! Admin permissions and special permissions
When a group has an admin permission on a feature such as tiki_p_admin_sheet, the group will lost his admin permission for an object with local perms or categories permissions.

! Note
Some information on this page is from __[http://twbasics.tikiforsmarties.com/How+Permissions+Work|Tiki for --Dummies-- Smarties]__, copyright (C) by Rick Sapir, published by KeyContent.org, and available under a Creative Commons Attribution-Share Alike License.