Replies
- Philip Strothmann on April 12, 2019 at 3:32 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22241
Dear Brasjesh,
just FYI: It works because I set the field to have “Free User” as the default value and selected the option to not allow users to change member type after registration for this field – which I disabled via CSS on the frontend. That way the value is set, even though the user never sees it on the frontend 🙂
Have a nice weekend!
Kind regards, Philip
- Philip Strothmann on April 9, 2019 at 3:54 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22154
Dear Brajesh,
ok, that worked. In that case I will simply make the field disappear via CSS on sign-up to avoid that users set the type themselves 🙂
Thanks so much!
Kind regards, Philip
- Philip Strothmann on April 9, 2019 at 2:39 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22152
Dear Brajesh,
the screenshot of the profile would just show you quite literally an empty profile. Please find the screenshot from the settings here: https://www.evernote.com/l/AAInBuNW9YlLx5GOafZVmLsmAtoFtsaVaMUB/image.png
I’m not using any conditional fields, but something just crossed my mind: The member type field that is meant to be set based on user role is part of the extended profile in my setup, not of the basic profile which is filled out during registration – because it should be set automatically based on the role and not be the user. Maybe that is contributing to the issue?
Kind regards, Philip
- Philip Strothmann on April 9, 2019 at 2:25 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22150
Dear Brajesh,
I did some more testing and the behavior described above is actually causing a bigger problem than I thought initially. In the backend everything is set as it should, and if I trigger routines that change e.g. the user role, the member type changes as it should. So that’s all great!
Unfortunately, it doesn’t work equally well on the frontend. When I register a new user, the backend process runs and the correct member type is assigned. However, for some reason it is not shown on the frontend in the profile. The member type field simply doesn’t appear, regardless of how I set the visibility / ability for users to change it.
It only starts showing on the frontend once the user resaves the profile and only, if the setting is set to enable users to change the field in the first place. That’s a bit defeating the purpose, because a) I don’t want to enable the user to change the member type, as it should be set based on the role and b) the idea is that it becomes visible automatically, regardless of whether the user updates the profile again or not.
I truly appreciate your effort in getting us thus far, if you could address this final issue, I’d be really really happy!
Thanks so much in advance.
Kind regards, Philip
- Philip Strothmann on April 9, 2019 at 1:46 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22149
Dear Brajesh,
awesome, works exactly like I need it. Thanks so much, highly appreciated! 🙂
FYI: Obviously the link between user role & member type works only if the profile is resaved or changed. So I added the member type I needed batch wise to my users. The member types were then correctly assigned, however didn’t appear for all users on the frontend. Turns out I had to resave all profiles where a value for the other member type field (in my case background) had already been set. That was a bit of manual work, but now it works fine 🙂
Kind regards, Philip
- Philip Strothmann on April 8, 2019 at 5:14 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22116
Dear Brajesh,
perfect, works like a charm 🙂 Thanks so much, highly appreciated! Looking forward to the update on Member Types Pro then 😉
Kind regards, Philip
- Philip Strothmann on April 8, 2019 at 2:03 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22107
Dear Brajesh,
thanks for the explanation and yes, I thought that it might be due to such a limitation. In that case I still think it would be better to bring the user to the group wall instead of the single post entry. How do I change that? 🙂
Kind regards, Philip
- Philip Strothmann on April 8, 2019 at 1:12 pm in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22099
Dear Brajesh,
thanks for your message. On 3. Whenever someone posts an activity in the group, if I click on the “view activity” I am taken indeed to a single post view of that post but on the user’s activity wall, not on the group wall – which is probably the correct behavior as you designed it.
In my mind however it would make a lot more sense to take the user who clicked on the notification to the post in the context of the group in which it was posted. E.g. if I get a notification about a new post in a let’s say facebook group, I am also taken to that group and not to that users profile.
Kind regards, Philip
- Philip Strothmann on April 8, 2019 at 10:40 am in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #22096
Dear Brajesh,
any update on either or the two issues? 🙂
Kind regards, Philip
- Philip Strothmann on April 5, 2019 at 11:38 am in reply to: [Resolved] Assign additional Member Type per role but keep existing ones in separate field #21955