Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
There need to be two default administrative views:
- A view of content that contains a voting field
- 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. :)
Comment | File | Size | Author |
---|---|---|---|
#13 | Add_default_administrative_views-2832581-13.patch | 40.94 KB | JordiK |
Comments
Comment #2
dercheffeAnd it would be good, if the admin is able to reset/delete some voting results via this views.
Comment #3
pifagorComment #4
RomixuaComment #5
RumyanaRuseva CreditAttribution: RumyanaRuseva at FFW commentedEven 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.
Comment #6
TR CreditAttribution: TR commentedI 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!
Comment #7
JordiK CreditAttribution: JordiK commented+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...
Comment #8
pifagorHi.
@JordiK
No. According to the GDPR, we do not use IP.
We should use
getCurrentIp
Comment #9
JordiK CreditAttribution: JordiK commentedHere 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.
Comment #10
TR CreditAttribution: TR commentedMuch 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.
Comment #11
JordiK CreditAttribution: JordiK commentedHere is the new patch. I also made all columns in both views sortable.
Comment #12
TR CreditAttribution: TR commentedI 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.
Comment #13
JordiK CreditAttribution: JordiK commentedUpdated 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.
Comment #15
pifagorComment #16
JordiK CreditAttribution: JordiK commentedIf 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: