Customizing fields - Fieldable entities in D7

You can customize the fields you use.

There are 2 steps:
1/ Customize the fields to be allowed sitewide at admin/settings/petition
2/ Customize the fields to display on the petition and those you want to be required (advance settings on the petition form)

Please note : the email field is always required. The petition always send an email to the petitioner and the signature has always to be confirmed by a click on the link.

There must be a misunderstanding.

On the picture, you are using another module to add fields.

In the current Peition module, you only have a limited possibility:

1/ First set up the general settings at admin/settings/petition
See the attached picture below :SiteWidePetitionSettings

2/ Edit the fields you want to show on the petition on the edit form
When you create the form, click on "advanced settings" and choose the fields you want to include.

This means you only have a limited set of possibilities.

If you are not please with the name of a field, you can use the locale module to translate a specific term to a custom vocabulary

Is this module compatible with CCK? That would be the easiest way to do this, I imagine: hook it into CCK. You can see additional information about CCK for developers here: http://drupal.org/node/101742.

Hmmm... actually it looks like this module is providing some kind of webform integration which will work nicely! See line 59 in the petition module...

There are 2 modules to distinguish:

CCK and webform

CCK enable to add fields to a node object.
webform enables to create a node with a customized designed form that can be used the users.

You can use CCK with the petition module:
For instance, you can add a image field to include an image on the petition node.
However, you cannot add a signature field with CCK,

Webform module:
This enables to create customized fields on a form, which is appended to a node.
The same structure could be used for the petition module.
At the beginning, I even tried to start this way, but it became to complex and I wanted to be ready fast.

That why there is a hint left to webform (bad clean up)

In any way, the petition module is as it is now and I won't change it at the moment as it would impact a lot the table structure.

When the module is upgraded to Drupal 7 and the new Webform module is available for Drupal 7, I may consider hook into the webform module to enable the add of customized fields.

@Vako,

Sorry, but I won't contribute the webform module. Adding this feature to the rest of webform not only require a perfect understanding of how this module works, but also how this module is meant to be.

This would require quite a change in the current tables and logic of this module and I think you should ask the webform project owner.

I want to contribute to the module:

there is the module http://drupal.org/project/content_profile, which offers the option to choose a content-type as profile.

Similar could be done with the signature fields.
The advantages are:

- every maintainer can create and edit fields
- the order of the fields can be changed very easy
- access control is very granular possible: for nodes and for fields
- signature display can be replaced by a view
- easy creation of own signature lists like last 10 signatures ... with views
- will shrink the sourcecode of the module to half or even a third of the actual size

- very drupalish ;-)

- and as you mentioned: kind of basis to upgrade to D7

So what do you think?

Are patches welcome to go this direction?
(i don't want to write the patch only for myself - then it easier for me to change the module the way i need it)

best
Thomas

Hallo Thomas,

I was myself thinking to move to a CCK approach when doing the upgrade to D7.
Same way as the Signup module.

However, this does not let the possibility to customize the signature fields, or display signatures in a view.

I really have it difficult to understand how you plan to do.
For me, a customizing of signatures fields requires an approach similar to webform, which, is not problem free when it deals with the integration with view.

If you come with a patches, I suggest they are used to build a .2 version.

But please enlight me on the main principles to change (database deisgn, the other module to interact with).

With Best

subscribing...

@ Gauvain

Thank you for this great module!I would like to know wheter it's possible to disable some fields on the create petition form for specific user role. I'm developing a site for public administration and I need that only the admin could manage and visualize some field such as campaign parameters, activating and inactivating signature forms. Do you know how I could manage this?

Best regards,

Alessandra

@Vako thank you very much for your suggestion. Unfortunately field permission doesn't work with petition module :-(.Do you know other possible solution?

Came here after realizing some petition projects.

We're right in the middle of petition_node, webform and node+cck...

Indeed meanwhile webform adds views support with Version 3.x. Also adding own fields right hit the core use case. However submissions are very limited and many features are missing.

Using nodes as submissions with cck as fields would add general drupal typical node-type extensibility. Views support is native, cck fields (or fields in d7) allow flexible lists and extensibility. We might want to use flags and other tools to extend submissions.
If you look at forum, they use the core taxonomy feature to group threads (submissions) into forums (campaigns). This architectural difference should also be considered.

However still missing is something like submission/email validation. If you want to have a one-form-submission (no separate user registration) this feature is not directly available.

We're currently doing further research, which module and further application development will cover all of our usecases.
Currently we expect that using nodetypes for submissions (allowing to use custom cck fields, similar to content_profile), views for lists, and adding petition_node features like submission/email validation would be the most flexible solution with minimum implementation overhead.

Instead of reimplementing the concepts of fields, introducing own primary entities i strongly vote for building something like "petition tools" to reuse other modules and have configurable drupalish building blocks.

If you're interested in supporting this module rewrite (next major release?) then we might take the ball and start this project. If you object to this concept we consider building a new module with petition_node features for the cck setup.

Also note that the most simple and architecturally correct next generation drupal 7 approach might be different with fields in core.

Field names at the very least really need to be customizable.

Why have a field labeled "Other (activity, status, etc?)" - obviously this is the kind of thing you want to be able to customize. "Town" and "surname" don't really work for most americans, either. I went into the petitions.module file and manually changed the names but that's definitely less than ideal.

Recent discussion with Thomas Zahredding favorizes a petition and subscription nodetype(s).
We want to focus on reuse of other modules and implement generic functionality (support also e.g. rules).
The internal features should be reduced to a clean limited set providing the core mechanics.

We're currently specifying the solution we focussing and are open for further inputs.

subscribe

Since Drupal 7 is becoming more near every day i think this feature won't be implemented in D6 + cck architecture ever.
The only future proof concept will then be fieldable entities and i think this would make perfect sense.
Sorry there's no D7 version to choose so sticking with 6.x.

If someone is ready to chime in, feel free to join us.