source: main/waeup.kofa/branches/uli-upgrade-beaker/docs/source/userdocs/users.rst @ 17260

Last change on this file since 17260 was 13108, checked in by Henrik Bettermann, 9 years ago

Rename button.

Reorganize applicants section docs.

File size: 3.7 KB
Line 
1.. _users:
2
3Users
4*****
5
6Kofa distinguishes between four types of users: anonymous users,
7applicants, students, portal officers/managers and the Zope manager.
8Kofa distinguishes further between authenticated and unauthenticated
9users and between users with and without account object.
10
11The user authentication process in Kofa is quite complex. Briefly
12and in simple terms, a so-called authenticator (plugin) validates
13the credentials provided via the login form, fetches the matching
14account object, extracts the account data and finally leads to the
15creation of a temporary user object, a so-called principal. Kofa
16principals provide `name`, `title`, `email`, `phone`, `public_name`
17and `user_type` attributes.
18
19
20Anonymous
21=========
22
23Anonymous users do not authenticate and thus do not provide
24credentials. Their user id in logfiles is always ``zope.anybody``.
25These users gain two permissions: :py:class:`Anonymous
26<waeup.kofa.permissions.Anonymous>` and :py:class:`Public
27<waeup.kofa.permissions.Public>`.
28
29Only a few actions of anonymous users are logged. These are payment
30data webservice requests, the execution of password mandates and the
31self-registration of applicants.
32
33.. _applicants_and_students:
34
35Applicants and Students
36=======================
37
38Logged-in applicants or students are regular authenticated Kofa
39users. Their user account object is an adaption of their
40applicant/student object. More precisely, the Applicant/Student
41authenticator fetches the matching applicant/student object and
42turns it on-the-fly into a Kofa account object which is further used
43for creating a principal instance. The `applicant_id`/`student_id`
44attribute becomes the user name and the `display_fullname` property
45serves as user title.
46
47.. _officers:
48
49Officers
50========
51
52.. seealso::
53
54   :ref:`Officers Doctests <userscontainer_txt>`
55
56   :ref:`Officers Python Test <test_suspended_officer>`
57
58Officers are users with a dedicated user account object stored in the
59``users`` container (of type :py:class:`UsersContainer
60<waeup.kofa.userscontainer.UsersContainer>`) which is located in Kofa's root
61container. The account object has three more attributes than the principal
62instance which is created from the account data: (1) a `suspended` attribute
63which allows to deactivate an account, (2) a `roles` attribute which is a list
64of global role names assigned to the officer, and (3) a private `_local_roles`
65attribute which maps local role names to lists of objects the respective local
66role applies to. This information is important because local role assignment
67is originally stored only with the objects the role applies to and not with
68the user who got the role. When removing an officer, Kofa iterates over the
69mapping and the list of objects in order to remove all these local role
70assignments denoted in the mapping.
71
72The management of portal officers is done in the 'Officers' section
73of Kofa. The management page shows all officers registered in the
74portal together with their global and local roles. The table can be
75easily sorted or filtered. Deactivated officer accounst are marked
76``(suspended)``.
77
78
79Manager
80=======
81
82There is one and only one manager account (user id ``zope.manager``)
83in Kofa. The manager has access to the root instance of the Kofa
84application which has its own user interface (see screenshot below).
85Through this 'Grok UI' the manager can access some basic functions
86to manage the database and also access the Kofa user interface.
87
88.. image:: images/Grok_UI.png
89
90Although the manager automatically gains all permissions the system
91defines, this real superuser (or emergency user) neither has an
92account in Kofa nor can access Kofa through its regular login page.
93The manager has to enter the portal through the Grok UI which
94usually ony runs on a localhost port, for example
95``http://localhost:8080``.
Note: See TracBrowser for help on using the repository browser.