Projects
Wiki     Timeline     Roadmap     Browse Source     View Tickets     New Ticket     Search

{5} Assigned, Active Tickets by Owner (Full Description) (15 matches)

List tickets assigned, group by ticket owner. This report demonstrates the use of full-row display.

cdaboo@… (1 match)

Ticket Summary Component Milestone Type Created
Description
#107 Too many children of type {DAV:}prop for {DAV:}principal-match Calendar Server Later Defect 12/14/06 
2006/12/14 23:04 -0700 [HTTPChannel,99,127.0.0.1] REPORT /principals/user/ HTTP/1.1
2006/12/14 23:04 -0700 [-] Exception rendering:
2006/12/14 23:04 -0700 [-] Unhandled Error
        Traceback (most recent call last):
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 239, in callback
            self._startRunCallbacks(result)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 304, in _startRunCallbacks
            self._runCallbacks()
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 317, in _runCallbacks
            self.result = callback(self.result, *args, **kw)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 647, in gotResult
            _deferGenerator(g, deferred)
        --- <exception caught here> ---
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 623, in _deferGenerator
            result = g.next()
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/method/report.py", line 69, in http_REPORT
            doc = doc.getResult()
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 609, in getResult
            self.result.raiseException()
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/internet/defer.py", line 317, in _runCallbacks
            self.result = callback(self.result, *args, **kw)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/util.py", line 66, in gotAllData
            return filter(result)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/util.py", line 79, in parse
            return davxml.WebDAVDocument.fromString(xml)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/element/parser.py", line 218, in parse
            parser.parse(source)
          File "/System/Library/Frameworks/Python.framework/Versions/2.4/Extras/lib/python/_xmlplus/sax/expatreader.py", line 109, in parse
            xmlreader.IncrementalParser.parse(self, source)
          File "/System/Library/Frameworks/Python.framework/Versions/2.4/Extras/lib/python/_xmlplus/sax/xmlreader.py", line 123, in parse
            self.feed(buffer)
          File "/System/Library/Frameworks/Python.framework/Versions/2.4/Extras/lib/python/_xmlplus/sax/expatreader.py", line 216, in feed
            self._parser.Parse(data, isFinal)
          File "/System/Library/Frameworks/Python.framework/Versions/2.4/Extras/lib/python/_xmlplus/sax/expatreader.py", line 364, in end_element_ns
            self._cont_handler.endElementNS(pair, None)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/element/parser.py", line 178, in endElementNS
            element = top["class"](*top["children"], **top["attributes"])
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/element/rfc3744.py", line 660, in __init__
            super(PrincipalMatch, self).__init__(*children, **attributes)
          File "/Volumes/data/Users/wsanchez/Developer/CalendarServer/Twisted/twisted/web2/dav/element/base.py", line 124, in __init__
            assert max > 0, "Too many children of type %s for %s" % (child.sname(), self.sname())
        exceptions.AssertionError: Too many children of type {DAV:}prop for {DAV:}principal-match

glyph@… (1 match)

Ticket Summary Component Milestone Type Created
Description
#469 incompatible with python-sqlparse 0.1.3 (Debian Testing) Calendar Server Later Enhancement 11/14/11

When starting the server with the system's python-sqlparse 0.1.3 instead of the version 0.1.2 that it would use as fallback, the server fails with: 

  File "/home/pohly/src/CalendarServer/CalendarServer/twext/enterprise/dal/parseschema.py", line 232, in nextColumn
    return self.parseColumn(maybeIdent.value)
  File "/home/pohly/src/CalendarServer/CalendarServer/twext/enterprise/dal/parseschema.py", line 307, in parseColumn
    theType = SQLType(typeName.value.encode("utf-8"), typeLength)
AttributeError: 'NoneType' object has no attribute 'encode'

Adding some print statements showed that it fails for varchar entries: 

txdav/common/datastore/sql_schema/current.sql
create table CALENDAR_HOME (
  RESOURCE_ID      integer      primary key default nextval('RESOURCE_ID_SEQ'),
=>  OWNER_UID        varchar(255) not null unique
);

In python-sqlparse, typeName.value was "varchar", same as the string representation of typeName itself. Based on that observation here's a crude patch which uses str(typeName) as default. Works for me, no idea whether it is the right fix...

  • CalendarServer/twext/enterprise/dal/parseschema.py 

    diff --git a/CalendarServer/twext/enterprise/dal/parseschema.py b/CalendarServer/twext/enterprise/dal/parseschema.py
index 0978b5f..4e3fcb1 100644
    a b class _ColumnParser(object): 
    304304                # something else 
    305305                typeLength = None 
    306306                self.pushback(maybeTypeArgs) 
    307         theType = SQLType(typeName.value.encode("utf-8"), typeLength) 
     307        theType = SQLType((typeName.value or str(typeName)).encode("utf-8"), typeLength) 
    308308        theColumn = self.table.addColumn( 
    309309            name=name.encode("utf-8"), type=theType 
    310310        ) 

wsanchez@… (13 matches)

Ticket Summary Component Milestone Type Created
Description
#79 Add list of system requirements Infrastructure Later Defect 11/03/06

We need to add a list of software requirements for the server - specifically things we assume are already installed. e.g., sqllite 3, SVN 1.3 or greater, Python 2.4 or greater, Kerberos, etc.

