Symphony.

So, I'm about to embark on a project that will use Members. It's my first Members project.

I'm wanting to have the authors of the site be able to log in to the website's front-end the same way that members do, using the same form, but have more privileges and access, and therefore create an ACL for the site.

Has anyone managed to do this yet? What sort of logic will I need to achieve this.

Also, along the same vein, has anyone thought about a method of automagically promoting a member to an author? Is this even possible??

I am building something similar to this. I will have up to some hundred members with "create/edit" permissions and just a few backend authors. The ACL is half-way done. I won't include Author login on the frontend, because there are more important things to do. (An author can as well use a Member account in the frontend, as long as the permissions are OK for him.)

I don't think it is a good idea to mix up Members and Authors. Try to keep things simple. If you want people to work in the frontend, try to have Member permissions for different groups of members. (In my case there will be even more logic in the permissions layer.) So thinking of a real web app, one should indeed be able to restrict the backend to the developer and make everybody else login to and work in the frontend of the website.

Besides a cool ACL you will need a good templating system to build the frontend and make it talk to your events. That is probably the harder part, because you will have to solve a lot of problems which have already been solved for you in the Symphony backend. But your goal is to make it even better! :-)

[EDIT:] By "better" I mean "more focused" (on certain tasks). The Symphony backend must always try to be ubiquitous.

It has always confused me that a Symphony developer can bypass Members login on the frontend. This isn't logical to me. If you would like backend "authors" to be frontend "members" then I suggest writing a members layer that hooks into the Authors system. Members can apparently support other authentication systems such as Facebook and Twitter. It's the same jump to integrate with LDAP, your own database of users, or the users in the Symphony authors table.

You could see Brendan's FB/Twitter members integrations and go from there.

I think you're right Michael, separating Members and Authors is the right way.

I will be using Symphony primarily as the 'framework' for an app that will be run from the front-end only, so it does make sense to keep them separate. I thought I'd ask anyway...

I think this may take me some time to do, partly cos I'm lazy and don't have much time, and partly cos I have to learn how this Members stuff works.

Nick, whe you say bypass, do you mean the developers are always logged in as members? or that any logic in the XSLT is completely ignored for developers? I can see the latter being a big issue for testing this app of mine... If it is so, then there should be a switch, or it shouldn't do it at all. I would hate to have to log out and then back in just to test a template...

Nick, whe you say bypass, do you mean the developers are always logged in as members?

Correct, if you're logged in as a Symphony developer and view a page restricted by Members, it lets you view it, so Symphony backend users trump frontend members. I've found this quite a confusing workflow: "why can I see this page but the members data source isn't finding a member?".

So my idea was to write a members provider that hooks into backend users (they're just another source of user details), the same as FB, Twitter or any other oAuth/OpenID setup. Keeps tempting easier.

if you're logged in as a Symphony developer and view a page restricted by Members, it lets you view itby Members

That's what was catching me out recently on an internal project. Easy to get tripped up trying to test Front End Members while logged in as Symphony Admin.

@michael-e, member forms is a godsend!

@moonoo2: Thanks!

I vaguely remember a discussion about the "Members login bypass" for developers. Maybe @brendo knows more.