Allow more control over votes generated using devel generate

Bug: my validation was rejecting negative values, which are used by Up/Down.

I don't see a way to delete the original attachment, but here is the corrected version:

I did some more testing today with a fresh installation. Here's a quick walk-through of the minimum steps to see what this code does:

1. Standard Drupal install
2. Install modules: Devel, VotingAPI, and a VotingAPI widget module, such as the excellent Rate module
3. Enable Devel, Devel Generate, VotingAPI, and the voting widget module
4. Configure the voting widget:
   • for the Rate module, all widget config is in /admin/structure/rate
   • other widget modules are configured differently -- see their documentation
5. Generate some users (/admin/config/development/generate/user)
6. Generate some content nodes (/admin/config/development/generate/content)
7. (OPTIONAL:)
   
   1. Generate some votes WITHOUT this update (/admin/config/development/generate/votingapi)
   2. Check the results in the "Voting Results" tab of a node (this tab is only available for Rate module widgets)
   3. The generated votes will not be shown, because the current vote generation code does not work. It does add rows to the votingapi_vote table in the database, but they're not valid and not recognized by any widgets that I know of.
8. Unzip the attachment and copy votingapi.drush.inc and votingapi.admin.inc into the votingapi folder, overwriting the original versions
9. Now generate some votes with the new code (/admin/config/development/generate/votingapi). Select the node type, vote tag, and widget type, as configured from previous steps. (Note that the Fivestar module uses different values from the Rate module's five-star widget.) If you don't see an option for the widget you chose, you can select "CUSTOM" to specify a list of values appropriate for that widget.
10. Then check the "Voting Results" tab for several nodes. You will see an interesting diversity of voting patterns that closely model the statistical properties of real votes. Each node will have a unique average, and the distribution of votes will be Gaussian, i.e. a "bell curve", if your widget has enough options for that pattern to be apparent. (That's only for "percent" and "points" value types. The model is different for "option" type widgets, such as the Emotion widget, but the results are equally realistic.)

If you have any difficulty with any of these steps, please do let me know and I'll be happy to help. I would also really appreciate any error reports or suggestions for improvements.

To be more consistent with community standards, here is the same contribution in the form of a patch.
When applied to 7.x-2.x, the result is the same as the attachment in comment #1.

Hello, interdruper. Thanks for the feedback!

I repeated the test you described, but I wasn't able to reproduce that bug. I added a Fivestar field to the Article node type, "rated while viewing", with five stars, and a vote tag of "vote". I generated 50 users and 50 Article nodes. I deleted all votes and then generated new votes with the specified criteria, using (percent: 20,40,60,80,100) values. A total of 1991 votes were generated. Then I used phpMyAdmin to examine the contents of the votingapi_vote table. I looked through all 1991 votes, and the "value" field was always correctly set to one of (20,40,60,80,100) for every vote.

The code that generates these votes first produces Gaussian distributed values (floating point) and then quantizes them into valid values:

    foreach ($this->quantization_thresholds as $i => $threshold) {
      if ($vote_value <= $threshold) {
        return $this->values[$i];
      }
    }

The quantization_threshold is the midpoint between two consecutive values. So it's basically rounding to the nearest valid value, and it can only return a valid value. In this case, the valid values specified were (20,40,60,80,100), so it cannot return any other value.

The votingapi_cache table contains the calculated results of the aggregate function ("average" for percent value types), and those do have floating point values. Perhaps that is what you observed? Or maybe a Views listing of the same aggregate data? If not, can you please tell me where you found these invalid values?

Regarding your suggestion to release this as a separate module: Voting API already provides a feature to generate votes, but it is very buggy and incomplete. To me, it makes sense to include this "fix" and improvement to this existing feature in Voting API. But I don't know all of the community protocol, so if others suggest that it should be a separate module, then I will do that. I would also like to hear from the maintainer, torotil, about this.

Thanks for the update on the bug report.

Thanks also for your input on releasing this as a separate module. Those are some good points. You are right, it is a very big patch that addresses multiple issues, which could make it difficult to review properly. On the other hand, it is only intended for development testing, not production use. I sent an email to the maintainer of Voting API to get his input too. I will make a decision after I hear back from torotil.

Thanks for the feedback. I want to be sure I understand your suggestions.

> What's the reason for bundles being limited to node types?

I had to research bundles just now. I guess I didn't understand that concept before. So the node type is actually a node-specific form of a bundle type? Instead of node_type_get_names(), is there a corresponding function that would provide the same kind of information, but generalized to all entity types, instead of just node? I looked for this, and I think it would be field_info_bundles($entity_type). Correct me if I'm wrong about that. Otherwise, I'll go ahead and extend support to the bundle types of all entity types.

In the options array, I'll replace node_types with bundle_types. In the UI, I'll set the input label to use the name of the selected entity type, to avoid confusing users. E.g. "SELECT NODE TYPES" or "SELECT USER TYPES", instead of "SELECT BUNDLE TYPES". In the case when there is only one bundle type I will hide that input. Does that sound okay?

> There is still some places where node_type and entity_type are mixed.

I don't know what you mean by this. Can you please refer to a specific line of code that has this problem?

> I'd prefer to modularize votingapi_generate_votes() somehow.

When you say modularize, do you mean that it should be possible for other modules to extend the vote generation with custom functionality?

> I'd rather split it into a series of smaller patches.

That's understandable, but I have to be honest, it seems like that would be a somewhat challenging and error-prone process. I'm still open to consider it, if you can suggest a feasible approach to segmentation. But perhaps interdruper's suggestion to roll it into a separate module could provide a simpler path forward, to allow it to be tested and improved in a more holistic manner. Perhaps then, after its quality reaches an acceptable level, we might find a way to integrate that module into a future release of Voting API. Does that sound reasonable?

Thanks for the detailed guidance. I guess you're right, that should be easy enough. It would make sense to approach the modularization and segmentation at the same time. Basically just refactoring, submitting one piece at a time. The challenge would be to keep cohesive functionality in each patch. So I'll start with the back-end (drush code), and preserve the interface from the old UI, at least temporarily.

When I break out useful chunks into utility functions, do you think some of those should be exposed as part of the API? Specifically, being able to delete votes by criteria could be useful to other modules. I guess we can work out the interface for each function whenever it's determined to be generally useful.

I was thinking, since content generation is actually part of the Devel module, and since the new vote generation code is fairly complex, it might make sense to separate it into a new file, votingapi.devel.inc. What do you think about that?

When I submit each patch, should I post them to this issue, or create a new issue for each one?

> I can give you commit access to votingapi

I'm still learning to work with Git, so I'm somewhat hesitant about that. I know you can revert any mistakes I might make, but is it possible to restrict my access to a specific branch, so I don't have to worry about accidentally committing to the wrong branch or something?

I'll have to study the 3.x branch so I can rewrite this in an easily portable way...

> we can also coordinate the effort via email

Sure, I'll send you an email with my contact info.

added link to admin UI

The way I wrote it, each user has an 80% chance of voting on each node. So you can control the number of votes generated by the number of users in the system. I know that's not ideal, but it's still much more useful than what you get without this patch.

These days I'm doing most everything on the client-side, with a very thin layer of authentication and validation on the back-end. Voting calculations still belong on the server, but I prefer a more light-weight solution for that. So I'm not able to support any revisions to this patch.