Mailing List Archive

Unless I'm missing something as well I think the 0.9.8 web interface is
indeed missing those functions.

In my testing I'm also unable to find anyway to view the grants I make. So
even though I can set permissions and from what I can see from clients they
work, I've got no way to see what is set or to remove existing grants.

These bugs are a pity since apart from them I think the 0.9.8 web interface
is a huge improvement but without them fixed I'm unable to upgrade my
companies install to 0.9.8

Does anybody know if a bug fix release to cover these issues is planned?
I've had a hunt through the wiki but I'm not seeing planning/release notes
for a 0.9.8.1 or similar.

Thanks
Jason

2009/12/29 Norbert P?schel <norbert.pueschel at networker-gmbh.de>

> Hello,
>
> am I missing something obvious or is the 0.9.8-admin GUI lacking the
> delete funktion for principals and collections?
>
> Regards,
> Norbert P?schel
>
>

On Wed, 2010-01-13 at 10:07 +1300, Jason alavaliant wrote:
> Unless I'm missing something as well I think the 0.9.8 web interface
> is indeed missing those functions.
>
> In my testing I'm also unable to find anyway to view the grants I
> make. So even though I can set permissions and from what I can see
> from clients they work, I've got no way to see what is set or to
> remove existing grants.

They should be listed on the principals screen if you go into 'List
Users' and then click on the principal you're interested in, you should
see a list of the grants. that principal has made.


> These bugs are a pity since apart from them I think the 0.9.8 web
> interface is a huge improvement but without them fixed I'm unable to
> upgrade my companies install to 0.9.8
>
> Does anybody know if a bug fix release to cover these issues is
> planned? I've had a hunt through the wiki but I'm not seeing
> planning/release notes for a 0.9.8.1 or similar.

I'm afraid I'm on the core organising team for linux.conf.au and so for
the next two weeks that's pretty much my whole life... as it has been
for quite a while already, but with 600 geeks descending on Wellington
next week things are really starting to get busy now!


There are a bunch of changes committed to Git already towards 0.9.8.1
and there will be some more, and then I'll release it as soon as
possible. Certainly I'm hoping it will be back on track to be
releasable to a wider audience.

I was aware of the limitations of 0.9.8 in terms of some limitations in
the web maintenance side of things, but I felt I had to release it
partly in order to uncover worse omissions, and so others could also be
developing against the new permissions model, which is a huge change
internally.

From my POV critical things that I need to fix before I can release
0.9.8.1 are:

* need to be able to edit principals through the web interface without
having to be an administrator who can do anything.

* the javascript on the edit collection screen needs to be fixed to
properly toggle what is editable for a calendar collection.

* functionality to delete a principal

* functionality to delete a collection

* functionality to create a collection from a (possibly empty) uploaded
iCalendar file

Anyone who wants to send me a patch for that second one, in particular,
would make me very happy, since javascript is something I don't
generally write much of :-)

The last three should be pretty easy - I just always forget people like
to delete records, since my preference is for marking them as inactive
and leaving them in the database. The first one is the one I need to
spend time thinking hard about.

There's a little more in the TODO file that would be nice, but if I had
those two resolved I think I'd release with all the other changes I've
already committed.

Cheers,
Andrew.

PS. If someone feels like adding this to the pre-release notes for
0.9.8.1 on the wiki then I'd be grateful there too... :-)

>
> Thanks
> Jason
>
> 2009/12/29 Norbert P?schel <norbert.pueschel at networker-gmbh.de>
> Hello,
>
> am I missing something obvious or is the 0.9.8-admin GUI
> lacking the
> delete funktion for principals and collections?
>
> Regards,
> Norbert P?schel


------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Does the turtle move for you? www.kame.net
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100113/405ab11f/attachment.pgp>
-------------- next part --------------

On Wed, Jan 13, 2010 at 10:55 PM, Andrew McMillan <andrew at morphoss.com>wrote:

