I guess it would be hard work to accomplish that. I could think of ways for both, but the effort to do so is not worth the profit.
The payoff is a matter of opinion. I still think there is appeal in inviting outsiders to participate in a specific discussion deemed of interest to them by authors and other participants. Yes, this is thinking outside the box of how traditional forums work, but I do believe it is a strong vehicle to increase the forum members.
I'm not aversed to the notion of using categories and dynamically allow access to the invitee to the shared category, but:
1. Moving a conversation to a different category will make it less accessible to the fully registered forum users (that was the reason for the prior digression into discussion "shortcuts").
2. I read somewhere that for performance reasons it is not advisable to have too many categories and clearly creating a category for each shared discussion will do just that.
Indeed your reading was right - an invitee would have a simplified registration from and when upgraded would have the rest completed. There may be some aspects of the registration prefilled by the inviting person. Anything to make life easier for the new invitee who will hopefully one day "graduate" to a full member.
I know that this is a complex issue and that a full design document should have been introduced, but this forum is not very conducive to have a design discussion - lengthy posts discourages the audience. So both mea culpa for not being fully clear and thank you for responding despite this shortcoming.
(if you would like a high level design document, I'm willing to create one).
@hgtonight said:
To break this down in terms I can understand:
You have multiple categories with some type of access restrictions (everyone cannot see every category)
Yes, there are several existing categories (not too many) with role based permissions.
2 You want a share button aimed at bringing new users on board (could users that do not have current access be invited?)
The share button will invite users (both unregistered and registered - two different processes, I concur) to join in the specific shared discussion (view+comment).
3 Through this share action, you want to enable users to view a single discussion in a restricted category without signing in
Is this correct?
I am thinking that the Share button will email some sort of an invite or link, but since the purpose is to engage the invitee and promote "fuller" registration, I think that some "partially registered" user (we'll have his email - that's how the sharing request will be sent) will be created through the sharing process. So "without signing in" may or may not be accurate - I can live with either granting access by a link or by a trimmed-down signing in (just the email?).
I am not sure whether your hashing approach requires creating multiple new categories as was previously suggested. The advantage of this approach is that the existing security/permission model would prevent invitees from accessing other "unshared" discussions, the disadvantages are (1) this will create proliferation of Invitee-related categories, supposedly a performance hit, and (2) make the original discussion less accessible to the original participants (at the minimum less visually accessible).
If so, I think a discussion attribute along with a random hash key (kind of like a nonce) could be used.
I am not sure I understand the discussion attribute with hash key approach. Can you elaborate?
Ok, so when you generate a shared link, you add an attribute to the discussion that contains a hash of some kind.
The link will contain some method to say "I am an invited user". If the discussion controller sees this method, it validates the "I am an invited user" data and shows the discussion if everything looks kosher.
At this point, you have a reference to the user via a hash. If they want to comment, you see this reference and create a new user properly with the data in the link. Then submit the content via the newly created user account.
The only cleanup you have to do is to remove the discussion attribute once it has been used.
So, you modify the session after the discussion controller has been set up in Gdn_Dispatcher_BeforeControllerMethod_Handler. Then you go from there.
Not sure how to bypass the login for a non-registered user (I'll check whether comment before register performs such a bypass)
I'll also need to learn a bit about dynamically creating a new user. All I'll know is the email (possibly name if the sharing form asks for it - I need to be stingy as I want it to be easy).
I'm thinking that the cleanup will be on an aging process as I'd like the invitee to be able to comment multiple times without the need to have to be invited again to the same discussion.
There may be several invitees to the discussion, so the attribute you mention will have to be an array or a link to another table (array is easier, I guess).
I like the addition of a field to the discussion because I want to highlight the fact that the discussion is shared and on click show who is it shared with, and let the inviter and the author remove the share (one of cleanup events). I need to think about the handling of expired/removed shares (what to show on the screen).
The hashing is for security or for randomization or both?
I think I saw somewhere that Vanilla has some hashing function. Is that what you were considering?
I guess the invitee email would be the key for the hashing.
Finally, and not the least important, you @hgtonight wrote:
If the discussion controller sees this method
is this a hook that does not have the previously mentioned exposures mentioned by @R_J?
Comments
The payoff is a matter of opinion. I still think there is appeal in inviting outsiders to participate in a specific discussion deemed of interest to them by authors and other participants. Yes, this is thinking outside the box of how traditional forums work, but I do believe it is a strong vehicle to increase the forum members.
I'm not aversed to the notion of using categories and dynamically allow access to the invitee to the shared category, but:
1. Moving a conversation to a different category will make it less accessible to the fully registered forum users (that was the reason for the prior digression into discussion "shortcuts").
2. I read somewhere that for performance reasons it is not advisable to have too many categories and clearly creating a category for each shared discussion will do just that.
Indeed your reading was right - an invitee would have a simplified registration from and when upgraded would have the rest completed. There may be some aspects of the registration prefilled by the inviting person. Anything to make life easier for the new invitee who will hopefully one day "graduate" to a full member.
To break this down in terms I can understand:
Is this correct?
If so, I think a discussion attribute along with a random hash key (kind of like a nonce) could be used.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
I know that this is a complex issue and that a full design document should have been introduced, but this forum is not very conducive to have a design discussion - lengthy posts discourages the audience. So both mea culpa for not being fully clear and thank you for responding despite this shortcoming.
(if you would like a high level design document, I'm willing to create one).
Yes, there are several existing categories (not too many) with role based permissions.
The share button will invite users (both unregistered and registered - two different processes, I concur) to join in the specific shared discussion (view+comment).
I am thinking that the Share button will email some sort of an invite or link, but since the purpose is to engage the invitee and promote "fuller" registration, I think that some "partially registered" user (we'll have his email - that's how the sharing request will be sent) will be created through the sharing process. So "without signing in" may or may not be accurate - I can live with either granting access by a link or by a trimmed-down signing in (just the email?).
I am not sure whether your hashing approach requires creating multiple new categories as was previously suggested. The advantage of this approach is that the existing security/permission model would prevent invitees from accessing other "unshared" discussions, the disadvantages are (1) this will create proliferation of Invitee-related categories, supposedly a performance hit, and (2) make the original discussion less accessible to the original participants (at the minimum less visually accessible).
I am not sure I understand the discussion attribute with hash key approach. Can you elaborate?
Ok, so when you generate a shared link, you add an attribute to the discussion that contains a hash of some kind.
The link will contain some method to say "I am an invited user". If the discussion controller sees this method, it validates the "I am an invited user" data and shows the discussion if everything looks kosher.
At this point, you have a reference to the user via a hash. If they want to comment, you see this reference and create a new user properly with the data in the link. Then submit the content via the newly created user account.
The only cleanup you have to do is to remove the discussion attribute once it has been used.
So, you modify the session after the discussion controller has been set up in Gdn_Dispatcher_BeforeControllerMethod_Handler. Then you go from there.
Search first
Check out the Documentation! We are always looking for new content and pull requests.
Click on insightful, awesome, and funny reactions to thank community volunteers for their valuable posts.
OK, interesting approach. Thanks!