Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Hey, I would like to let my users send a newsletter but not create new newsletters types (terms).
I can set perm to send. But then users cant see Sent and Not sent newsletters lists.
So I need to enable administer newsletters perm.
Then is ok, but - List, add and edit newsletter series. - is also available.
How can I show Sent and Not sent lists to those who have perm to send without letting them creating and editing newsletter types ?
Thanks
Comments
Comment #1
Simon Georges CreditAttribution: Simon Georges commentedNo new feature will be added to 6.x-1.x.
I suppose we could add a "list newsletter issues" permission.
Comment #2
Simon Georges CreditAttribution: Simon Georges commentedMoving all feature request to 7.x.
Comment #3
amonteroThis is because of 'administer newsletters' permission granting access to both:
- admin/content/simplenews -> The 'Newsletters' tab in the content overview page
- admin/config/services/simplenews -> The Configuration->Web services->Newsletters menu
I added a new 'administer simplenews categories' permission to check access to 2nd item. Now 'administer newsletters' permission only grants access to newsletters issues tab in content overview.
Comment #4
amonteroComment #6
amonteroUpdated tests.
Comment #8
amonteroUpdate tests, coding standards compliance.
Also added permission in commented code, 'just in case' anybody trips on it later :)
Comment #9
amonteroComment #11
amonteroUpdate tests, coding standards compliance.
Comment #13
amonteroUpdate tests, coding standards compliance.
Comment #15
Berdir#13: simplenews--794180-add--administer-simplenews-categories--permission-13.patch queued for re-testing.
Comment #16
BerdirThanks for working on this. The failing test is one that happens sometimes, just trigger a re-test and it should go away.
The problem is that Simplenews 7.x-1.x is now stable and with that comes the question what can be added to stable releases and what not. The additional t() strings aren' a problem, they're backend stuff and it's easy to update translations now using l.d.o.
However, what we probably should add is an update function that gives existing roles on existing sites the new permission if they have the old one, to avoid changing the module behavior there. Possibly with a short message informing the admin that he might want to uncheck those permissions.
Also, we need to check how this affects 7.x-2.x. We're changing the naming there, newsletter is actually a newsletter list/category and a single node is a newsletter issue. So a 7.x-2.x patch could possibly do the opposite of this one and add a separate permission for newsletter issues.
Comment #17
amonteroHi, Berdir.
Thanks for your prompt response.
I've been banging my head for a good time trying to figure out what was wrong with the tests, good to know. Too bad I can't help with the test to sort what makes it fail sometimes.
Agree about update hook is needed. Will work on it.
As long as 7.x-2.x concerns, I think on naming permissions right at this point will ease upgrade path when 2.x becomes stable. However, changing permission naming in 1.x seems too dangerous, since it's stable.
Maybe a followup issue for 2.x among the upgrade path issues swapping just the permission names to allow room to 'administer simplenews categories' to exist in 2.x. Maybe it's against current nomenclature, but that would make site upgrade and contrib code upgrade to 2.x lots easier. I just mean machine naming. I'm not familiar with 2.x branch (just checked simplenews_permission() ), so it's just an idea I'm unsure of how can affect. What do you think?
Meanwhile how about such a message in the update hook?
Comment #18
amonteroWorking update hook.
Used functions in user.module safe at hook_update time, no external API calls other than DB involved.
Roles granted 'administer simplenews categories' permission are logged.
Hopefully nearing my first commit for simplenews :)
Comment #19
amontero#18: simplenews--794180-add--administer-simplenews-categories--permission-18.patch queued for re-testing.
Comment #20
amontero#18: simplenews--794180-add--administer-simplenews-categories--permission-18.patch queued for re-testing.
Comment #21
amonteroBumping.
Is there anything else that should be taken care of to get this issue commited and closed?
TIA.
Comment #22
amontero#18: simplenews--794180-add--administer-simplenews-categories--permission-18.patch queued for re-testing.
Comment #23
amonteroBumping.
To all subscribers: as I've checked on IRC, this issue just needs someone to review and test it (including upgrade path) to be ready to be commited (RTBC). Anyone interested? TIA.