> On Wed, 2010-01-13 at 10:07 +1300, Jason alavaliant wrote:
> > Unless I'm missing something as well I think the 0.9.8 web interface
> > is indeed missing those functions.
> >
> > In my testing I'm also unable to find anyway to view the grants I
> > make. So even though I can set permissions and from what I can see
> > from clients they work, I've got no way to see what is set or to
> > remove existing grants.
>
> They should be listed on the principals screen if you go into 'List
> Users' and then click on the principal you're interested in, you should
> see a list of the grants. that principal has made.
>
>
Nothing there for me. I've got the 'Principal Grants' section where I can
select users and apply grants. I can message up the top saying that the
grant has been applied and the user I apply the grant to disappears from the
list of users but there is no sign of a list of existing grants anywhere I
can see on that page.


I was wondering if it could be somehow related to the issues with the
database I upgraded from (See the 'Broken iCal Delegation listing /
Database?' email from me to the list a month and 1/2 ago for details on
that). So I tried restoring a backup from before we damaged our original
database. That one had the same issue. I'll try a completely fresh
database in a bit once I find a good way to run the creation scripts when
the davical server and postgres server aren't on the same machine.


My testing has made me notice two other issues as well;

'The Principal Collections' list in the web interface isn't showing all the
collections for some of my users. For example on my 0.9.7.6 server my
account has 4 collections present, when I import the database onto the
0.9.8 server (and run the update script) viewing the web interface my
account has no collections listed. They are there though as I can access
them via the caldav.php url for the dev server. I can't find any
consistency to which ones aren't shown though, most user's have their
collections listed and some of my database backups show my collections, just
not other ones.

Also there is no option in the new web interface to set the language for
users. I accentually left the language selection to de_DE for the admin
account in my first install (as in the first version I installed it wasn't
changing the web interface language. ) So now I've restored my oldest
database I'm having to use the admin interface while guessing what things
like "Erteile neues, von diesem Principal ausgehendes Recht" mean.... I
should be able to fix that by manually editing the database if I have to but
I think an option for it might be nice :)






>
> The last three should be pretty easy - I just always forget people like
> to delete records, since my preference is for marking them as inactive
> and leaving them in the database. The first one is the one I need to
> spend time thinking hard about.
>
>

