source: main/waeup.kofa/trunk/docs/source/userdocs/users.rst @ 12925

Last change on this file since 12925 was 12922, checked in by Henrik Bettermann, 10 years ago

Include links to doctests.

File size: 3.5 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
34Applicants and Students
35=======================
36
37Logged-in applicants or students are regular authenticated Kofa
38users. Their user account object is an adaption of their
39applicant/student object. More precisely, the Applicant/Student
40authenticator fetches the matching applicant/student object and
41turns it on-the-fly into a Kofa account object which is further used
42for creating a principal instance. The `applicant_id`/`student_id`
43attribute becomes the user name and the `display_fullname` property
44serves as user title.
45
46
47Officers
48========
49
50.. seealso::
51
52   :ref:`Officers Doctests <userscontainer_txt>`
53
54Officers are users with a dedicated user account object stored in
55the ``users`` container (of type :py:class:`UsersContainer
56<waeup.kofa.userscontainer.UsersContainer>`) which is located in
57Kofa's root container. The officer account object has two more
58attributes than the principal instance which is created from the
59account data: (1) a `roles` attribute which is a list of global role
60names assigned to the officer, and (2) a private `_local_roles`
61attribute. The latter maps local role names to lists of objects the
62respective local role applies to. This information is important
63because local role assignment is originally stored only with the
64objects the role applies to and not with the user who got the role.
65When removing a user, Kofa iterates over the mapping and the list of
66objects in order to remove all these local role assignments denoted
67in the mapping.
68
69The management of portal officers is done in the 'Officers' section
70of Kofa. The management page shoes all officers registered in the
71portal together with their global and local roles. The table can be
72easily sorted or filtered.
73
74
75Manager
76=======
77
78There is one and only one manager account (user id ``zope.manager``)
79in Kofa. The manager has access to the root instance of the Kofa
80application which has its own user interface (see screenshot below).
81Through this 'Grok UI' the manager can access some basic functions
82to manage the database and also access the Kofa user interface.
83
84.. image:: Grok_UI.png
85
86Although the manager automatically gains all permissions the system
87defines, this real superuser (or emergency user) neither has an
88account in Kofa nor can access Kofa through its regular login page.
89The manager has to enter the portal through the Grok UI which
90usually ony runs on a localhost port, for example
91``http://localhost:8080``.
Note: See TracBrowser for help on using the repository browser.