Search results

collective.usernamelogger-1.2-2.lbn25.noarch

Log user names when using cookie authentication in Zope/Plone.

collective.vdexvocabulary-0.1.2-1.lbn19.noarch

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', [])

collective.vdexvocabulary-0.1.2-1.lbn25.noarch

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', [])

collective.whoiswho-1.0-1.lbn19.noarch

Display members and groups

collective.whoiswho-1.0-1.lbn25.noarch

Plone addon that provides read-only views which display all groups, the members per group and the member's details. The views are made available to the user through a link in the user's menu (iow, a user action).

collective.workspace-1.1-1.lbn19.noarch

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.

collective.workspace-1.1-1.lbn25.noarch

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.

collective.xmltestreport-1.3.1-1.lbn13.noarch

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.

collective.xmltestreport-1.3.4-1.lbn25.noarch

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.

collective.xmltestreport-1.3.4-1.lbn25.noarch

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.