There need to be two default administrative views:

  1. A view of content that contains a voting field
  2. A view of the results for an individual piece of content

Without those the module is only useful to someone who knows how to use a database. :/

Shouldn't be hard, it's just config after all. :)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tkoleary created an issue. See original summary.

dercheffe’s picture

And it would be good, if the admin is able to reset/delete some voting results via this views.

pifagor’s picture

Issue tags: +epam-contrib-2018
Romixua’s picture

Assigned: Unassigned » Romixua
RumyanaRuseva’s picture

Assigned: Romixua » Unassigned
Status: Active » Needs review
FileSize
40.39 KB

Even though it's easy for everyone to create the view, I believe it will be nice to have a default one on module install.
Here is a view with two display pages:
- /admin/content/votes with a list of all votes and exposed filters.
- /node/%node/votes with a list of votes for the selected content.

TR’s picture

I really like this feature, and the patch still applies and works. Several comments:

I think there should be a link to this View from somewhere, so that people can find it. Maybe from the Voting API help page, maybe from the Voting API configuration settings, maybe on the admin/reports page - but there should be a link somewhere, because right now the only way to find this information is to to to admin/structure/views and click on the link for the "Votingapi Votes" View. That's not real friendly or helpful.

The exposed filters need work. Right now if you want to filter by user you need to enter the (integer) user ID rather than the user name. That's not helpful. Likewise if you want to filter by the voted entity you need to enter the entity ID rather than the entity title. Again, not helpful IMO because the View only displays the entity title, not the ID.

Also, the "Vote source" filter doesn't seem to work at all, or at least I don't know what I need to enter here to get it to filter by vote source.

Again, I REALLY would like to have this, so any feedback as to what should be done to address the above comments would be appreciated!

JordiK’s picture

+1 for this feature.

As in #5:
The list of votes can go into a tab at admin/content (just like comments or files). A link to this path can be added at /admin/config/search/votingapi too.
The second one - /node/%node/votes should be added as a tab on the entity page.
Although it should be noted, that most of the modules, which provide votingapi widgets (e.g. rate) already define such a view.

And I guess, that Vote source should be the voter's IP...

pifagor’s picture

Hi.
@JordiK

And I guess, that Vote source should be the voter's IP

No. According to the GDPR, we do not use IP.
We should use getCurrentIp

JordiK’s picture

FileSize
40.98 KB

Here is an update to the previous patch.
The exposed filters work now - I changed all the operators on text inputs from "Equals to" to "Contains" - now you can enter part of the string as criterion.
The search of Entities and Users (Voted entity and Authored by) required a relationship, which was added. Now entities are searchable by their title, Users by username or name.
Renamed a couple of columns (Authored by to Voted by).
When you import the view (or install Votingapi) and rebuild the cache, the views can be found at the paths stated in #5.

Please review.

TR’s picture

Much better!

Can you add a reset button for the exposed filters? That will make it easier to use. Edit the view and check the box under Advanced/Exposed Form/Settings

Also, remove the _core: key from the config - you have to do this manually.

JordiK’s picture

Here is the new patch. I also made all columns in both views sortable.

TR’s picture

Status: Needs review » Reviewed & tested by the community

I re-imported it and tried it out and it works as expected. I tested access from anonymous and authenticated users, I tested the sorting on all fields, and I tested the searching on all fields. Maybe add a description, which is used in the list at /admin/structure/views? That's not required, but it's a nice touch.

#2 asked about a delete operation. I think that would be useful, BUT it should require a new permission IMO. I see that as out of the scope of this current issue so it shouldn't be added right now. If the delete feature is something people want then we can discuss the details in a new issue.

JordiK’s picture

Updated the description.

This one can be committed without impacting any other ongoing work, as the patch creates one new views configuration .yml-file.

I had some thoughts about deleting votes and I would not allow it through the UI at this stage. It can be done anyway if necessary - on DB level, for example.

  • pifagor committed 1f6acb2 on 8.x-3.x authored by JordiK
    Issue #2832581 by JordiK, RumyanaRuseva, TR, tkoleary, pifagor, Romixua...
pifagor’s picture

Status: Reviewed & tested by the community » Fixed
JordiK’s picture

If you would like to hide the "Votes" tab on nodes because you use another module to show the results (e.g. Rate) do the following:

  • open the view "Votingapi Votes"
  • go to the display "Entity Votes"
  • disable the display "Entity Votes"
  • save the view

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.