martin: doc/architecture Makefile, 1.8, 1.9 client_server.sgml, 1.11, 1.12
cvs at intevation.de
cvs at intevation.de
Sun Oct 3 06:34:19 CEST 2004
- Previous message: martin: doc/architecture client_server.sgml,1.10,1.11
- Next message: stuart: doc/www/src default.css, 1.2, 1.3 index.html.m4, 1.26, 1.27 webclient.html.m4, 1.3, 1.4 client-features.html.m4, 1.3, 1.4
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: martin
Update of /kolabrepository/doc/architecture
In directory doto:/tmp/cvs-serv24694
Modified Files:
Makefile client_server.sgml
Log Message:
Martin K.: Added Kolab Invitation policies
Index: Makefile
===================================================================
RCS file: /kolabrepository/doc/architecture/Makefile,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- Makefile 29 Apr 2004 18:10:25 -0000 1.8
+++ Makefile 3 Oct 2004 04:34:17 -0000 1.9
@@ -37,7 +37,7 @@
concept/index.html: $(SGML_SRC) $(INCLUDED_SRCS)
$(HTML_CMD) $(SGML_SRC)
cp erfrakon.png $(HTML_DEST_DIR)/
- mv $(HTML_DEST_DIR)/index.html $(HTML_DEST_DIR)/index.html.tmp
+ cp $(HTML_DEST_DIR)/index.html $(HTML_DEST_DIR)/index.html.tmp
cat $(HTML_DEST_DIR)/index.html.tmp | sed -e 's/SRC=\"erfrakon\"/SRC=\"erfrakon\.png\"/g' > $(HTML_DEST_DIR)/index.html
rm $(HTML_DEST_DIR)/index.html.tmp
Index: client_server.sgml
===================================================================
RCS file: /kolabrepository/doc/architecture/client_server.sgml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -d -r1.11 -r1.12
--- client_server.sgml 3 Oct 2004 03:34:45 -0000 1.11
+++ client_server.sgml 3 Oct 2004 04:34:17 -0000 1.12
@@ -299,77 +299,108 @@
</para>
</sect1>
-<sect1><title>Automatic rules based accepting of invitations</title>
+<sect1><title>Automatic rules based handling of invitations</title>
<para>
-The server implements based on the webclient a mechanism for automatically
-accepting invitations to special accounts. These accounts
-could either represent a group (group account) or a resource (resource account
-e.g. a room, car, lcd beamer etc.).
-For the automatic acceptance a list of allowed senders is maintained in the LDAP
-directory. In case the sender is not in
-this sender list the request is queued like a normal invitation request and the
-sender is informed about the fact that his
-request is pending. In case of automatic acceptance no conflict detection is
-taking place. If the organizer (sender of the invitation)
-changes the appointment this information is propagated to the automatic account
-like traditional meeting requests. As a result the
-meeting is also moved in the automatic account. Whenever a change happens to the
-calendar of the automatic account the corresponding
-freebusy list is regenerated and published.
+The Kolab server implements a mechanism for handling of invitations.
+Typically this feature is used to handle bookings of resources (e.g. a room,
+car, lcd projector etc.).
</para>
<para>
-For resource and group accounts it is possble to configure the behaviour in case
-of a conflict. We only implement the following foure
-cases for any automatic account. This behaviour is configurable in the LDAP
-directory.
+For the automatic handling of invitations access control lists are used which
+define the action to be taken depending on the senders address.
+</para>
+<para>
+These ACLs are maintained in the LDAP directory. In case no ACL does match the
+request is queued in the INBOX of the recipient and the sender is informed about
+the fact that his request is pending.
+</para>
+<para>
+There are five different kind of Kolab invitation policy ACLs. Typically these
+values are prefixed with the primary email address of a sender to whom they
+shall apply. An omitted prefix represents an anonymous policy and means "apply
+to everyone".
+</para>
+<para>
+The sender is always informed via traditional accept and reject invitation
+messages using iCalendar format.
+</para>
<itemizedlist mark='bullet'>
<listitem>
<para>
-ignore conflicts, accept if sender is in allow list, queue if sender is not in
-allow list
+ACT_ALWAYS_ACCEPT
+</para>
+<para>
+In this case no conflict detection is taking place. If the organizer (sender of
+the invitation) changes the appointment this information is also propagated to
+the automatic account like traditional meeting requests. As a result the
+meeting is also moved in the automatic account. Whenever a change happens to the
+calendar of the automatic account the corresponding freebusy list is
+regenerated.
</para>
</listitem>
<listitem>
<para>
-ignore conflicts, accept if sender is in allow list, reject if sender is not in
-allow list
+ACT_ALWAYS_REJECT
+</para>
+<para>
+Invitations from senders which match this ACL are immediately rejected. In case
+this is an anonymous ACL then this account will not accept any invitations from
+any sender.
</para>
</listitem>
<listitem>
<para>
-detect conflict and reject or accept immediately if no conflict
+ACT_REJECT_IF_CONFLICTS
</para>
<para>
-detect conflict and queue or accept immediately if no conflict
+The invitation is accepted in case there is no conflict with other
+appointments and immediately rejected otherwiese. The check happens by refering
+to the uptodate free-busy list.
</para>
</listitem>
-</itemizedlist>
+<listitem>
+<para>
+ACT_MANUAL_IF_CONFLICTS
</para>
<para>
-The sender is always informed via traditional accept and reject invitation
-messages equivalent to normal non automatic invitations.
+The invitation is accepted in case there is no conflict with other
+appointments. In case a conflixt is detected the invitation is queued in the
+INBOX. It is expected that a user is manually maintaining the INBOX regularily.
</para>
+</listitem>
+<listitem>
<para>
-The adminstrating access to the automatic account is controlled analogous to all
-other accounts with access control lists. This means access
-controll list are based on user accounts and group membership. The later allows
-for flexible handling of changing membership without the
+ACT_MANUAL
+</para>
+<para>This is the default case for every account. Invitations are just queued in
+the INBOX of the recipient. The recipient then decides upon the request manually
+</para>
+</listitem>
+</itemizedlist>
+
+<para>
+In additon adminstrating access to resource accounts is controlled
+analogous to all other accounts with IMAP access control lists. This means
+access control lists are based on user accounts and group membership. The later
+allows for flexible handling of changing membership without the
need to permanently maintain all individual access permissions in case a user
changes.
</para>
+
<para>
The implementation of the webclient and the automatic handling of invitations is
handled in such a way that this web component can but is not required to run on
the primary Kolab server. From the point of view of the Kolab server the
-automatic account is implemented with just another Kolab client. This allows for
-clean and secure seperation while keeping scalability.
+automatic account can be distributed like any other account in a multi-location
+setup. This allows for clean and secure seperation while keeping scalability.
</para>
+
<para>
An automatic booking of a resource or the publishing of a meeting to a group is
simply done by adding the corresponding account to the list of invitations e.g.
-<email>Audi.A4 at kolab.erfrakon.de</email> or
-<email>marketing at kolab.erfrakon.de</email>.
+<email>Audi.A4 at erfrakon.de</email> or
+<email>group.kolab at erfrakon.de</email>.
</para>
</sect1>
- Previous message: martin: doc/architecture client_server.sgml,1.10,1.11
- Next message: stuart: doc/www/src default.css, 1.2, 1.3 index.html.m4, 1.26, 1.27 webclient.html.m4, 1.3, 1.4 client-features.html.m4, 1.3, 1.4
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the commits
mailing list