Closed (fixed)
Project:
Entity Print
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
26 Nov 2015 at 20:31 UTC
Updated:
24 Aug 2016 at 00:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
sgurlt commentedComment #4
benjy commentedWhy don't we generate the permissions in hook_permission() by looping over the entity types and adding a "view entity print $type" permission?
Comment #5
sgurlt commentedYeah I also thought about doing it in this way. But for me it feels like the community is more used to do it in the way I implemented it, then setting a lot of permissions. Sure with the permission way you could split it out more and set up more specific access rights, but I just didnt need this for my project :)
Another plus for my implementation is that you just have to export one varibale instead of a lot of permissions.
Anyway, if you say you wanna have this set up with permissions, I could rewrite it, just let me know.
Comment #6
benjy commentedSorry, I don't agree. Drupal provides permissions as the system to control access, I don't want to try introduce our own concept in a non-standard place.
There are already limitations in your approach, for example it cannot be controlled per role.
I think we should generate one permission per entity type and we'll also need an update hook to add the permissions to all users who have the "entity print access" permission currently.
Comment #7
sgurlt commentedHm you got me, I will rewrite the patch. Before I do this just one last question. Do you wanna have it on entity types, as it currently is, or should I break it down to entity bundles?
Comment #8
benjy commentedYeah, I think bundles would be good.
Comment #9
sgurlt commentedAlright here we go. Instead of removing the original permission "entity print access" permissions, this now is a global allow for all entity types and bundles which saved me from writting a hook_update_N().
In addition to that I added permissions for entity types and bundles. You can decide if you want to allow all bundles of a specific type, or you could choose just the bundles you want.
I hope you like it ;)
Comment #13
benjy commentedThanks!, the patch doesn't apply for some reason, are you branching of 7.x-1.x?
Also, do you fancy trying to add some tests for this?
t() supports placeholders, we should use them here.
Comment #14
sgurlt commentedYes i was using 7.x-1.x and created the patch with the PHPStorm interface and also applied it using the interface for test proposal.
It worked good in my case, strange that the patch wont apply. I will later recreate it later using the terminal.
The hint about t() is a good point, just forgot about this :). I will change this before recreating the patch.
Comment #15
sgurlt commentedAlright, patch number three.
This time created with command line git, variables for t() and "fancy" tests ;-)
Comment #17
benjy commented"Do you fancy" is an expression that means, "if you want to do it" :) I wasn't referring to the tests :)
Patch still doesn't apply, once that's done and the testbot runs i'll review again.
Comment #18
sgurlt commentedOk another test...
Ok I really dont get this, I send you a private message, maybe you can give me some help with that.
Comment #20
sgurlt commentedOk I think i found it out by my self, sorry for spamming.
Comment #21
sgurlt commentedComment #22
benjy commentedThanks for all your work on this, below is some feedback :)
Coding standards say that comments need to be <80chars in length.
Please add spaces around . to comply with coding standards.
->type doesn't always related to the bundle, use
list($id, $vid, $bundle) entity_extract_ids()I wonder if this should be called bypass entity print access now? We'd need an upgrade path then so i'm not too worried about that.
The tests are looking great, nice work. Just one suggestion, we should add some negative tests as well, e.g. Assert that a user that can view the page bundle cannot view the article bundle, and a user that can view the user entity type cannot view the node entity type.
Comment #23
sgurlt commentedAlright, thanks for the feedback. I worked on all your mentioned points (including the upgrade path), except the last one, as I already had added negative tests.
and
:)
EDIT: Forgot to adjust the permission names inside the tests... doing this now.
Comment #25
benjy commentedGreat, looking good, just one more thing.
Why do we remove this, don't we want to deny access in this case?
Comment #26
sgurlt commentedAlright, patch is adjusted.
You are right, that return FALSE shouldnt be removed.
Comment #27
benjy commentedI think this is good now, I need to apply the patch and give it a test but other than that, i'll try commit later in the week.
Thanks for all your hard work on this, appreciated.
Comment #28
sgurlt commentedSure I really liked working on that :)
What is the status of permissions for your Drupal 8 release?
Comment #29
benjy commentedThe Drupal 8 module was a straight port from D7 so it is likely pretty similar. I'd be more than happy to accept the same changes for the 8.x-1.x branch if you're want to give it a go.
Comment #30
sgurlt commentedI think I will start with it in the upcoming week.
Comment #31
sgurlt commentedComment #32
benjy commentedThanks for all your work here, i've just committed the patch. I made a few changes on commit (interdiff.txt attached), mainly just some wording to be more consistent with how the node module formats its permission strings as well.
Thanks again!
Comment #34
sgurlt commentedYou are welcome :)
I am activly working on the D8 version of that patch. Just making slow progress as I havent done so much for now with D8, but I am on it :)
Comment #35
benjy commentedOK, well feel free to ask any questions.
Comment #37
nithinkolekar commentedby default Drupal doesn't provide permission like "view own content " for authenticated user. This will grant authenticated user with permission "Use Entity Print" to generate pdf of any content and thus leads to all or none scenario. So it would be nice to have "entityprint own content" permission.
Comment #38
benjy commentedCould you please open a new issue for your described permission. Thanks!