Thanks for the update on 0.9.8.1 Deleting records can be handy for
testing - to ensure the automatic account creation for new users via ldap is
working on my 0.9.8 install I need to remove an existing account and then
try to log in and see if the account is created. (I can't use the ldap
sync option to do all accounts, from what I can tell my companies oddball
ldap server lacks a modifyTimestamp attribute or anything else close enough
to be substruted so a sync always errors out because nothing has the
attributes it's looking for.)


Thanks
-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100120/aa085884/attachment.htm>
-------------- next part --------------

On Wed, Jan 20, 2010 at 6:44 PM, Jason alavaliant <alavaliant at gmail.com>wrote:

>
>
> On Wed, Jan 13, 2010 at 10:55 PM, Andrew McMillan <andrew at morphoss.com>wrote:
>
>> On Wed, 2010-01-13 at 10:07 +1300, Jason alavaliant wrote:
>> > Unless I'm missing something as well I think the 0.9.8 web interface
>> > is indeed missing those functions.
>> >
>> > In my testing I'm also unable to find anyway to view the grants I
>> > make. So even though I can set permissions and from what I can see
>> > from clients they work, I've got no way to see what is set or to
>> > remove existing grants.
>>
>> They should be listed on the principals screen if you go into 'List
>> Users' and then click on the principal you're interested in, you should
>> see a list of the grants. that principal has made.
>>
>>
> Nothing there for me. I've got the 'Principal Grants' section where I can
> select users and apply grants. I can message up the top saying that the
> grant has been applied and the user I apply the grant to disappears from the
> list of users but there is no sign of a list of existing grants anywhere I
> can see on that page.
>
>
> I was wondering if it could be somehow related to the issues with the
> database I upgraded from (See the 'Broken iCal Delegation listing /
> Database?' email from me to the list a month and 1/2 ago for details on
> that). So I tried restoring a backup from before we damaged our original
> database. That one had the same issue. I'll try a completely fresh
> database in a bit once I find a good way to run the creation scripts when
> the davical server and postgres server aren't on the same machine.
>
>
>

I got a fresh blank database setup with
/usr/share/davical/dba/create-database.sh today. The grants I make
with that one get shown in the web interface... So it looks like the
root of all my issues is some sort of problem (corruption?) with my existing
database. Hopefully you might be able to give some suggestions when
you get more time after linux.conf.au ends. In the mean time I'll try
diffing the fresh database against my broken one and see if I can guess at
where the problem is.


>
>
> Thanks
> -J
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100121/d3b8e967/attachment.htm>
-------------- next part --------------

On Thu, Jan 21, 2010 at 3:45 PM, Jason alavaliant <alavaliant at gmail.com>wrote:

>
>
> On Wed, Jan 20, 2010 at 6:44 PM, Jason alavaliant <alavaliant at gmail.com>wrote:
>
>>
>>
>> On Wed, Jan 13, 2010 at 10:55 PM, Andrew McMillan <andrew at morphoss.com>wrote:
>>
>>> On Wed, 2010-01-13 at 10:07 +1300, Jason alavaliant wrote:
>>> > Unless I'm missing something as well I think the 0.9.8 web interface
>>> > is indeed missing those functions.
>>> >
>>> > In my testing I'm also unable to find anyway to view the grants I
>>> > make. So even though I can set permissions and from what I can see
>>> > from clients they work, I've got no way to see what is set or to
>>> > remove existing grants.
>>>
>>> They should be listed on the principals screen if you go into 'List
>>> Users' and then click on the principal you're interested in, you should
>>> see a list of the grants. that principal has made.
>>>
>>>
>> Nothing there for me. I've got the 'Principal Grants' section where I
>> can select users and apply grants. I can message up the top saying that
>> the grant has been applied and the user I apply the grant to disappears from
>> the list of users but there is no sign of a list of existing grants anywhere
>> I can see on that page.
>>
>>
>> I was wondering if it could be somehow related to the issues with the
>> database I upgraded from (See the 'Broken iCal Delegation listing /
>> Database?' email from me to the list a month and 1/2 ago for details on
>> that). So I tried restoring a backup from before we damaged our original
>> database. That one had the same issue. I'll try a completely fresh
>> database in a bit once I find a good way to run the creation scripts when
>> the davical server and postgres server aren't on the same machine.
>>
>>
>>
>
> I got a fresh blank database setup with
> /usr/share/davical/dba/create-database.sh today. The grants I make
> with that one get shown in the web interface... So it looks like the
> root of all my issues is some sort of problem (corruption?) with my existing
> database. Hopefully you might be able to give some suggestions when
> you get more time after linux.conf.au ends. In the mean time I'll try
> diffing the fresh database against my broken one and see if I can guess at
> where the problem is.
>
>


Actually I think I've found a much simpler answer to things. My primary
postgres server is 8.1.11 which never looked too closely into since the
release notes at http://wiki.davical.org/w/Release_Notes/0.9.8 say postgres
8.1 or later. (looking over email I now notice that you mentioned in the
release email that 8.1 was never tested with but I didn't notice that until
now.)

However for the last test above I ended up installing a postgres server on
to my dev box since I couldn't work out how to use the create-database.sh
script against a remote server. it just so happened that 8.3.9 was what
got installed on the dev box.

Which happened to be the first time everything got shown to me in the web
interface, after I realised that I tried copying a dump from my primary
server on there and running the upgrade script and what do you know things
worked. (grants AND collections were all listed perfectly in the web
interface.) Unless somebody else can report 0.9.8 running perfectly on
postgres 8.1.11 I'm going to say something in 0.9.8 actually requires a
higher version of postgres than 8.1.11 to function properly... I guess the
twiki page should say required version 8.2 or higher?

Thanks
-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100121/7d2e4fa1/attachment-0001.htm>
-------------- next part --------------

On Thu, Jan 21, 2010 at 6:41 PM, Jason alavaliant <alavaliant at gmail.com>wrote:

>
>
> On Thu, Jan 21, 2010 at 3:45 PM, Jason alavaliant <alavaliant at gmail.com>wrote:
>
>>
>>
>> On Wed, Jan 20, 2010 at 6:44 PM, Jason alavaliant <alavaliant at gmail.com>wrote:
>>
>>>
>>>
>>> On Wed, Jan 13, 2010 at 10:55 PM, Andrew McMillan <andrew at morphoss.com>wrote:
>>>
>>>> On Wed, 2010-01-13 at 10:07 +1300, Jason alavaliant wrote:
>>>> > Unless I'm missing something as well I think the 0.9.8 web interface
>>>> > is indeed missing those functions.
>>>> >
>>>> > In my testing I'm also unable to find anyway to view the grants I
>>>> > make. So even though I can set permissions and from what I can see
>>>> > from clients they work, I've got no way to see what is set or to
>>>> > remove existing grants.
>>>>
>>>> They should be listed on the principals screen if you go into 'List
>>>> Users' and then click on the principal you're interested in, you should
>>>> see a list of the grants. that principal has made.
>>>>
>>>>
>>> Nothing there for me. I've got the 'Principal Grants' section where I
>>> can select users and apply grants. I can message up the top saying that
>>> the grant has been applied and the user I apply the grant to disappears from
>>> the list of users but there is no sign of a list of existing grants anywhere
>>> I can see on that page.
>>>
>>>
>>> I was wondering if it could be somehow related to the issues with the
>>> database I upgraded from (See the 'Broken iCal Delegation listing /
>>> Database?' email from me to the list a month and 1/2 ago for details on
>>> that). So I tried restoring a backup from before we damaged our original
>>> database. That one had the same issue. I'll try a completely fresh
>>> database in a bit once I find a good way to run the creation scripts when
>>> the davical server and postgres server aren't on the same machine.
>>>
>>>
>>>
>>
>> I got a fresh blank database setup with
>> /usr/share/davical/dba/create-database.sh today. The grants I make
>> with that one get shown in the web interface... So it looks like the
>> root of all my issues is some sort of problem (corruption?) with my existing
>> database. Hopefully you might be able to give some suggestions when
>> you get more time after linux.conf.au ends. In the mean time I'll try
>> diffing the fresh database against my broken one and see if I can guess at
>> where the problem is.
>>
>>
>
>
> Actually I think I've found a much simpler answer to things. My primary
> postgres server is 8.1.11 which never looked too closely into since the
> release notes at http://wiki.davical.org/w/Release_Notes/0.9.8 say
> postgres 8.1 or later. (looking over email I now notice that you mentioned
> in the release email that 8.1 was never tested with but I didn't notice that
> until now.)
>
> However for the last test above I ended up installing a postgres server on
> to my dev box since I couldn't work out how to use the create-database.sh
> script against a remote server. it just so happened that 8.3.9 was what
> got installed on the dev box.
>
> Which happened to be the first time everything got shown to me in the web
> interface, after I realised that I tried copying a dump from my primary
> server on there and running the upgrade script and what do you know things
> worked. (grants AND collections were all listed perfectly in the web
> interface.) Unless somebody else can report 0.9.8 running perfectly on
> postgres 8.1.11 I'm going to say something in 0.9.8 actually requires a
> higher version of postgres than 8.1.11 to function properly... I guess the
> twiki page should say required version 8.2 or higher?
>
> Thanks
> -J
>


I've gone ahead and updated the 0.9.8 release notes twiki page to say
postgres 8.2 or higher since nobody seems to dispute my findings that 0.9.8
doesn't fully work on 8.1.

Since my last email I've gone ahead and upgraded my company to 0.9.8
overall the experience has been very positive. Many people are raving
about the speed increases and so far no huge issues.

I've run into a few small issues though.

Firstly I've got a calendar with an entry that can't be deleted. There
doesn't seem to be much that shows up in the apache logs but in iCal if I
try to delete it I get;
The server responded with
"HTTP/1.0 500 Internal Server Error"
to operation CalDAVScheduleEventQueueableOperation./
in a popup box, Sunbird/lightning can't delete the event either, their
error messages don't give anything much useful though. So far it seems
limited to that one event, I was thinking I could just delete the event
from the database directly. I'm unsure if there are multiple places I'd
need to update to do it though. (I think I just need to delete the right
line from calendar_item?)

Secondly I created a new user (type: resource) for sharing some schedules
and then used the 'create collection' button in the web interface to add two
new collections with 'is a calendar' turned on. I thought that was the
right thing to do but iCal seems unable to detect any calendars under that
name and using sunbird if I put the full address in I get "Warning: There
has been an error reading data for calendar: photostudio-one. However, this
error is believed to be minor, so the program will attempt to continue.
Error code: DAV_DAV_NOT_CALDAV. Description: The resource at
https://cal.company.com/photostudio/one/ is a DAV collection but not a
CalDAV calendar" Since there seems to be no option in the web interface
to delete the collection I'm unsure how to fix this up as short of deleting
the entries directly from the db I can't even start over.

Finally I tried putting
$c->default_privileges = array('read', 'read-free-busy',
'schedule-query-freebusy');
in my config file as per http://wiki.davical.org/w/Permissions so that all
calendars would be globally readable by default. I think 'read' is the
right permission name to use but it doesn't seem to have any effect on
accounts created from ldap? New users have only the 'Scheduling: Deliver a
Reply' permissions set on in their defaults after their account is
created. If I use the 'create principle' option in the web interface the
right boxes are ticket but if I user just logs in and the account is created
via ldap data being imported it's given a different set of defaults. Does
the ldap code do something different for defaults on 0.9.8?

Any thoughts on the above points would be greatly helpful.

Thanks
-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100126/91f5d1bf/attachment.htm>
-------------- next part --------------

On Tue, 2010-01-26 at 14:52 +1300, Jason alavaliant wrote:
>
> I've gone ahead and updated the 0.9.8 release notes twiki page to say
> postgres 8.2 or higher since nobody seems to dispute my findings that
> 0.9.8 doesn't fully work on 8.1.

Yes, it seems there might be several issues with 8.1 that I wasn't aware
of. I've tried to code using the 8.1 specification, and it would be
nice to identify what these are, but none of my own servers have 8.1 on
them and realistically I probably don't have the time to find somewhere
I could install it, etc, etc, ... so I think for now we'll have to say
"must be 8.2 or later".


> Since my last email I've gone ahead and upgraded my company to 0.9.8
> overall the experience has been very positive. Many people are
> raving about the speed increases and so far no huge issues.
>
> I've run into a few small issues though.
>
> Firstly I've got a calendar with an entry that can't be deleted.
> There doesn't seem to be much that shows up in the apache logs but in
> iCal if I try to delete it I get;
> The server responded with
> "HTTP/1.0 500 Internal Server Error"
> to operation CalDAVScheduleEventQueueableOperation./
> in a popup box, Sunbird/lightning can't delete the event either,
> their error messages don't give anything much useful though. So
> far it seems limited to that one event, I was thinking I could just
> delete the event from the database directly. I'm unsure if there are
> multiple places I'd need to update to do it though. (I think I just
> need to delete the right line from calendar_item?)