#118 Docs need another roll Calendar Server Later Defect 01/04/07

Documentation (on the Wiki) is stale again:

  • repository.xml no longer exists.
  • Directory services may need a once-over.
  • Need to document caldavd.plist.
  • Update README.
  • We probably need more detailed docs in the project itself, since they should be versioned with the code.
#33 API Documentation should be made available via the web. Infrastructure Later Defect 08/17/06

Currently API documentation can be generated by running doc/gendocs but an up-to-date copy should also be available on the website. Possibly as part of an svn post-commit hook.

#154 Inheritable ACEs should be passed down to instantiated child resources Calendar Server Later Defect 04/19/07

12/7/06 6:53 PM Wilfredo Sanchez: Inheritable ACEs should be passed down to instantiated child resources

This keeps them easily available for ACL queries, rather than having to computer them (at least once) by walking the URL tree.

#212 We should avoid the non-standard Connection.execute method in sqlite3. Calendar Server Later Defect 01/11/08

​http://docs.python.org/lib/sqlite3-Connection-Objects.html

It documents several methods as "nonstandard shortcuts" we should avoid using any of these methods specifically Connection.execute because it prevents us from working on older but otherwise compatible sqlite modules.

#16 Use incremental XML parsing to avoid blocking Calendar Server Later Enhancement 08/15/06

When we receive requests from the network which contain XML bodies (eg. DAV methods), we read the request stream into memory until we have all of it, then parse the XML. This is the only option we ahve with PyXML, I think, since it's parse() routines require a string, or do blocking I/O on a filehandle.

The downside here is that we have to have all of the XML in memory before we can continue, which is lame.

What we actually want is a parser that we can feed data to incrementally. ElementTree appears to have this property, so switching parsers to ElementTree could be nice. ElementTree also has the advantage of being slated for inclusion in future python releases, seems lighter weight than PyXML, and has a less complicated licensing situation.

We should also consider LXML, which is ElementTree-like, but binds to the Libxml2 C library and apparently performs better.

What we're after here is better performance, in terms of both memory and CPU. XML parsing and iCalendar parsing are, I think, going to be some of our prominent bottlenecks.

I'll mark this as a P4 for Preview 1, since our main goal for Preview 1 is feature completeness, so people can start using it.

#64 Extract attachments from iCalendar resources Calendar Server Later Enhancement 09/26/06

If a client writes an iCalendar resource with an attachment in it (encoded inline, rather than referenced by URI), the iCalendar data will be large. This is problematic if the client wishes to make a small (in terms of data size) change to the iCalendar data, such as changing the event title or time, because it will also have to re-upload all of the attachment data as well. A change of a few bytes could end up requiring megabytes (or more) to be sent over the wire.

A solution I'd like to pursue involved the server extracting the attachment from the resource during PUT, parking the attachment in a different location, and rewriting the iCalendar data to reference the attachment resource by URI.

#52 Calendar collections only properties appear on all resources Calendar Server CalendarServer-6.x Defect 09/15/06

Properties: supported-calendar-set, supported-calendar-data and max-resource-size are only defined on calendar collection resources, but they appear on ALL CalDAVResource objects.

It is hard to change this without making a new CalDAVCalendarCollectionResource type with those listed as live-properties and remove them from CalDAVResource.

Note that we are not strictly violating the spec as it only says those properties MAY be defined on calendar collections. It does not say they MUST NOT be on other resources. So this is just a nice to have fix.

#116 IDAVPrincipalCollectionResource is incomplete Calendar Server CalendarServer-6.x Defect 01/04/07

It does not include several generally useful methods found on DirectoryPrincipalCollectionResource, such as principalForUser. It should also contain a principalForShortName method that is analogous to DirectoryService.recordWithShortName taking a type and a shortname.

#122 Be better about exception classes Calendar Server Later Defect 01/26/07

We're totally over-using ValueError, etc. when we should be creating new exception classes.

Let's go though and try to clean that up...

#139 DeltaV preconditions and postconditions Calendar Server Later Defect 04/19/07

Ensure that these are being met, and that the correct responses (XML) are being sent back when they are not.

Some errors may still return HTML responses instead of XML responses.

I'm wondering if we can avoid duplicating error handling code here... perhaps sending XML to all DAV clients is OK.

Also have to make sure CalDAV preconditions and postconditions are all checked.

It's not clear how critical this is; depends on how many of our clients will simply use status codes vs. try to parse the response XML.

#74 Clean up unused time zone definitions? Calendar Server Later Enhancement 10/18/06

If a client sends us iCalendar data (eg. in PUT) which contains a VTIMEZONE component that is not referred to by any other component in the (eg. VEVENT) resource, the VTIMEZONE component is superfluous data.

It's not illegal to do this, but it is rather goofy, since it's simply a (admittedly small) waste of disk space and bandwidth.

Perhaps we should rewrite the data in this case to remove the superfluous component.

#19 hCalendar input/output Calendar Server Later Feature 08/15/06

It would be swell if the server could accept ​hCalendar input and emit hCalendar output, given the right content-type/accept headers. This would help the microformats folks use it to embed calendar data into HTML and so on.

Note: See TracReports for help on using and creating reports.