There are many scenarios where a subscriber list needs to be shared among many (non super-) admins.
Currently a subscriber list can only be owned by a single administrator, which does not allow shared list use.
Are there any plans to extend phpList any time soon so as to allow subscriber list ownership by multiple administrators?
What other solutions or workarounds exist for such shared use senarios?
I have exactly the same question. I have multiple editors and multiple lists. All editors need to be able to send messages to all lists. The only way to achieve this, is to make the editors super admin, which is not what I want.
I think being able to assign multiple owners to a list would be ideal. However, a setting per list to āallow all editors to send to this listā would work for me as well, if thatās easier to implement.
Also, I would appreciate it if someone has a work around that works with the current version.
Best regards,
Bart Kummel
I made a change to accomplish what you need and more to version 3.2.5 about a year ago. It permits regular (non-super) admins to send from any list, modify any list and a few other functions relating to members and lists. It takes only about 15 lines of code. I also made a separate mod so regular admins can manually confirm a subscriber.
If a moderator of this forum will chime in and give me permission, Iāll post it on this forum. If not, you can send me a message with your email address and Iāll send the information to you.
This mod will grant all regular admins the additional privs. It cannot be set for specific admins only.
This sounds interesting, do you know if it will work with the current 3.3.1 version please?
Interesting hack, however I hope that phplist will build-in multiple-admins (selected admins) ownership for each and every subscriber list.
I believe the developers will acknowledge this need. It will be better to incorporate the functionality in the main source tree.
Nick
I havenāt looked at the 3.3.1 code so Iām not sure if the mod will work, but most likely it will. Iāll take a look when I get a chance.
Works just fine with version 3.3.1. Your query motivated me to perform the upgrade and make the mods to the latest version.
Thatās great Steve, would you like to post the mods youāve made for others who would like to add this option to phpList.
Obviously when an update appears it may overwrite your mods, but in the meantime I think, from the number of queries weāve had, itāll be a most welcome mod.
OK - Here goes.
I chose these options because these are what I need for my organization. You donāt need to implement all of these options. For example, you can let all admins use the lists but not be able to view members of the list.
This mod will permit all regular admins to:
Use all subscriber lists to send campaigns.
View members of any subscriber list.
Add members to any subscriber list.
Modify the details of any subscriber.
Regular admins cannot:
Delete a subscriber he does not āownā.
Manually process a queue (from the web interface) - A cron job must be used to send the campaign.
In file admin/accesscheck.php change function accessLevel
From:
function accessLevel($page)
{
global $tables, $access_levels;
if (!$GLOBALS['require_login'] || isSuperUser()) {
return 'all';
}
if (!isset($_SESSION['adminloggedin'])) {
return 0;
}
if (!is_array($_SESSION['logindetails'])) {
return 0;
}
//# for non-supers we only allow owner views
//# this is likely to need tweaking
return 'owner';
}
To:
function accessLevel($page)
{
global $tables, $access_levels;
if (!$GLOBALS['require_login'] || isSuperUser()) {
return 'all';
}
if (!isset($_SESSION['adminloggedin'])) {
return 0;
}
if (!is_array($_SESSION['logindetails'])) {
return 0;
}
// Modification Start
if ($page == 'send') {
return 'all';
}
if ($page == 'list') {
return 'all';
}
if ($page == 'members') {
return 'all';
}
if ($page == 'user') {
return 'all';
}
if ($page == 'users') {
return 'all';
}
// Modification End
//# for non-supers we only allow owner views
//# this is likely to need tweaking
return 'owner';
}
Thatās it.
phpList 2.x had more comprehensive permission management for sub admins but the was later removed due to small demand for the features and greater confusion over when to use them.
It would be good to have granular control back in phpList 3 and 4 - you can engage other developers on this issue by writing a more detailed set of expectations on mantis and solicit feedback. Once the backend is in place to support this, front-end changes can be designed to make configuration straightforward.
An old topic, but Iād really like to see a way to limit access to lists/templates/etc based to admins. So that anything āadmin1ā creates would not be visible to āadmin2ā or any other admin (other than the super-admin).
Multi-tenant - would be a great feature. Is it easily enabled with a mod similar to the one in this thread?
I donāt know if it is similar to RickHs comment, but I am thinking of enabling a more data friendly version of your proposed mod.
I am not fully satisfied with giving all administrators the rights to view and edit all lists. From data security and privacy perspective the implementation in phpList is good. But for my usecase it still is necessary, that unprivileged administrators may use a specific list for sending, but not for editing.
So my proposal was, that you can have ONE OWNER of a list, but you can specifiy MULTIPLE USERS of a list. Meaning that a list user is allowed to use the list for sending. But he/she cannot view the subscribers of the list.
When I find time in next days, I will also propose a code change.
But for now: What are your thoughts?
Please tell me if you find this remark should be placed in an own topic.
After short observation my short term mod ist to use just the access modification for āsendā which results in having all lists for all users that can send newsletters.
// Modification Start
if ($page == 'send') {
return 'all';
}
To allow setting of allowed users per list, it would need another table that maps lists to users. Besides a new configuration options the last change would again be a simple update to the accessLevel function. I donāt know when I will find to dig deeper into this solution.
This post was very helpful for me!
Do you think itās possible to write a plugin for it? Because after every update the changed settings going lost. I would try it myself, but there are already too many other projects I participateā¦ 
Or is there already a plugin what I overlooked?
Regards,
Joseph