Yes, that's correct: deleting the row from calendar_item and/or
caldav_data should do it (and a trigger should delete the matching row
from the other table).


> Secondly I created a new user (type: resource) for sharing some
> schedules and then used the 'create collection' button in the web
> interface to add two new collections with 'is a calendar' turned on.
> I thought that was the right thing to do but iCal seems unable to
> detect any calendars under that name and using sunbird if I put the
> full address in I get "Warning: There has been an error reading data
> for calendar: photostudio-one. However, this error is believed to be
> minor, so the program will attempt to continue. Error code:
> DAV_DAV_NOT_CALDAV. Description: The resource at
> https://cal.company.com/photostudio/one/ is a DAV collection but not a
> CalDAV calendar" Since there seems to be no option in the web
> interface to delete the collection I'm unsure how to fix this up as
> short of deleting the entries directly from the db I can't even start
> over.

Sounds like the collection has been created as a non-calendar. I know
some bugs around new user creation have been fixed in Git and will be in
the next release.


> Finally I tried putting
> $c->default_privileges = array('read', 'read-free-busy',
> 'schedule-query-freebusy');
> in my config file as per http://wiki.davical.org/w/Permissions so
> that all calendars would be globally readable by default.

The default permissions are set on user creation, not on collection
creation. If you set the collection.default_privileges field to NULL it
will take the default privileges from the principal.

