-
ftw.jsondump-1.1.0-1.lbn25.noarch
ftw.jsondump provides JSON representations for Plone objects. By using adapters the
JSON representation can easily be customized.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
ftw.jsondump-1.1.0-1.lbn25.noarch
ftw.jsondump provides JSON representations for Plone objects. By using adapters the
JSON representation can easily be customized.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 25
-
ftw.lawgiver-1.4.0-1.lbn19.noarch
Motivation
Developing and maintaining complex Plone workflows is a time-consuming and cumbersome endeavor. Dozens of permissions need to be managed for different roles and different workflow states. Usually, this has to be done directly in the ZMI of Zope by selecting or unselecting thousands of checkboxes. This process has been shown to be very tedious and prone to errors. Furthermore, it is no simple task to document the workflow and the associated design decisions which led to the resulting configuration of permissions and roles. The extension or adaption of an existing workflow becomes very difficult, leading to workflows which are barely maintainable.
Another problem poses the communication between workflow integrator and customer. The security system of Zope is based on a role-based access control (RBAC) which is intrinsically complex due to its use of roles, permissions, and workflow states. Experience has shown that these security concepts can be hard to convey to customers.
How it works
ftw.lawgiver helps solving these problems by using a DSL to describe how a workflow should work. The lawgiver then generates the complete workflow definition (definition.xml) based on this specification. By separating this specification from the resulting workflow definition (which is in XML) the specification does not have to use permissions--handling the permissions is the job of the lawgiver.
Using the specification file the workflow can easily be regenerated at any time and will handle additional permissions automatically when regenerated. However, it is still the task of the developer to regenerate the definition.xml when more or other permissions have to be managed. He or she have to make sure that the workflow is properly installed with an upgrade step / reindexing security.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
ftw.lawgiver-1.4.0-1.lbn25.noarch
Motivation
Developing and maintaining complex Plone workflows is a time-consuming and cumbersome endeavor. Dozens of permissions need to be managed for different roles and different workflow states. Usually, this has to be done directly in the ZMI of Zope by selecting or unselecting thousands of checkboxes. This process has been shown to be very tedious and prone to errors. Furthermore, it is no simple task to document the workflow and the associated design decisions which led to the resulting configuration of permissions and roles. The extension or adaption of an existing workflow becomes very difficult, leading to workflows which are barely maintainable.
Another problem poses the communication between workflow integrator and customer. The security system of Zope is based on a role-based access control (RBAC) which is intrinsically complex due to its use of roles, permissions, and workflow states. Experience has shown that these security concepts can be hard to convey to customers.
How it works
ftw.lawgiver helps solving these problems by using a DSL to describe how a workflow should work. The lawgiver then generates the complete workflow definition (definition.xml) based on this specification. By separating this specification from the resulting workflow definition (which is in XML) the specification does not have to use permissions--handling the permissions is the job of the lawgiver.
Using the specification file the workflow can easily be regenerated at any time and will handle additional permissions automatically when regenerated. However, it is still the task of the developer to regenerate the definition.xml when more or other permissions have to be managed. He or she have to make sure that the workflow is properly installed with an upgrade step / reindexing security.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 25
-
ftw.mobilenavigation-1.4.6-1.lbn19.noarch
This product helps to create a responsive design. There are following mobile_buttons in portal_actions defined:
Toggle personaltools (default personaltools)
Toggle searchbox (default searchbox)
Toggle special navigation (special navigation, using AJAX to expand children)
Navigation types
You can choose between:
Expandable navigation (install profile default)
Sliding navigation (install profile slide navigation)
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
ftw.mobilenavigation-1.4.6-1.lbn25.noarch
This product helps to create a responsive design. There are following mobile_buttons in portal_actions defined:
Toggle personaltools (default personaltools)
Toggle searchbox (default searchbox)
Toggle special navigation (special navigation, using AJAX to expand children)
Navigation types
You can choose between:
Expandable navigation (install profile default)
Sliding navigation (install profile slide navigation)
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 25
-
ftw.profilehook-1.0.0-1.lbn19.noarch
ftw.profilehook provides a hook for executing custom code after a generic setup profile is installed.
Motivation
We often use import steps for executing code after import a generic setup profile. Registering a lot of setup handlers is bad because it extends the import duration of every profile and the amount of import steps are limited in generic setup, causing bad effects when exceeded. Import steps are meant to import things from any profile, not for executing code after importing a specific profile. Because of these reasons ftw.profilehook exists and provides an easy method to solve this issue.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19
-
ftw.profilehook-1.2.1-1.lbn25.noarch
ftw.profilehook provides a hook for executing custom code after a generic setup profile is installed.
Motivation
We often use import steps for executing code after import a generic setup profile. Registering a lot of setup handlers is bad because it extends the import duration of every profile and the amount of import steps are limited in generic setup, causing bad effects when exceeded. Import steps are meant to import things from any profile, not for executing code after importing a specific profile. Because of these reasons ftw.profilehook exists and provides an easy method to solve this issue.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 25
-
ftw.publisher.core-2.3.3-1.lbn13.noarch
The ftw.publisher packages provide tools for publishing plone contents from one instance to another.
This package provides shared tools and utils used by ftw.publisher.sender and ftw.publisher.receiver.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
ftw.publisher.core-2.3.3-1.lbn19.noarch
The ftw.publisher packages provide tools for publishing plone contents from one instance to another.
This package provides shared tools and utils used by ftw.publisher.sender and ftw.publisher.receiver.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 19