Since any Facebook user "can join as many classes as you wish now", I think it's time to revisit the Guest User options which were discussed back when the new Restricted Page was being designed and implemented. As it stands now, it's an "All or Nothing" choice, and several 'Restricted Guest' options are almost mandatory.

At the very least, a Guest User configuration which incorporates the restricions of the old System Password access is needed.

Although we can entertain any specific ideas, Class Connection works no differently from the way Class Creator has always worked. i.e. you can decide if you want anyone to be able to join your web site, or you can require a name be on your Class List in order to join your class. The addition of the ability to join multiple classes on Class Connection changes nothing. New Classmate Verification can also be used, or not used, at the Admin's discretion. There has never been itemized Guest Access rights. That's basically what you're wanting correct? If yes, do you envision that being per page?

That's true. Class Creator offers the same two choices it always has. Someone can be a Member with full privileges, or a Guest with full privileges. And Class Connection did change one significant thing - we used to be able to restrict any join attempt to only those whose names were pre-entered.

If you skim though the 'Restricted Page' thread, there were quite a few suggestions on how to handle guests - including some good ones you made yourself. Some of those would involve major changes to the way the system was designed.

But one would not. The code is already there to handle someone who logs in using the System Password, allowing view access to restricted pages (except profiles) but no ability to post or make changes. It would not take a giant step to create a "Limited Guest" which had the same permissions and restrictions.

Of course, building on that to offer additional choices for a Guest Member with check boxes to allow or restrict by page or function would be happily received. Or additional options per page. But for now, a "Limited Guest" option would be a great start.

All right. I hear the suggestion but nothing changed on Class Connection regarding this. You can still restrict joining to only those pre-entered on the Class List just like always. If you have it set up that way on your Preferences page, and somebody only attempts to join via the app, they'll be blocked right there. They will be able to see your class list like normal, they won't be on it, and the only option they are given is to contact the Administrator to request being added to the Class List so they can join. Or again you can opt to allow anyone to join, turn on New Classmate Verification, and approve each new joinee. The point being both of these options work precisely the same on Class Connection as they do on Class Creator.

Let me add one note to what I just said above as there is one minor difference on the app. Anyone can install an app. We can't stop that actually. So the user will in fact have an installed Class Connection app even if they're not on your Lass List. That's as far as it goes though. Because they are not on your Class List they can't go any further than that, and they can't get into your class at all until you add them. They're in limbo so to speak until you add them to the list They have the app installed but they can't do anything or access anything they're not authorized to see, and nobody sees them until you give them a name to use so they can officially join -- same as Class Creator.

Thanks Brad. I was equating an app 'join' (which is really just a selection within the app) with a Class Creator 'join' where we allow selected names to register. Two very different things, although one could lead to the other.

But I also remember early reports of people who could see or do things from the app which web site visitors could not. Assuming any of those were true and have been resolved by now, I hope you're right and the security of the playing field is now the same for everyone.

But the combination of people who want to access the site has changed. We need to handle many more potential visitors who have found the app (and our site) and who have different reasons for visiting - and wants/needs to see or do things.

On our site, we allow members of classes on either side of ours to be guests. Same with teachers. Or even spouses of deceased classmates who we've known for decades and want to stay in touch with. But in this new environment, we now have to adjust to a wider variety of requests for access. It's one thing to allow classmates from adjacent classes full access, and another to allow the same full access to someone who wants to look around because they went to the same school 10 or 20 or 50 years later.

In short, when it comes to view access and functional permissions, one-size-fits-all simply doesn't meet our needs in the current enviromnent.

Ok great. Let me propose a couple ground rules so we're all clear on this as we discuss in the future. Let's use these names:

Guest: Guest is somebody you actually add to your class web site as a member.
Visitor: Visitors are people coming to your class via the Facebook app

We can get into specific details, but generally, what would you like to see in terms of access rights as it pertains to both Guests and Visitors? Is there a specific list of pages or features you've got in mind? As always we want to KISS. Rather than making every possible thing something admins can turn on or off for Guests and Visitors, what are the main needs here in your view?

Sorry for the delay in responding. There were some great discussions about this in other forum entries a while back, but some of the posts seem to have disappeard. Or I just couldn't find them.

There is, however, a post in one of the TAP forums which is pretty clear. I edited it slightly since there have been some changes since then.

Posted Sunday, September 22, 2013 02:07 PM

The subject has been beaten to a pulp over in the CC forums, but... I'd like to see more of how (or if) others use the System Password - and if there's support for a function that could replace the System Password which is no longer mandatory - with something better.

As I see it, there are 4 levels of access.

1) Joined Classmates - Access to everything, site email and Nofity options, the ability to post in forums, add comments to In Memory, etc.

2) Guest Members - same privileges as joined classmates.

3) System Password access - View privileges for everything (except profiles), but nothing more. The password can be changed, but usage can't be monitored.

4) Visitors - Anyone who hasn't joined has limited view access only, including a differently configured Home Page. Members who haven't joined yet are in this catagory until they join, along with search engines and passers-by who hit the web site for whatever reason.

What I really would like to see when all the dust settles is at least four basic levels of access. Additional sub-levels would be a plus.

I still like the idea of view access only (except for profiles), with no posts or changes allowed. I can see cases (spouse/family of deceased classmember, alumni association secretary, etc) where that's what I'd want to do. Trouble is, there's no way to monitor access via system password now - and it doesn't expire.

What if we replaced the system password access capability with a "Configurable Guest"?

That might include options to configure or set what a Guest Member can see and do, or a "Limited Guest" member type which duplicates the functionality of the System Password.

For a "Configurable Guest", set up could include Guests being either hidden or display in their own section of the class list (as they do now). They could have all the privileges a Guest has now, or less functionality like configurable view limits such as blocking profiles (or evem some locked pages), could post (or not), use email (or not) etc. Perhaps a drop-down menu with check boxes for allowed options.

Guests could have a full profile, or - like a hidden guest now - could have no visible profile. And depending on the options chosen, could only require limited Details (mandatory email address and password for logins), with optional address and phone number. And we could monitor each Guest's usage like any other member.

We will discuss these ideas internally and we will decide if and how to proceed.

Thanks Scott.