Ok, just created the 2.x branch. No work on it yet.

Wanted to get feedback on changes for 2.x branch. So let me know what you think of these and also other ideas you have.
Also if you are working on modules or other custom code that integrates with Entityforms let know of internal changes that would make that work better.

Changes

Remove Rules dependence

Probably make a entityform_rules submodule that would have all the current functionality.
New module Entity Rules will take care of current functionality(and will work for any Fieldable entity type).

Reference only for Entityform Types

Add option to restrict submitting a particular Entityform Type to only work when it is used as Entity Reference. This would make it possible for Entityform Nodes module to restrict the viewing of the Entityform Type to only work when it is shown with the node(no direct url to the Entityform Type submit page).

Handle Anonymous Users better

Right now anonymous submissions aren't tracked to the session at all.
This could be done to enforce the "Resubmit Action" for anonymous users(though won't be perfect).

Possible Changes(not likely)

Remove View Dependence

Someone suggested this so just putting it out there. Would then have to make a sub-module EntityForm Submissions Listings(or something) which would provide the current views for submissions Viewing. Moving forward to Drupal 8 this is probably not important because Views will be in core anyways.

Add Entityform Nodes submodule

This would create a Node Content type that has a Entity Reference to an entityform type.
It seems like this is the way a lot of people are using the module. This could also be done as a separate module which might speed up the release of Entityform 2.x(if entityform nodes didn't have to be finished).

Other Related Issues

#1893332: Display summary page (aka review) before submission
#1864248: Remove Rules requirement
#1848018: Add i18n support for Label and other property translation (+ entityform name)
#1973954: Create "Preview Form" admin tab

All active, needs review, needs work, rtbc issues for 2.x

Postoned

#1546270: Integrate with Panelizer

All issues tagged entityform-2.x feature

There are probably other changes I will add to this but just wanted to get the conversation started.

Comments

Kristen Pol’s picture

My 2 cents:

1) Remove Rules dependence - I think this is a good idea since not everyone uses Rules. You will likely get more interest this way.

2) Add Entityform Nodes submodule and Reference only for Entityform Types - Could you provide some use cases for these? I'm not sure I see the advantage of this sub-module and restriction.

3) Remove View Dependence - I would vote "no" on this one. I've never seen a site without views so I don't think it's worth the effort.

DamienMcKenna’s picture

Upgrade path for Webform?

tedbow’s picture

Upgrade path for Webform?

@DamienMcKenna, couldn't you think of something a little harder? ;)

I think converting Webform Components to Fields would be pretty hard. I think if this something that was really needed then it would better in a separate module. That way it wouldn't have to hold up the release of Entityforms 2.x.

If it was done as separate module, "Webform to Entityform"(W2E or something) it should be dependent on a another new module, "Webform Component to Field"(WFC).
That way other modules or custom code could use WFC to convert Webforms to other entities, Content Types or Profile2 Types, etc.

This would probably only work with simplier Webforms and because there are so many modules that integrate with Webforms it would probably be just geared to base Webforms module.

DamienMcKenna’s picture

My idea is that the converter would first compare the set of components used in the form and indicate whether the specific webform would be convertible or not. But yeah, a separate module might be the better way to go.

tedbow’s picture

Maybe it should a separate issue. If you or someone else is interested in taking this on I would be interested in helping.

gmclelland’s picture

I haven't used Entityform in while so I don't know if this already has this feature. The file_entity module just added integration with the http://drupal.org/project/admin_views module. See http://drupal.org/node/1256946#comment-6952000.

Maybe Entityform could add this kind of integration to provide Bulk Operations with Views Bulk Operations? They did it without any dependencies on Views Bulk Operations or Admin Views modules. - Just a thought

tedbow’s picture

@gmclelland, interesting. I am not sure would be possible b/c I want the Entityforms Type editor to be able to just switch submission Views per EntityForm type without having to have access to the Views UI etc.

Right now there is VBO integration if the module is enabled but the Views will still work if VBO is not installed, not a dependency.

chapsou’s picture

chapsou’s picture

Issue summary: View changes

added related issue

DamienMcKenna’s picture

@chapsou: Do you mean that you would like EntityForm to create content types instead of its own entity system? That won't happen, the whole point of building it this way was to have a separate, non-node system.

chapsou’s picture

yes i need that my entityform works like a node in order to use it with apache solr and because i'll need to change the user id attached to it.
Maybe you can advice me another issue ?

DamienMcKenna’s picture

@chapsou: I suggest opening support request issues for each of the things you are trying to do with EntityForm (search indexing, etc) and then people might be able to help you work out some solutions; this discussion is off-topic for this issue.