> I think 'read' is the right permission name to use but it doesn't
> seem to have any effect on accounts created from ldap? New users
> have only the 'Scheduling: Deliver a Reply' permissions set on in
> their defaults after their account is created. If I use the 'create
> principle' option in the web interface the right boxes are ticket but
> if I user just logs in and the account is created via ldap data being
> imported it's given a different set of defaults. Does the ldap code
> do something different for defaults on 0.9.8?

I think that the 'created on login' is doing it correctly, but 'create
pcincipal' is not. I believe it's fixed in Git now... :-)


> Any thoughts on the above points would be greatly helpful.

Apologies for my distraction for the last few weeks with running
linux.conf.au, which I'm mostly recovered from now.

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Don't worry so loud, your roommate can't think.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100127/17fa0fdc/attachment.pgp>
-------------- next part --------------

On Wed, Jan 27, 2010 at 4:52 PM, Andrew McMillan <andrew at morphoss.com>wrote:

> On Tue, 2010-01-26 at 14:52 +1300, Jason alavaliant wrote:
> >
> > I've gone ahead and updated the 0.9.8 release notes twiki page to say
> > postgres 8.2 or higher since nobody seems to dispute my findings that
> > 0.9.8 doesn't fully work on 8.1.
>
> Yes, it seems there might be several issues with 8.1 that I wasn't aware
> of. I've tried to code using the 8.1 specification, and it would be
> nice to identify what these are, but none of my own servers have 8.1 on
> them and realistically I probably don't have the time to find somewhere
> I could install it, etc, etc, ... so I think for now we'll have to say
> "must be 8.2 or later".
>

