@quarta77 So plugin docs should be easy enough to find. The multi user system manages sub-admins and I don’t think is documented in the manual as things stand (it was in the old manual but not moved across).
Yes this functionality exists as you describe it, only you must create the subadmins – they cannot create themselves. Passwords are emailed to them. In the next release settings passwords for subadmins via the web ui will also be possible. See https://mantis.phplist.org/view.php?id=19061
No problem, thanks. Thank you SO much for replying to my post. I was able to locate where I can create a sub user. I created one, but the password did not get sent to the user. Any ideas why?
I wanted to test logging in with that user, to see if the instance would be brand new. Meaning, as the admin, I created some subscribers, campaigns, etc. If I logged into the system with the sub account, everything should look brand new , right? Like the subscriber lists would be empty right?
This goes back to my requirement of having different users having their own assets.
Thanks so much. IF this is true, then I can definitely select phplist over every other open source project.
@quarta77 One issue with the way subadmins are currently created is that if email delivery isn’t working for some reason, then no password will be recieved and the new subadmin can’t login. That’s a key reason for the upcoming improvement mentioned above. Basically you should investigate your SMTP settings as the most likely culprit. As a workaround you can reset the password in the database directly. You should be able to just set a plaintext one e.g. via phpMyAdmin, as phpList automatically hashes such passwords the first time they are used.
Yes once logged in, the space should be clean, with no campaigns or subscribers. Only the primary admins can see all campaigns and lists. It sounds like it should fit your use case.
Fantastic. Thanks. I was eventually able to log in as the sub account and it was clean as you mentioned. This is great.
Now, if I put up my own sign up form , I could programmatically insert the user record into the phpList DB. What table and fields would i need to populate in order to get them to be able to log in and use the application as a clean , new user?
Lastly, as users sign up, they are completely separate , right? Or are they tied to together by any means?
From what I can see, multi-user does not equate to multi-site, i.e., each user will not see what appears to be a completely fresh install of phpList. Specifically, there is only one set of Config data for the entire phpList installation, so all subadmin users are still within that basic configuration (organization name, campaign defaults, reporting settings, etc.).
As one example of how this has an impact, when you import subscribers or send a campaign, phpList will send reports of the results via email. Each of your users will not get their own, all of those reports for all of the lists created by your users will go to one email address, e.g., yours.
Another example, your users will not be able to create subscribe pages unless you give them the ability to change the Config settings, which are shared among them all, which could lead to chaos.
The multi-user functionality intrigued me because I’m a writer, I use phpList for my reader newsletter, and I have a pen name with a separate identity (and newsletter) for those readers. It would be great to be able to have a completely standalone instance of phpList for the pen name, but AFAIK that can’t be done without a separate code and database install (which is probably what I’ll do eventually, but right now “his” list is the one thing I still have in MailChimp).
Right. I see. Thanks for the reply. Is there anyway to create a plugin that would allow different users to have different settings and make it seem like their own install? How can I achieve what I am looking for?
I’m not aware of any way to accomplish that currently, other than installing separate code and creating separate databases. If there is a way to do it with one database and code instance, I would also like to know so I can use it as well.
The functionality you need would be very useful to other phpList admins also, and better suited to being implemented in phpList itself instead of plugins.
The sub-admin (multi user) system already includes ownership of lists and campaigns by specific admins. Subscribe pages and transactional messages could include similar ownership.
A good next step would be writing up the changes in a Mantis issue and requesting feedback from others (e.g. suela, duncanc, xheni, and michield). You could also break down the changes into separate issues to make progress more bite sized and easier for others to assist with, or work on parallel.
Sure. Lets start to outline how we can get true multi user support.
I assume the system would then act as an account centric fashion, where most of the queries would include the userID.
We could start by outlining what is NOT specific to account. For example, someone mentioned that the bounce back emails are not configurable per user. This would be something we could document to implement.
I don’t mind contributing funds to get this rolling.