bugphpGroupWare - Bugs: bug #13205, better publish and subscribe...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #13205: better publish and subscribe functionality needed

Submitter:  Jan Vilhuber <jvilhuber>
Submitted:  Thu 26 May 2005 11:12:13 PM UTC
   
 
Category:  calendar Item Group:  0.9.16.005
Severity:  3 - Normal Priority:  5 - Normal
Status:  Invalid Privacy:  Public
Assigned to:  skwashd Open/Closed:  Closed
Component Version:  BZIP2 Operating System:  GNU/Linux - SuSE
Reproducibility:  Every Time Planned Release:  None
Fixed Release: 

Thu 02 Jun 2005 08:56:02 AM UTC, comment #2: 

This is a feature request not a bug report - closing

Some of this stuff is planned for 0.9.18

Dave Hall <skwashd>
Group administrator
Fri 27 May 2005 04:36:50 AM UTC, comment #1: 

One thing that I did to get around this, which is of course a gross, insecure hack, but may be a decent starting-point for a real solution, is as follows:

1) remove the need for authentication from ical.php
2) hardcode (ewwww) a login and password for a real phpgw user, who would preferably have read-only access. I'm not sure how else to get database access, i.e. a $sessionid.
3) add a parameter to the URL, i.e. calendar/ical.php?vilhuber would refer to the calendar by vilhuber.

This allows ANYONE to view anybody else's calendar at present.

Obvious improvements are to have a setting in a user's profile (or relevant calendar) that allows viewing by the ical.php program. Also, one could use vilhuber.Home instead of just 'vilhuber' to refer to a calendar called 'Home' by user 'vilhuber'. Not sure if phpgroupware has such a concept, though I think multiple calendars are allowed. If so, each calendar should, of course, have a 'allow export' flag of some sort. Other variantions of the calendar-access naming are of course possible.

That still seems a bit of a hack, but one can always improve later.

Jan Vilhuber <jvilhuber>
Thu 26 May 2005 11:12:13 PM UTC, original submission:  

A user should be able to publish his or her calendar to anyone. This sort of works via the calendar/ical.php, but this still requires a username password, and that username and password is used to look up the calendar. Which means that only I can 'subscribe' to the phpgroupware calendar, since only I (presumably) know my password.

Perhaps a better way to publish a calendar from within phpgroupware is to write out the calendar file in ics format to the directory set during setup time (I set mine to /var/lib/phpgroupware. This would be much easier on the database and user-logins than doing interactive dips into the database everytime someone calls ical.php.

Updates can be written either manually (through a 'Publish' button in the UI for example), or periodically, or automatically, whenever a change is made to the calendar.

Conversely, it would be great to be able to 'subscribe' to an external calendar. Currently, there's an import function, which seems to be able to read ical format, but this is an actual import. What is needed for subscribe functionality is to read the  external calendar, then put the entries (perhaps) into a separate calendar, and make it read-only. Next time we update the subscription (manually via 'Refresh' or automatically every X minutes), all entries are flushed from this calendar, and the new ones read (again read-only).


For extra credit, what I REALLY want is to be able to edit the calendar both locally in phpgroupware and on the remote computer, and have both remain in sync. Alas, I don't think the iCalendar format is good for that sort of thing, or at least not eaily. SunBird (mozilla) does this , by reading the remote calendar, mofifying it, then writing it back out. If every program did this, that could work, but a) they don't and b) this seems wildly inefficient (but I'm no expert on syncing technology...).

Jan Vilhuber <jvilhuber>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 3 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-06-02 skwashd StatusNone Invalid
    Assigned toNone skwashd
    Open/ClosedOpen Closed

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code