Fair enough, I think most people will be ok with that as long as they know
what does and doesn't work.


>
>
> > Since my last email I've gone ahead and upgraded my company to 0.9.8
> > overall the experience has been very positive. Many people are
> > raving about the speed increases and so far no huge issues.
> >
> > I've run into a few small issues though.
> >
> > Firstly I've got a calendar with an entry that can't be deleted.
> > There doesn't seem to be much that shows up in the apache logs but in
> > iCal if I try to delete it I get;
> > The server responded with
> > "HTTP/1.0 500 Internal Server Error"
> > to operation CalDAVScheduleEventQueueableOperation./
> > in a popup box, Sunbird/lightning can't delete the event either,
> > their error messages don't give anything much useful though. So
> > far it seems limited to that one event, I was thinking I could just
> > delete the event from the database directly. I'm unsure if there are
> > multiple places I'd need to update to do it though. (I think I just
> > need to delete the right line from calendar_item?)
>
> Yes, that's correct: deleting the row from calendar_item and/or
> caldav_data should do it (and a trigger should delete the matching row
> from the other table).
>


That worked, however after that we noticed more events that were giving
that error when modifications were attempted. After some trial and error
we found that having 'invitees' set in the invitee field in iCal when
editing the event was what was causing the message. So far now we have
stopped putting invitees list into the calendar entries. I'm unsure
if this a problem with 0.9.8 not liking invitees in general or just with my
install?



>
>
> > Secondly I created a new user (type: resource) for sharing some
> > schedules and then used the 'create collection' button in the web
> > interface to add two new collections with 'is a calendar' turned on.
> > I thought that was the right thing to do but iCal seems unable to
> > detect any calendars under that name and using sunbird if I put the
> > full address in I get "Warning: There has been an error reading data
> > for calendar: photostudio-one. However, this error is believed to be
> > minor, so the program will attempt to continue. Error code:
> > DAV_DAV_NOT_CALDAV. Description: The resource at
> > https://cal.company.com/photostudio/one/ is a DAV collection but not a
> > CalDAV calendar" Since there seems to be no option in the web
> > interface to delete the collection I'm unsure how to fix this up as
> > short of deleting the entries directly from the db I can't even start
> > over.
>
> Sounds like the collection has been created as a non-calendar. I know
> some bugs around new user creation have been fixed in Git and will be in
> the next release.
>