tedbow’s picture

Remove Rules dependence

Probably make a entityform_rules submodule that would have all the current functionality.
That way people could use Entityforms if they didn't want to install Rules and didn't need any of the Rules functionality. Probably have notices in the current settings to say "Enable Entityform Rules to ....."

I am working on new module that will allow taking out the Rules dependence of the this module

Entity Rules allows triggering of Rules components on entity events, i.e. create, update, delete. It will also have Validation and Access events for modules that provide info about their entity add/edit forms.

This will basically allow the current functionality of triggering Rules but from a separate Rules tab for each bundle.

It is a work in progress right now but you can try via git clone.

Shawn DeArmond’s picture

Maybe I should file this as a separate "Support Request" issue, but I'd like to find a way to control access to the submitted values. That is, beyond "view own submissions" and "view any submissions".

For my particular use case, I would like to use Organic Groups to control who can see submissions. I know I can add a "groups audience" field to the entityform, but I don't know if that controls anything other than the relationship. I'm also interested in integrating State Machine module for a workflow-like approval process.

The combination of OG access and State Machine access is likely to drive me mad, but if there was an easy integration module, that would certainly help.

Does the submitted values have any sort of access system, perhaps similar to the node access system?

Thanks!

tedbow’s picture

Does the submitted values have any sort of access system, perhaps similar to the node access system?

No there is no advanced access system. I don't think this would be added. The problem gets into recreating all the features that the Node system has. This module is geared towards entityform submissions not being "content".

If someone finds another contrib module that implements an entity access api I would consider integrated support but I don't think it should be created by this module.

1 option would be to add a drupal_alter call in entityform_access. So that any module could alter access. Workbench Moderation does something like this. But I don't think this would effect access in Views.

DamienMcKenna’s picture

+1 for not including this in the main module but consider helping (hook implementations if needed) another module to expand to cover entityform entities.

Shawn DeArmond’s picture

A hook in entityform_access would be a good start.

If it isn't obvious yet, I'm trying to utilize this as a form submission/approval process, using OG as the admins who can approve for forms submitted within their group. The access logic gets a little intense. I can build the Views simply using relationships, but I need to grant people access to view the form submission based on a number of parameters.

Shawn DeArmond’s picture

I created another issue for a feature request: #1937526: Extend submission access system

Shawn DeArmond’s picture

Issue summary: View changes

added anonymous user section

tedbow’s picture

Issue summary: View changes

added linked to new issue

tedbow’s picture

Ok, I have started working on 7.x-2.x. Removed all references to Rules for a start.

See #1864248: Remove Rules requirement

tedbow’s picture

Issue summary: View changes

added Entity Rules reference

tedbow’s picture

Moved Entityform Nodes submodule - to Not Likely. This could be done in another module

tedbow’s picture

Reference only for Entityform Types

Add option to restrict submitting a particular Entityform Type to only work when it is used as Entity Reference. This would make it possible for Entityform Nodes module to restrict the viewing of the Entityform Type to only work when it is shown with the node(no direct url to the Entityform Type submit page).

I am thinking this feature could be changed to "Provide Submit Page" which would default to true.

The benefit of setting this to FALSE would be that you could link it to a node(or other entity) via Entity Reference and then access to submitting the Entityform could be totally controlled by access to the Node which can have more complex access control.

Any thoughts?

tedbow’s picture

Regarding #13 to #18

I have a patch in #1937526: Extend submission access system

That adds hook_entityform_access_alter and needs review.

tedbow’s picture

Issue summary: View changes

moved Entityform Node section

tedbow’s picture

Issue summary: View changes

Removing clone issue b/c is Entity API issue

tedbow’s picture

I am looking for help on this issue #1848018: Add i18n support for Label and other property translation (+ entityform name)

If I could get some help then i18n support could be added for all entityform type text properties.

tedbow’s picture

Issue summary: View changes

add i18n issue link

tedbow’s picture

tedbow’s picture

Issue summary: View changes

Updated issue summary.

tedbow’s picture

Issue summary: View changes

Move issue to postponed

tedbow’s picture

Ok I have update the issue summary.

Thing are getting close.

Here are all remaining issues

So you are interested in geting a 2.0 alpha take a look at these issues.

tedbow’s picture

I re-wrote Entityform Notifications.

It is basically not just exported Rules that work with the new Entity Rules module.

The Rules use the module Entity To Text module to include in the submission data in the emails.

I also took the tokens logic from Entityform b/c it is now Entity To Text(and works with any entities).

