Personal tools
Skip to content. | Skip to navigation
Introduction This product provides a content rule action that will tweet an object's title and a short URL for it. Usage Simply add this product to your buildout and the new action should be available. You need to have at least one twitter account authorized for the current site, to do so, read the documentation for a dependency of this package http://pypi.python.org/pypi/collective.twitter.accounts
Usage Twitter profile portlet * Add a "Twitter profile Portlet" wherever you want. * Enter a header (if you want one). * Choose the Twitter account to use from the drop-down (see Prerequisites). * Enter the user you want to get the feed from. (username can be with @ or not). * Mark the checkbox for showing the avatars next to the username, or leave it unmarked for not. * Choose the maximum results you want to show each time. Twitter search portlet * Add a "Twitter search Portlet" wherever you want. * Enter a header (if you want one). * Choose the Twitter account to use from the drop-down (see Prerequisites). * Enter the search string you want to use. * Mark the checkbox for showing the avatars next to the username, or leave it unmarked for not. * Choose the maximum results you want to show each time. Extras From any portlet, you can: * Click on a "#" starting word (hashtag) to go to Twitter and get further results * Click on an "@" starting word (usernames) to go to the user profile in Twitter.
File upload widget with multiple file selection, drag&drop support, progress bars, client-side image resizing and preview images.
Multifileupload for Plone using uploadify Usage After install, go to http://your-plone-site/@@upload
Log user names when using cookie authentication in Zope/Plone.
What this package do? IMS VDEX is a standard for exchanging vocabularies. collective.vdexvocabulary create bridge between vdex vocabularies and zope vocabularies, so you can easily use it in systems like Plone / Zope. Contents What this package do? Whats so special about it? How do I use it? Example VDEX file How to access relations (from code) Where can I complain / help / send rum? Credit TODO History 0.1.2 (2014-01-07) 0.1.1 (2010-10-11) 0.1 (2010-06-23) 0.1a1 (2010-04-29) Whats so special about it? Imagine you have big vocabularies with a lot of relations. I'm talking +10.000 terms with +30.000 relations. So this would be perfect use case to use collective.vdexvocabulary. Also there are other stuff which I didn't found in other vocabulary packages for Plone/Zope: i18n support (as it is defined in IMS VDEX) proper order also with unicode charecters (if zope.ucol is installed) easy registration using zcml relations as it specified in IMS VDEX standard How do I use it? In your configure.zcml add: <configure ... xmlns:vdex="http://namespaces.zope.org/vdex" ...> <include package="collective.vdexvocabulary" file="meta.zcml" /> <include package="collective.vdexvocabulary" /> And to register a vdex vocabulary simply add line bellow pointing to file containing vdex vocabulary: <configure ... xmlns:vdex="http://namespaces.zope.org/vdex" ...> <vdex:vocabulary file="path-to/very-interesting.xml" /> To make registration of vocabularies even easier you can also register several vocabularies and just point to directory: <configure ... xmlns:vdex="http://namespaces.zope.org/vdex" ...> <vdex:vocabulary directory="path-to/my-vdex-vocabularies" /> vdex files in path-to/my-vdex-vocabularies directory should have ending .vdex to be recognized by vdex:vocabulary ZCML directive. Example VDEX file Example of car manufacturers list (car_manufacturers.vdex).: <?xml version="1.0" encoding="utf-8"?> <vdex xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" orderSignificant="false" language="en"> <vocabIdentifier>your.package.car_manufacturers</vocabIdentifier> <term> <termIdentifier>ford</termIdentifier> <caption> <langstring language="en">Ford</langstring> <langstring language="es">Una miedra de coche</langstring> </caption> </term> <term> <termIdentifier>bmw</termIdentifier> <caption> <langstring language="en">BMW</langstring> <langstring language="es">Be-eMe-uWe, mierda</langstring> </caption> </term> <relationship> <sourceTerm>bmw</sourceTerm> <targetTerm vocabIdentifier="your.package.car_models">very-special-bmw-model</targetTerm> <relationshipType source="http://www.imsglobal.org/vocabularies/iso2788_relations.xml">NT</relationshipType> </relationship> ... </vdex> List of car models (car_models.vdex).: <?xml version="1.0" encoding="utf-8"?> <vdex xmlns="http://www.imsglobal.org/xsd/imsvdex_v1p0" orderSignificant="false" language="en"> <vocabIdentifier>your.package.car_models</vocabIdentifier> <term> <termIdentifier>very-special-bmw-model</termIdentifier> <caption> <langstring language="en">Very special BMW model</langstring> <langstring language="es">Un modelo de Be-eMe-uWe</langstring> </caption> </term> <relationship> <sourceTerm>very-special-bmw-model</sourceTerm> <targetTerm vocabIdentifier="your.package.car_manufacturers">bmw</targetTerm> <relationshipType source="http://www.imsglobal.org/vocabularies/iso2788_relations.xml">BT</relationshipType> </relationship> ... </vdex> How to access relations (from code) Relations are defined by ISO2788. To get listing of BMW car models from above VDEX example you have to: from zope.schema.vocabulary import getVocabularyRegistry vr = getVocabularyRegistry() car_manufacturers = vr.get(self.context, 'your.package.car_manufacturers') car_models = vr.get(self.context, 'your.package.car_models') bmw = car_manufacturers.getTerm('bmw') bmw_car_models = bmw.related.get('NT', [])
Display members and groups
collective.workspace package for providing 'membership' in specific areas of a Plone Site. It allows you to grant people access to areas of content using a membership group rather than local roles for each user, and to delegate control over that group to people who don't have access to the site-wide user/group control panel. collective.workspace provides a behavior that can be enabled for any Dexterity content type. When enabled, it adds a "Roster" tab which is where you can manage the team. All the functionality takes place via an IWorkspace adapter, which can be overridden to specify: A list of groups, and the roles that each group should receive. These groups are created automatically via a PAS plugin, and automatically granted local roles using a borg.localrole adapter. The schema for which fields should be stored for each member in the roster. This includes checkboxes for the groups, to determine which groups the member is in. Action links for each row in the roster. The default is an "Edit" link which brings up a popup to edit the fields for that person's roster membership. Action buttons at the bottom of the roster which apply to the rows the user selects. An example of this could be a 'Send email' action, so a roster admin can easily email users in the roster. Unlike similar previous packages (see slc.teamfolder and collective.local.*), collective.workspace supplies its own PAS groups plugin, instead of using standard Plone groups. This means that Workspace-specific groups do not appear in the sitewide group control panel. Some other features are: Membership in a roster is indexed, so you can search the catalog for items of portal_type X that have a particular user in their roster. Events are fired when roster memberships are added/modified/removed.
This package provides an extension to the test runner to the one that ships with zope.testrunner, as well as a buildout recipe based on zc.recipe.testrunner to install a test script for this test runner. The test runner is identical to the one in zope.testrunner, but it is capable of writing test reports in the XML format output by JUnit/Ant. This allows the test results to be analysed by tools such as the Jenkins continuous integration server. The recipe accepts the same options as zc.recipe.testrunner, so look at its documentation for details. When buildout is run, you should have a script in bin/test and a directory parts/test. To run the tests, use the bin/test script. If you pass the --xml option, test reports will be written to parts/test/testreports directory: $ bin/test --xml -s my.package Use bin/test --help for a full list of options. If you are using Jenkins, you can now configure the build to publish JUnit test reports for <buildoutdir>/parts/test/testreports/*.xml.
Introduction collective.chat.xmpp provides instant messaging for Plone. It provides a web-based chat client, by means of Converse.js, a javascript library which makes use of the open and very popular XMPP messaging protocol. You will need an XMPP server (such as ejabberd) for the message handling. Features Manually or automatically subscribe to other users. With manual roster subscriptions, you can accept or decline contact requests. Chat statuses (online, busy, away, offline) Custom status messages Typing notifications (i.e when the contact is typing) Third person messages (/me ) Multi-user chat in chatrooms Chatrooms can be configured (privacy, persistency etc.) Topics can be set for chatrooms Full name and profile picture support (via VCards) Installation XMPP integration with Plone is provided by the collective.xmpp.core package. Please refer to its README on how to set it up. You can use the buildout at collective.xmpp.buildout. The buildout in this egg is used for development purposes. You'll need to have a working XMPP server and access to the administration account on the server. Your XMPP server will have to support the following extensions XEP-0045 Multi-user Chat XEP-0071 XHTML-IM. XEP-0144 Roster Item Exchange. XEP-0124 Bidirectional-streams Over Synchronous HTTP (BOSH) XEP-0206 XMPP over BOSH Configuration You'll need to have an administrator account on the Jabber server you'll be using. Refer to the collective.xmpp.core README for information on how to set this up. Once you've installed collective.xmpp.chat, you should go to the Plone registry in the control panel and set the XMPP Domain as well as the XMPP Admin JID and XMPP Admin Password values. Additionally you have the option Auto-subscribe XMPP users, which is disabled by default. Enable this option if you don't want your users to manually maintain their rosters (i.e subscribing and unsubscribing to one another) and would rather have everyone subscribe to everyone else. Be careful however, this might cause a lot of overhead (and therefore be quite slow) on sites with large userbases.