So here's the deal...
Back in the mists of time, before Cosmo freebusy reports, Chandler had a
hack for implementing a first pass at freebusy. Any collection that
was in the dashboard (also known as a "mine" collection) would be
published in a subcollection in cosmo.
Collections not in the dashboard ("not mine") would live here:
/home/capps/myCatsCollection
Collections in the dashboard ("mine") would live here:
/home/capps/freebusy/myHomeCollection
I won't make up details on exactly *how* this was used to support
freebusy, but suffice it to say (a) cosmo had no "freebusy" awareness --
these were just subcollections that happened to be named "freebusy" to
cosmo (b) even in alpha4 chandler no longer cared whether or not a
collection lived in a freebusy subcollection. Unfortunately, it did
still *publish* dashboard collections to freebusy subcollections,
because we unwound all of this too late and didn't get to that
particular bug.
That is the background. The current facts to deal with:
- We have users who are dogfooding alpha4 and have published dashboard
collections, so we have collections in "freebusy" subcollections on osaf.us
- If users log in to the Cosmo UI, they cannot access the "freebusy"
subcollections from the dropdown menu.
- Users can go find "freebusy" subcollections from the account browser,
and can get bookmarkable urls for those collections. The bookmarkable
urls work. (I just tried this out and can see my collections using a
ticket, for example).
- Presumably, alpha5 should be able to generate a bookmarkable url for
the afflicted collections.
- New collections created from alpha5 and beyond will not have this problem.
Just wanted to put this problem out there. What, if anything, should we
do about this?
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