joachim’s picture

> Right now anonymous submissions aren't tracked to the session at all.

One way to do this might be with Session API. It's what Flag uses to keep track of anon flaggings (though it's not perfect).

tedbow’s picture

@joachim, thanks for the tip about Session API.

Maybe we should use it if it is installed but not a make it a dependencies. I am trying to limit dependency.

My idea is to have some sort of Anonymous user tracking setting. Then if the Session API is not enabled just provide a notice that it need to track anonymous users.

I don't want to make it a dependency b/c nobody has actually asked for this feature(maybe shouldn't be added at all?).

joachim’s picture

> Maybe we should use it if it is installed but not a make it a dependencies

That's also how Flag does it.
Basically, with Flag, anon users using flags is only possible if Session API is present, since tracking of anon users is a requirement. You wouldn't need to be so draconian here.

DamienMcKenna’s picture

I've started a new issue for the upgrade process: https://drupal.org/node/2087691

DamienMcKenna’s picture

Issue summary: View changes

add link to active issues

tedbow’s picture

@joachim and anybody interested in anonymous submission tracking.

I am going to postpone this because nobody has ever asked for this feature or complained that it wasn't there.

It probably shouldn't be to hard to do in another contrib module especially now that we have an alter hook for submission access(to stop an anonymous user from submitting 2x).

tedbow’s picture

Final issue before the release of 7.x-2.0 #2134619: Upgrade process for upgrading Rules from 1.x to 2.x

gmasky’s picture

Are the following covered in version 2.x or how can I achieve them.

1. When a user submits an entity form it is not published. An admin needs to approve before it is published.

2. Check for and disallow duplicate entries by email address like core Drupal does.

Thanks

tedbow’s picture

@gmasky for #1 Entityform Submissions don't have a "published" property. If you need that you should think about using nodes.

#2 you would have to do my Rules or Custom code. but this would be a separate issue.

gmasky’s picture

Thanks @tedbow

#1 my problem is each submission is displayed in a view directly without any moderation. I was thinking there may be a way using rules to have the submission in an un-published state.

#2 I will check on doing this with rules and report back

DamienMcKenna’s picture

EntityForms can be marked as "draft" which should accomplish the same thing.

gmasky’s picture

@ DamienMcKenna I thought the draft format was relevant for the person filling up the form. Am I understanding this correctly? It would be ideal for me if a submitted form is saved as a draft and then an admin can activate the draft.

Thanks

tedbow’s picture

@gmasky can you make a separate issue if you want support on this? This is not what this issue is about.

Also do a search in the issue queue first I know some other people had similar questions.

Thanks

tedbow’s picture

Ok someone needed anonymous user tracking and was able to fund the development.

I am working in another branch and it will probably be a submodule. You can read about it here:

#2181691: Allow Anonymous users to edit Entityform Submissions

Any help testing would be great!

nithinkolekar’s picture

-1 for entityform nodes b/c this can be achieved, in not more than 2 min by creating new content type which has entity reference to entityform :).
Update: I was happy with manual way of attaching entityform to node until I came through the situation like described in the issues Add scope to Resubmit action when entityform is submitting via node.I think this can be added to entityform nodes submodule.

If is already on the way then small feature request for this module:
Hide whole node and display login form instead just hiding entityform ER field(Currently showing node title , body fields and hiding entityform) when anonymous user doesn't have permission to submit entityform.Simple redirection is also enough.

tsvenson’s picture

Just found this module and instantly saw many potential use cases for a project I am working on. However, when I scrolled down the project page, the Requirements section sad it needed Rules 7.1.x.

I think it would be a good idea to be more verbose about the changes in the 2.x version there as it initially got me wondering if this was a stalled project. Glad I found out it isn't. Just thought to give this feedback, to make the project page more clear about it.

tedbow’s picture

@tsvenson thanks for the feedback. Yes Rules is not necessary for 2.x unless you are using Entityform Notifications.

The project page and documentation could use updates. I would appreciate any help on docs and if someone has better wording for project page they can create an issue with the text.

Thanks

tsvenson’s picture

@tedbow Would love to help out, but it wont be until several months, or even next year, until I get to the stage of the project where this module comes into play.

For now I just have time to keep an eye on the progress, which in itself is an itching problem since there are way too many Drupal modules with great potential out there. Actually so many I have to fight, especially my procrastination, to not get drawn into playing with them to early ;)

maximpodorov’s picture

Maybe #2114649: Presubmission rules could be a usable addition.

briancoffelt’s picture

Status: Active » Closed (works as designed)

Issue is six months old, open if still needed.