Author: Zope Foundation and Contributors



.. contents::

CMFUid introduces a simple unique id implementation.


The supplied tools attach the unique ids to the objects. The objects
do not have to be aware of unique ids.

The current implementation depends on the portal catalog to find an 
object of a given unique id. The interfaces do not imply the use
of the catalog (except the IUniqueIdBrainQuery).

Which Tool does What?

The 'portal_uidgenerator' tools responsibility is to generate 
unique ids. The 'portal_uidannotation' tool is responsible to 
attach unique ids to a content object, and enforce rules about
what happens on object move/create/delete. The 'portal_uidhandler' 
manages registering and accessing unique ids. 

This design was chosen to allow users replacing only parts of
the functionality without having to understand the whole thing.

Unique Id API

'portal_uidhandler' implementing 'IUniqueIdHandler' is the main 
API for playing with unique ids.

'portal_uidhandler' fully implements IUniqueIdHandler (IUniqueIdSet
for registering/unregistering unique ids, IUniqueIdQuery for queries
and IUniqueIdBrainQuery for more efficient queries by returning 
catalog brains instead of objects).

The current implementation of get/queryBrain and get/queryObject 
do not return invisible objects (and brains of invisible objects).
By invisible objects, we mean objects that would be filtered out
by portal_catalog.searchResults due to expiry/effective date and/or
user roles.

It is often necessary to avoid this filtering in an application.
To do this, use the unrestrictedGet/QueryBrain and
unrestrictedGet/QueryObject as this will avoid 'None' results.

Have a look at the interfaces.

CMFUid's functionality is used by CMFDefault's favorite content type 
to follow linked objects. The favorite content type works as before if 
CMFUid is not installed. 

Update 2007-03-30

The annotation code has been updated to use events for assigning/removing 
uids.  The settings for this live in the portal_uidannotation tool.

The default behaviour is:

- uids are NOT assigned when an object is created
  (it is assumed that other code is responsible for this)

- when an object is moved, a UID is not changed

- when an object is imported, any EXISTING UID is removed
  (this can be controlled via the 'remove_on_add' property)

- when an object is copied, any EXISTING UID is removed
  (this can be controlled via the 'remove_on_clone' property)

A more natural behaviour is for UIDs to be assigned automatically on 
creation.  To enable this feature:

- tick the 'assign UIDs on add' tickbox
  (uids will now be assigned when content is added or imported and any
  EXISTING uid will be replaced)

- tick the 'assign UIDs on copy' tickbox
  (objects will get a NEW uid when they are copied which will replace 
  any EXISTING uid)

In order to preserve the original behaviour of the tool, automatic 
assignment of uids is NOT enabled by default - it must be turned on in 
the uidannotation tool.

The behaviour is hooked in based on object creating/deletion/move events
for any IContentish objects.  The event handlers live in the 
UniqueIdAnnotation tool.


Products.CMFUid Changelog

2.3.0-beta (2012-03-21)

- Made sure converted tools are used as utilities.

- Require at least Zope 2.13.4.

- Deal with deprecation warnings for Zope 2.13.

- Fix markup error (Chameleon compatibility)

2.2.0-beta (2009-12-06)

- no changes from version 2.2.0-alpha

2.2.0-alpha (2009-11-13)

- moved the Zope dependency to version 2.12.0b3dev

- Cleaned up / normalized imports:

  o Don't import from Globals;  instead, use real locations.

  o Make other imports use the actual source module, rather than an
    intermediate (e.g., prefer importing 'ClassSecurityInfo' from
    'AccessControl.SecurityInfo' rather tha