Questions about different type of accounts

[Bernhard Reiter]

Hi Pieter,

Am Donnerstag, 24. November 2005 18:02 schrieb Pieter Vanmeerbeek:
> You say that a resource account gives the calendar user access.

Yes, technically
the webinterface in current Servers encrypts the password of the user
for the calendar user.
This will change and the calendar user will get a simple access permission,
see https://intevation.de/roundup/kolab/issue965 .

> However I've made a setup with Konsec clients and was trying to use a
> resource account for a room. Upon adding this account to a meeting request
> an automatic reply came which indicated acceptance.
>
> However adding a second appointment at the same time interval using also
> this room was also accepted.

That sounds like a bug in the resource handling.
In all tests we did, you get a decline email when trying to invite the room
at the time where it is already "booked" when you set: reject if conflicts.

> My settings in the Kolab admin tool were
>
> Account type : resource
> Inivation policy :
>
> Anyone --> reject if conflicts
> ....   -- > Always accept
>
> (this second option is not clear to me , whats its purpose? )

You can add a chain of rules bound to distribution lists or users.
E.g. you could say: Always accept for big.boss at example.com.

> From this I would expect a decline of the second meeting. What did I do
> wrong?

I cannot say, please file a bug report with the necessary details:
Best would be to also send both invitation emails to a third account that does 
not modify them, include them in the report. 
Also include the resmgr logs.

> I created a new data file into the outlook client, and checked the access
> rights for the calendar folder. And only the resource itself had access to
> it. Something even stranger, the calendar was empty. This could be a Konsec
> related problem, as directly accessing the resource account on disk shows
> message files. 

This sound like Konsec problem then, it should display the contents like
a calendar in Outlook. They probably would want to know about the bug.

> These message files contain a section 
>
>
> This is a Kolab Groupware object. To view this object you will need a
> client that understands the Kolab Groupware format. For a list of such
> clients please visit http://www.kolab.org/kolab2-clients.html
> --=_5bcejg577yio
> Content-Type: application/x-vnd.kolab.event; name="kolab.event"
> Content-Disposition: attachment; filename="kolab.event"
> Content-Transfer-Encoding: 7bit
> <<
>
> And all other calendar objects created by the Konsec client also contains a
> tnef section. It also contains an xml section. So I suppose the tnef part
> isn't really needed.

The tnef part saves some outlook flags that cannot be known before
and are not saved in the XML. We from the Kolab project tried to convince
all Outlook connector developers to not use such an attachement if at all 
possible. It seems it cannot go without.
It would be much nice, if the unkown flags would just be saved as special 
email-headers and if we could identify them step by step to eliminate the 
need for them as much as possible.

Bernhard