This project is read-only.

Feature request

Feb 25, 2015 at 7:57 PM
Edited Feb 25, 2015 at 9:19 PM
It would be great to be able to establish a redirect on acceptance in the module settings as opposed to just the administrator or role on invite send. I would love to use the module to do 3 types of invitations via separate instances of the module that would require different redirects.

OK - Just tested the multi-module approach and it doesn't work the way I thought. The configuration of the module is for one module instance only. Bummer..... How difficult would this be to change so each module would have it's own settings. I realize that you set out to have a convenient and quick way to invite a user to a site but there is so much potential for this module!! One step at a time I suppose..

for instance:

Instance 1: Invite a referral (business to business) and would like to be able to include some profile tokens like userid of the person issuing the invitation in the body of the invitation. (We use the userid as a referral code and want the recipient to enter the code when they register). Redirect to a business inquiry page.

Instance 2. General site invitation. Redirect to a welcome page

Instance 3. Invitation to join a group based on group/roleid. Redirect to the group

__Now I'm thinking... It would be an awesome feature to automatically add the recipient as a friend of the person sending the invite once the invitation is accepted and creating a journal entry to reflect the acceptance __

Sorry.... there is so much missing from the community edition of dnn in terms of social interaction that I can get carried away :)

Going though the language editor, it was apparent how much work you have done in terms of functionality in this module. Thank you for the effort!

I remember using one of your modules many years ago

Feb 27, 2015 at 3:15 AM
Some very good suggestions there which can be incorporated into an upcoming release but not the 01.00.01 maintenance release that I plan to put out tomorrow. Here are a few of my thoughts:

Because DNN registration is portal scoped, the module also needs to be portal scoped. As such, my original design figured that one and only one instance of the module be placed on a site. All configuration settings are portal scoped (and stored in custom database table not ModuleSettings or TabModuleSettings. However, the module design could be modified so that some additional settings, such as default page redirect upon acceptance and default role(s) to be applied would be ModuleId or TabModuleId dependent. This would allow multiple instance of the module on a site, all sharing in the same invitation data and security, etc. configuration but differing in a few new settings.

Instance 1: The module already exposes a token for the inviting UserID, {"[Invitation:InvitedByUserID]"}

Instance 2: When no redirect after acceptance is specified when creating the invitation, the current default is the site's Redirect After Registration page or if that is not specified in Site Settings, the site's Redirect After Login page.

Instance 3:
Am I correct that you would want to place the module on the Group Activity Page so that it can pick up the GroupID from the query string and properly respond to it by applying the group's role to the newly created user upon acceptance and setting up the redirect after acceptance to be the Group Activity Page?

I would also think that the module's Manage Invitations control should only display invitations pertaining to the group and that only existing members of the displayed group (or administrators) would have access to the module when on the Group Activity Page. What about the Bulk Import capabilities - should they be completely disabled when the module is on a Group Activity Page or should any imported role assignment be disregarded and only the group role be applied to newly created users upon acceptance?

The idea of creating a friend relationship between the inviting user and the invited user as well as making an entry in the group's activity journal is a great one. What about when the module is placed on a non-group page? Should a friend relationship and entries on the inviting user and new user's journals be optionally (as a setting) also be done?

Would a much simpler module to allow a group member to invite someone who already registered on the site to join the group be helpful? I haven't made much use of the social capabilities of DNN on site's I manage but did feel that the current platform implementation leaves much to be desired and many opportunities for 3rd party module development. My ePrayer module ([]) does include several group related features when placed on a group activity page.
Feb 27, 2015 at 11:13 PM
Instance 1 - Being able to include the userid of the invited by is great so I can include that in the body of the email. I tried the option of "must have a valid profile" so the user is forced to update required fields that I need (zip code and referral id (userid))

Instance 2 - I use a custom registration and login module and don't use the dnn sites settings. This is due to the fact that I have 3 login scenarios that push to different roles and pages. So I can't rely on that. But I do need the ability to redirect based on the 3 scenarios. If there was the ability to establish redirects and roles based on module/tabid, I think I could create a generic email body but for groups that might be difficult. Maybe have an additional rich text field in the module settings that can be included in email body similar to the personal message that is stored in the module/tab settings in the database. That way I could have 3 instances of the module to handle the 3 scenarios.

Instance 3 - Yes I would want to put the module on the Group Activity page and enable group users to invite non-DNN users to join them. So on acceptance they would be added to the group role and redirected to the group activity page of the group. The email body would need to include the name of the group. I suppose the person inviting could include the group information in the personal message but if they don't, the person receiving the email would get the a generic invitation and not know what it's for.

I agree that the manage invite control should only show group invitations with access by existing group members.

A simple module for inviting existing site users to a group is a great idea. But it should only allow the user to invite/see their friends. We don't expose first/last name by default so giving a user access to the complete member list would probably not work.

Yes the implementation of social groups is really lacking. Group categories, notifications, geo/location, latest members. my groups, etc are really needed and I am surprised that there isn't more 3rd party developer activity around DNN social. Every module should have member and groupid capabilities too!

I see that you are in Maine. My son is stationed in South Portland with the Coast Guard and we are in Georgetown MA. It would be great to connect via email and I would like to share with you what I am doing.

Feb 28, 2015 at 2:04 PM
Thanks for the added information on each of the use cases. I'll keep them in mind for the next version. Unfortunately, that won't be available for a while as I'm now concentrating on my "FRBO-For Rent By Owner" module which I've been working off and on at for a couple of years now but hope to wrap up this spring.

In case you missed it, I released v 1.00.01 of DNN By Invitation yesterday which fixes several of the issues you reported - most importantly the notifications error that was shown when trying to approve or disapprove an invitation which required moderation.

I'm actually in Maine 6 months and Florida 6 months out of the year - don't like dealing with the snow and cold temps anymore.

You are welcome to email me at: bill (at)