Sounds good, can't wait to try that out in the next release. For now I've
found that putting an uncreated url into lightning 1.0b1 makes the calendar
get created on the server so I can just use that to make the calendars for
now. Only issue for now is cleaning up the non calendar entries I've
got in the place of where calendar entries should be going. Am I right in
assuming that I can delete the needed entry from the 'collection' table and
triggers will clean up entries in other tables or do I need to delete them
in other places too?





>
>
> > Finally I tried putting
> > $c->default_privileges = array('read', 'read-free-busy',
> > 'schedule-query-freebusy');
> > in my config file as per http://wiki.davical.org/w/Permissions so
> > that all calendars would be globally readable by default.
>
> The default permissions are set on user creation, not on collection
> creation. If you set the collection.default_privileges field to NULL it
> will take the default privileges from the principal.
>
> > I think 'read' is the right permission name to use but it doesn't
> > seem to have any effect on accounts created from ldap? New users
> > have only the 'Scheduling: Deliver a Reply' permissions set on in
> > their defaults after their account is created. If I use the 'create
> > principle' option in the web interface the right boxes are ticket but
> > if I user just logs in and the account is created via ldap data being
> > imported it's given a different set of defaults. Does the ldap code
> > do something different for defaults on 0.9.8?
>
> I think that the 'created on login' is doing it correctly, but 'create
> pcincipal' is not. I believe it's fixed in Git now... :-)
>
>
sounds good, I can survive manually fixing new users each few days until
the next release.


>
> > Any thoughts on the above points would be greatly helpful.
>
> Apologies for my distraction for the last few weeks with running
> linux.conf.au, which I'm mostly recovered from now.
>
>


Thanks for getting back to me, I can imagine it was pretty time consuming.
I only managed to go to a few talks but half my co-workers were out for
hours at it.
I can appreciate the struggle it must be to find enough time to answer all
the questions you get / finish new versions. (I maintain a few small
opensource apps myself.)

-J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100128/7b55cd9e/attachment.htm>
-------------- next part --------------

On Thu, 2010-01-28 at 15:25 +1300, Jason alavaliant wrote:

>
> That worked, however after that we noticed more events that were
> giving that error when modifications were attempted. After some
> trial and error we found that having 'invitees' set in the invitee
> field in iCal when editing the event was what was causing the message.
> So far now we have stopped putting invitees list into the calendar
> entries.

> I'm unsure if this a problem with 0.9.8 not liking invitees in general
> or just with my install?

It could be some bad interoperation beween iCal and DAViCal due to iCal
trying to use the scheduling extensions and DAViCal only having a
partial implementation.

I expect to have a more complete implementation of the scheduling
extensions in DAViCal in 0.9.8.2 that will resolve this, but it won't be
in the next release.


> Sounds good, can't wait to try that out in the next release. For
> now I've found that putting an uncreated url into lightning 1.0b1
> makes the calendar get created on the server so I can just use that to
> make the calendars for now.

A good workaround :-)


> Only issue for now is cleaning up the non calendar entries I've
> got in the place of where calendar entries should be going. Am I
> right in assuming that I can delete the needed entry from the
> 'collection' table and triggers will clean up entries in other tables
> or do I need to delete them in other places too?

Yes, the triggers should do all of the necessary cleanup. If they don't
it's definitely a bug :-)



> Apologies for my distraction for the last few weeks with
> running
> linux.conf.au, which I'm mostly recovered from now.

>
> Thanks for getting back to me, I can imagine it was pretty time
> consuming. I only managed to go to a few talks but half my
> co-workers were out for hours at it.
> I can appreciate the struggle it must be to find enough time to answer
> all the questions you get / finish new versions. (I maintain a few
> small opensource apps myself.)

I wish I'd been able to make it to some of the talks, as well as running
around making sure it was all going smoothly :-)

Fortunately everything was videoed, so we should have it all online in a
few short weeks...

Cheers,
Andrew.

------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
You own a dog, but you can only feed a cat.
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.morphoss.com/pipermail/davical-users/attachments/20100128/f79ece9e/attachment-0001.pgp>
-------------- next part --------------