I'm guessing I have a configuration issue but when I'm logged in (not as host) and try to add another user as a friend, I get the error message "You must be a member of the site and signed in to perform this action." Thanks for your help, John

Have you checked/set your community role correctly

I've gone back through the manual and all my settings and they appear to be set correctly (both Member Role and Community Role are set to Registered Users). I'm running DNN 5.4.4 and AS 1.7.2. Any other thoughts?

Only time we have seen something like this happen is when accounts were imported or using some kind of module that tries to share users across portals. Were both accounts created using the standard registration method?

Will, Yes we have been running DNNMaster's Multi-User Portal Sharing module on this site for many years. We may have hundreds of user accounts on this site that came from sister portals. What needs to be done to resolve this situation? Do we need to track down this accounts came from other portals and delete them and disable this user sharing module?

We have had several customers report problems with DNN Masters. Their utility does properly create the user in the same manner as DotNetNuke. I'm really not sure what would be the best course of action for you, but I know that user created according to DNN standards do not have this problem.

Why are you saying that DNNmasters MPUS-X module doesn't properly create user account ?
Did you test it ?
Can you support this with facts ?
Somehow the core DNN which should be the final compatibility reference does think that the user accounts are correctly created and they are working.
As a matter of fact the AS does work with DNNMasters MPUS-X module if the proper roles are shared.

Yes, we did test it and have had to troubleshoot several client installs.

Yes, each install that we have had to troubleshoot didn't have the profile created properly on the additional portals. Once the user was created with a profile the user was valid.


You are absolutely right. The core actually creates the profile data for each user, on each portal. The user sharing module does not.

Yes, once the user has been setup the same way DNN would create a user everything works just fine.

DNNMasters MPUS-X module replaces the core dnn providers so any module following the provider model will actually see the profile as belonging to a given portal user.

You are pulling data directly from database and yes, it is true MPUS doesn't create a copy of user profile on each user portal. It maintains one profile instead and the provider shows it as belonging to user on each shared portal.
This way the user can change his profile data on any shared portal and the changes will be visible on all of them.

Maybe you could adjust your module to this situation ?

Querying members and returning results through the providers doesn't scale well at all. Last time I checked, returning a list of users from the providers doesn't even include profile data with is another major drawback. The problem with the way this is being handled is that when someone decides to stop using this module then the user records in the database do not match the way DNN expects. We spent 2 days with a customer in this exact situation where we had to fix users, roles and profile properties. I honestly don't like the idea of using a provider that alters the way DotNetNuke stores and manages data relationships.

When somebody decides to stop using the module the expected action is to "un-share" the portals and this will revert to original, core dnn state.
If the module is simply disabled and removed the data will be in a state not compatible with dnn but that's an obvious mistake and there is an extra warning in docs for such case.
However, the problem at hand is how to solve this issue ?
Can you adjust your module so that in case the MPUS is installed it'll take this in consideration and pull the correct profile data ?
Another option is to change MPUS to make a copy of user profile for each shared user and portal but this will negate it's basic functionality and bloat database.

Chris,
With the current way your module is handling the data I don't think we can solve this issue. This isn't something we could quickly change even if we wanted. If your provider was handling the shared data in your own tables I would definitely consider providing some options, but I really don't want to be in a supporting position with a product that alters the DotNetNuke core data structure. While I can see how there is great benefit to using your product, I think it could be handled in a different fashion without altering the core data structure. If you want to discuss this further feel free to send me a message on the site or email.

Just to bring this topic to a close, Active Social requires users to have data matching the same structure as if DotNetNuke created the user. This is also important for any products that import user data.

I appreciate this discussion and hope that this can somehow get resolved. The ability to share users across portals in a DNN instance AND maintain social-network features is important to many of us. It seems the whole name of the game these days is about SHARING information across many potential sources and users. Having to maintain separate AS instances for each portal keeps the information isolated to that portal. Having a central AS instance that can be accessed from any portal allows information to flow freely and would be easier to find. Of course we could maintain only one AS instance, but then users would have to login again. If that happened, it would cause a lot of irritation and would inevitably lead to less user participation. User profile maintenance would also be more difficult. We might as well setup a Ning or SocialEngine site if the the users are going to have to login again or we have to maintain two profiles... For what its worth, I for one am willing to take the risk and responsibility to properly "unshare" my portals if that becomes necessary. With properly warnings in both module documentation, the module vendor shouldn't be held responsible for customer error. Except for this one issue, it appears that ActiveSocial is the best DNN option out there. I truly hope it can be resolved by both module vendors working together to find a solution. Kevin

Kevin,
I can definitely see the benefit of sharing users across portals under certain use cases. However, in a social environment there are many things that need to be taken into consideration. How do you handle privacy settings for data across portals? With this user sharing module the privacy settings will always be the same as the parent portal. What if in portal A I don't mind everyone seeing my phone number, but in portal B I want it to remain private? What if in Portal C I want only my friends to view my profile but in Portal A it is open to everyone? What if in Portal B I want different profile properties than I want in Portal in A? What if I want users to access their photos from all portals regardless of where I upload them? What if I don't want photos accessed on every portal? Maybe none of these use cases apply to you, but I know they have come up before. These are all things that need to be considered and carefully tested before implementing user sharing. Many times we get questions about user sharing. Often there is confusion between user sharing and single-sign on. DotNetNuke already supports using the same username and passwords across portals. The majority of the time, once a user understands how user data is managed within DotNetNuke they realize single sign-on is what they need.

Will,

Thanks for your response and concerns about security. I very much agree that security and privacy is a BIG issue that needs to be carefully thought out. That said, it should up to the administrator of the site, not the module manufacturer to ensure things are setup properly. I would at least like the option of sharing users, not be prevented because of potential security issues. Right now we only have the option of Portal A, B, and C to be maintained as separate entities. That is fine for some installs. Others might need A & C to be shared users in AS, with a separate B AS site. For my purposes, I need A B & C to share users in a single AS install. (BTW, the MPUS-x module allows the admin to decide which direction users and roles are shared and from which portals). Since every site's needs are different than others, flexibility is a key to a successful site. Right now AS is taking a fairly non-flexible route if it doesn't allow user sharing at all.

Kevin

No, my point was that if the module manufacturer is going to go outside of what the environment dictates then it is up to the module manufacturer to provide options. The use cases that I laid out were just a few things that we would have to consider and ensure flexibility, not set rules.

I couldn't agree with you more.


Active Social DOES ALLOW user sharing in the manner that DotNetNuke provides and supports. I'm sorry if you think Active Social isn't flexible because it follows and supports the data structure that is provided in DotNetNuke. The idea of storing or altering data in the core DotNetNuke tables in a manner different than the way the core intended doesn't sit well with me or any other customers that I have shared this issue with.

I'm going to lock this topic, but I will create a new one in the feature requests section. This isn't a technical support issue.