Search results

collective.contentrules.mailtogroup-1.5-1.lbn19.noarch

s action rule allows you to send e-mail to groups and users. The groups and users are defined in the action rule, it's possible to combine both. This action was made because the current actions cannot mail to a dynamic set of users (group). Adding multiple members was also added because you don't always know the e-mail of a certain user.

collective.contentrules.mailtolocalrole-1.3-1.lbn19.noarch

Using content rules in Plone 3 it's very easy to register for certain events and perform actions upon occurrence. One of these actions provided by Plone 3 is a mail action. A limitation in the supplied mail action is that one can only provide fixed email addresses. But sometimes you'd like to send an email to a user having a certain role on the object that was involved in triggering the content rule. An examplary use case and reason for creation of this package is the reviewer role. If an object in a certain location of the site is submitted for publication, you would like to inform the user that has the 'reviewer' role on this area of the site that a new document/object is available for review. Before contentrules was available in Plone 3 the place to add this functionality was to to create a python script and attach it to the workflow 'submit' transition that was used for the objects. .. Note:: This product is superceded by `collective.contentrules.mailtorole`, which can send mail to all members having a role on the object, including global roles.

collective.contentrules.mailtorole-1.7-1.lbn19.noarch

Using content rules (available since Plone 3) it's very easy to register for certain events and perform actions upon occurrence. One of these actions provided by Plone is a mail action. A limitation in the supplied mail action is that one can only provide fixed email addresses. But sometimes you'd like to send an email to a user having a certain role on the object that was involved in triggering the content rule. An examplary use case and reason for creation of this package is the reviewer role. If an object in a certain location of the site is submitted for publication, you would like to inform the user that has the 'reviewer' role on this area of the site that a new document/object is available for review. Before contentrules was available in Plone the place to add this functionality was to to create a python script and attach it to the workflow 'submit' transition that was used for the objects.

collective.contentrules.mailtogroup-1.5-1.lbn25.noarch

s action rule allows you to send e-mail to groups and users. The groups and users are defined in the action rule, it's possible to combine both. This action was made because the current actions cannot mail to a dynamic set of users (group). Adding multiple members was also added because you don't always know the e-mail of a certain user.

collective.contentrules.mailtolocalrole-1.3-1.lbn25.noarch

Using content rules in Plone 3 it's very easy to register for certain events and perform actions upon occurrence. One of these actions provided by Plone 3 is a mail action. A limitation in the supplied mail action is that one can only provide fixed email addresses. But sometimes you'd like to send an email to a user having a certain role on the object that was involved in triggering the content rule. An examplary use case and reason for creation of this package is the reviewer role. If an object in a certain location of the site is submitted for publication, you would like to inform the user that has the 'reviewer' role on this area of the site that a new document/object is available for review. Before contentrules was available in Plone 3 the place to add this functionality was to to create a python script and attach it to the workflow 'submit' transition that was used for the objects. .. Note:: This product is superceded by `collective.contentrules.mailtorole`, which can send mail to all members having a role on the object, including global roles.

collective.contentrules.mailtorole-1.7-1.lbn25.noarch

Using content rules (available since Plone 3) it's very easy to register for certain events and perform actions upon occurrence. One of these actions provided by Plone is a mail action. A limitation in the supplied mail action is that one can only provide fixed email addresses. But sometimes you'd like to send an email to a user having a certain role on the object that was involved in triggering the content rule. An examplary use case and reason for creation of this package is the reviewer role. If an object in a certain location of the site is submitted for publication, you would like to inform the user that has the 'reviewer' role on this area of the site that a new document/object is available for review. Before contentrules was available in Plone the place to add this functionality was to to create a python script and attach it to the workflow 'submit' transition that was used for the objects.

collective.contextimage-1.3.1-1.lbn19.noarch

Provide extension fields for context specific images and markup. This elements can be used as layout elements. If the current context does not provide the specific context related field, it is aquired from its parents. It is useful i.e. if you like to have a different logo or header background on different sections of your site, if you want to set a background image for your content, if you want to place an image in context somehwere in the page using a viewlet. Separate schema extenders are provided with corresponsing renderers bound to browserlayers loaded by different profiles. This way its possible to enable only one of the several features: Viewlet context image An image which gets rendered by a viewlet as img tag. Profile is profile-collective.contextimage:viewlet. Header context image An image which gets rendered as portal header background. Profile is profile-collective.contextimage:header. Page context image An image which gets rendered as page background. Profile is profile-collective.contextimage:page. Logo context image An image which gets rendered as portal logo. This is a drop in replacement for the logo viewlet with fallback to default logo). Profile is profile-collective.contextimage:logo. Footer Viewlet Richtext which can be displayed as portal footer. Profile is profile-collective.contextimage:footer.

collective.contextimage-1.3.1-1.lbn25.noarch

Provide extension fields for context specific images and markup. This elements can be used as layout elements. If the current context does not provide the specific context related field, it is aquired from its parents. It is useful i.e. if you like to have a different logo or header background on different sections of your site, if you want to set a background image for your content, if you want to place an image in context somehwere in the page using a viewlet. Separate schema extenders are provided with corresponsing renderers bound to browserlayers loaded by different profiles. This way its possible to enable only one of the several features: Viewlet context image An image which gets rendered by a viewlet as img tag. Profile is profile-collective.contextimage:viewlet. Header context image An image which gets rendered as portal header background. Profile is profile-collective.contextimage:header. Page context image An image which gets rendered as page background. Profile is profile-collective.contextimage:page. Logo context image An image which gets rendered as portal logo. This is a drop in replacement for the logo viewlet with fallback to default logo). Profile is profile-collective.contextimage:logo. Footer Viewlet Richtext which can be displayed as portal footer. Profile is profile-collective.contextimage:footer.

collective.cover-1.0a3-1.lbn13.noarch

collective.cover is a package that allows the creation of elaborate covers for website homepages, especially for news portals, government sites and intranets that require more resources than a simple page or collection can offer. However, despite offering rich resources to build a cover, collective.cover also provides a very easy mechanism for managing its contents, built around a drag-and-drop interface. collective.cover is based on Blocks and Tiles, like Deco, the new layout composition system for Plone. Use cases Suppose you are running The Planet, a news site that has a bunch of editors focused on getting news on different topics, like Economy, Health or Sports. If you are the main publisher of the site, you may want to delegate the construction of the cover page of the Economy section to the people working on that section content, but you might not want them messing around the Sports section as well. Also, suppose you have the final game of the World Cup and the match is going to be defined on penalties: you may want to prepare a couple of cover pages and publish the right one focused on the team that won in the end. These are the kind of issues we want to solve with this package; we are still far from it, but that is the idea.

collective.cover-1.6b1-1.lbn19.noarch

collective.cover is a package that allows the creation of elaborate covers for website homepages, especially for news portals, government sites and intranets that require more resources than a simple page or collection can offer. However, despite offering rich resources to build a cover, collective.cover also provides a very easy mechanism for managing its contents, built around a drag-and-drop interface. collective.cover is based on Blocks and Tiles, like Deco, the new layout composition system for Plone. Use cases Suppose you are running The Planet, a news site that has a bunch of editors focused on getting news on different topics, like Economy, Health or Sports. If you are the main publisher of the site, you may want to delegate the construction of the cover page of the Economy section to the people working on that section content, but you might not want them messing around the Sports section as well. Also, suppose you have the final game of the World Cup and the match is going to be defined on penalties: you may want to prepare a couple of cover pages and publish the right one focused on the team that won in the end. These are the kind of issues we want to solve with this package; we are still far from it, but that is the idea.