Symphony.

From what I remember, that was one of the more hated and confusing aspects of the old extension. All events will display.

Please see my post a few above your comment. All events should display, including those that are quasi-events (Login Info for example) but that there should be a flag somewhere to mark these events as un-permission-able. Was there any progress as to how this should be implemented? There's logic in the UI to de-activate these rows, it just needs the condition to be set.

Thanks XBleed, created #118.

@nickdunn I saw that and introduced ignoreRolePermissions in this commit :)

@wdtan Yeah, Members master branch is useless, it's the old alphaish extension and the new extension has no backwards compatibility with that. I've swapped the default branch of the repo to integration to hopefully prevent the extra step of swapping to an integration branch.

@xbleed - right, i understand it's not compatible with pre 2.2.1 versions. How do i update in git to use the 2.2.1beta1/2 tag? I'm not familiar with using them.

2.2.1 is no longer beta/rc, you should just be able to pull down from master, update your extensions with git submodule init / git submodule update and then run update.php

@nickdunn I saw that and introduced ignoreRolePermissions in this commit :)

I didn't spot this. Thanks mate.

@xbleed - i didn't think about this until just now, but I cloned symphony from git yesterday so I would assume that that would have been 2.2.1? After install, I then installed the members extension in which I was still getting those two db issues I outlined above.

also, I'm using a combination of rowan's and jonas' git/symphony articles but seem to be having troubles merging and updating from my symphony branch into my site branch. I can't seem to merge updated files for some reason. any clues on this one as well?

I cloned symphony from git yesterday so I would assume that that would have been 2.2.1?

Hmm, yeah, it should be. The bottom of your backend should specify which version of Symphony you're running, if you want to double check. That, or it should be in your parameters which you can see via debug devkit.

Sorry, but I don't really have an answer to the errors you're getting, myself.. I can't seem to replicate the issue on my end.

I have a post that ostensibly has to do with the selectboxlinkfield but is in the context of the Members 1.0beta3 extension. Please take a look at it and let me know if you might have an idea how I can move forward. Thank you.

Apparent Security Issue for Public Role

My configuration

• Symphony 2.2.1
• Members Extension 1.0 beta 3
• PHP Version 5.3.4
• Apache 2.2.17
• MYSQL 5.0.7

Browser Analysis

• Chrome 11.0.696.57 allows Public Users to view blacklisted pages
• Firefox 4.0.1 allows Public Users to view blacklisted pages
• Opera 11.10 blocks correctly Public Users from blacklisted pages
• Safari 5.0.5 (6533.21.1) blocks correctly Public Users from blacklisted pages

Synopsis

All pages are viewable that are blacklisted (deny access) for the Public Role in the Page Level Permissions within the Member Roles section.

In the Symphony Debug Console I see that I am logged out (i.e. defaulted to the Public Role):

Action Items:

Does anyone know of extant bugs that might cause this? Or errors that I may have made in setting this up? Your help is appreciated.

Attachments:

not-logged-in.png

I'm wondering if it is something that confused me a ton when I first started playing with this extension as well:

Symphony and the Members extension, as you know, use two different login systems. With the old members extension if you logged out of the front-end member username, it treated you as a member of the public.

I have noticed that with the new Members extension, even if you log out as a front-end member, but you are still logged in as a member of the Symphony backend, then you can still see all of the pages.

Is this what is happening to you? I'm wondering if this is a bug or intended behavior? It does make it a little more confusing...

Here's a work in progress FAQ

It's intended behaviour, if you are logged into the backend, page permissions are null and void to aid development.

@TheJester12 and @brendo that seems to be exactly the case. The difference in browser analysis above seems to be that I wasn't logged in in the Safari and Opera instantiations of the issue.

Thanks for clearing this up for me. I'm so very glad it's something simple and with me. I can change me fairly easily.

It's intended behaviour, if you are logged into the backend, page permissions are null and void to aid development.

I don't feel that this behaviour is an advantage. On the contrary, I find it misleading. And I don't like the fact that you will always have to open a different browser to check the behaviour of your app for visitors.

I have a question regarding the cookie behaviour.

By default a Symphony cookie is valid for the entire domain and all subdomains, as stated in class.cookie.php, line 56:

     * The domain that this cookie is valid for. This is null by default which implies
     * the entire domain and all subdomains created will have access to this cookie.

This Symphony behaviour is good and should not be changed. (It is very useful if parts of your website run on an SSL subdomain, for example.)

But unfortunately the same applies to members being logged in, which may be a problem for applications running on different subdomains. In fact I have this problem with a project I am building at the moment. My members should have to log in for each of the following domains separately:

• example.com
• sub1.example.com
• sub2.example.com

Would I have to hack the Members extension to achieve this?

I don't feel that this behaviour is an advantage. On the contrary, I find it misleading. And I don't like the fact that you will always have to open a different browser to check the behaviour of your app for visitors.

Perhaps this is a preference toggle that could be added in future releases?

I don't feel that this behaviour is an advantage. On the contrary, I find it misleading.

Interesting. I think I would find the alternative behavior illogical—being logged in to the back end as a developer and not being able to access pages on the front end.

Interesting. I think I would find the alternative behavior illogical—being logged in to the back end as a developer and not being able to access pages on the front end.

I only see the benefit if members' pages are plain-vanilla. Most member websites I work on incorporate member specific data into the member pages. So I don't really see an advantage either, but it doesn't annoy me.

+1 points for Lewis. Member pages are member related, so you should log in as one to see them (properly). And you should also be able to log out as Member and test what's happening to the member whithout the need to open a second browser or log out from the backend.

@Craig: Remember that member and autor/developer data are not coupled at all.

[EDIT]: We are talking about permissions here, whch can be changed at any time. But in my experience it's hard to get your application do the right things if your developer status overrides you member role's permissions.

The idea that an extension can keep me, as a developer, from seeing a front-end page seems counterintuitive to me. But maybe that's just my own weird logic...

Here's a tricky one..

Would it be possible to somehow use the activation features of this module to create an invite only registration system? Maybe there's a way to create a registration form that ignores the password requirement? Then just create a page with that event attached, ask for the invite receivers email, and send it off? That would send them the activation/"invite" code?

I guess the only problem I see with that idea is what I already mentioned.. the password requirement for registration forms. Anyone know of any other road blocks, or maybe if working around this one is possible or not before I start attempting this?

Thanks