the 'charset' field is automatically if not specified by the
application. The 'charset' is determined by the content-type header
specified by the application (if available) or from the
zpublisher_default_encoding value as configured in etc/zope.conf

level at which conflict errors (which are normally retried
automatically) are logged. The default is 'info'.

This doesn't interfere with the error_log site object which copies
non-retried conflict errors the the error log at level 'error'.

(Made sure logging is configured. Read $INSTANCE_HOME/log.ini if it exists.)

     - Collector #1976: FTP STOR command would load the file being
       uploaded in memory. Changed to use a TemporaryFile.

import directories. (Merged from trunk.)

Thanks to Tim Peters for pointing out the flaw!

o ZODB 3.6 properly removed it, but Zope needs to keep it for another release
  because ZODB released *twice* during the Zope 2.9 release cycle.

first beta due to the now zpkg-based build and release process.

No commit message

The reason for that is because zpkg and distutils can't deal with arbitrary
data files that don't belong to a certain package.

exits.

brings it in line with BTreeFolder.

  - change SimpleItem.py to use python logging module
  - log at error when standard_error_message can't be rendered
  - give more useful info about errors rendering standard_error_message to the browser.
  - all conflict errors are counted and logged at info
  - logging makes it clear where the conflict has been resolved and where it hasn't
  - errors seen by the user are rendered with standard_error_message and are sent to the error_log which will likely copy them to the event log, depending on the users setup.
  - also checking in a functional test for generating write conflict errors.
    
  (I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges simpler)

- remove unused import.
- change SimpleItem.py to use python logging module
- log at error when standard_error_message can't be rendered
- give more useful info about errors rendering standard_error_message to the browser.
- all conflict errors are counted and logged at info
- logging makes it clear where the conflict has been resolved and where it hasn't
- errors seen by the user are rendered with standard_error_message and are sent to the error_log which will likely copy them to the event log, depending on the users setup.
- also checking in a functional test for generating write conflict errors.
  
(I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges simpler)

- all conflict errors are counted and logged at info, as they were before Florent's change
- logging makes it clear where the conflict has been resolved and where it hasn't
- errors seen by the user are rendered with standard_error_message and are sent to the error_log which will likely copy them to the event log, depending on the users setup.
- also checking in a functional test for generating write conflict errors.

(I'll be committing to CHANGES.TXT shortly, I just wanted to keep the merges simpler)

- log at error when standard_error_message can't be rendered
- give more useful info about errors rendering standard_error_message to the browser.

We now check ownership and proxy roles if an executable object is on the stack.

Note that we have removed the C implementation of 'checkPermission'.