Hi there,
Sorry if this is utterly a trivial query; please shed me some light on how-to or reference video / info as I can't seem to find any that provides exact detail.
I have a "Membership" Object with various fields that each record represents one 'person'.
I'd like to have that 'person' be able to login. They would each have their UserRole so not everyone will be able to access the same amount of data the same way.
How can I accomplish the User Login to this "Membership" Object? I don't want to recreate the fields but I can't seem to map the relevant "Membership" Object fields to the UserRole objects.
Is this something you not do?
Many thanks!
jintak
Hi Craig,
Many thanks for your elaboration. I guess my situation would be very similar to your swimmer object example. like your swimmers who don't sign in, I have also students who are under the Member User Role. However I need a separate "Membership" Object to keep track of the financials, so similar to your Cash-Account object, I need the "Membership" object to elaborate their details. So Members User Role and Membership Object should be 1:1 whereas Students Object to Membership Object are 1:many. What you are saying is, the detail of the user logging in should be at the User Role item, rather than the Objects items; isn't it?
I guess if Member User Role and Membership Object have 1:1 relationship, then the fields could be in either one, then I may not need Membership Object altogether..... But, if I also need Instructor User Role since they will be accessing to a different set of App functions, ...... can this still hold valid? Or am I making my self too complicated?
So as far as the sign ons, Admins, Members, and Instructors will have different page to login and perform. However they all should have the same fields to identify themselves.
In this case, should the fields to identify a person be under User Role or Object? I'm still confused...
responses:
1. Under User Roles section I have Member and Administrator. These two objects reflect my two different roles. And, generally, yes, the fields for these objects (user roles) should be created here. Eg. My member object has a photo field and a text field for 'historical notes'. These are now properties of my Members.
And this was NOT obvious to me at first when I started using Knack.
2. Now, I have a swimmer object (name, swim level, etc). A Member is RELATED to many Swimmers. Swimmers are not users however, so the swimmer is just a regular object in the data section of the UI. That is, only my Members can log in, my swimmers do not log in.
or another example, Members have cash balances. So I create an object called Cash-Account with fields (date, amount, comment, etc). Then I related Member to Cash-Account. This is a 1 to many relationship. Finally, I create a SUM calculated field in the Member account which is the SUM of the Cash-Account.Amount field. Now I know how much each member owes me.
Hi Craig,
Thanks for your quick response. A couple of questions, if I may.
1. When you say "Objects will be created for each new User Role", you mean that a 'User Role' object will be created under the User Roles pane in Data tab, am I correct? For example, what I have now is Membership under User Roles section, and under Membership I have Admin, Member, and Instructor. Are you saying the fieelds for each 'person' whether or not they are Admin, Member, or Instructor, the 'person' related fields should be created under the Membership 'User Role' object?
2. In the meantime I had searched the other side of web and I found some tutorials that inspires adding a Connection to User Roles from Objects, so that in each of the respective Object, I have a connection to Membership 'User Roles' object. This seems to be the opposite to what you are suggesting (am I correct in saying so?). If so, what would be the difference between these two approaches?
Many thanks!
jintak
To create new user 'roles' create new User Roles (on the data tab near the bottom). For each new User Role and new object shows up. The default is just 'Accounts' but you can then add (in my case) 'Member' roles and 'Administrator' roles.
Then in these objects add all the other properties (fields) you wish to associate with a user. Eg Address, or MembershipLevel or whatever.
You'll notice that these user objects all have a property called 'User Roles'. It is this property which you change to adjust the role of a user. So if I want an account to be an administrator, I add the 'Administrator' role to this account's User Roles field.
So, I'm not sure exactly what you have right now but I suspect you have a membership object when really you need a membership 'user role'. (so yeah, you have a delete the membership object) and recreate all the properties in a membership user role.