The app I’m building is loyalty based, having everyday users and vendors, but allowing these vendors to also register and login. Currently I have User things and Vendor things (2 tables), but I’m having an issue with the vendor registration and login process that’s interfering down the line.
Vendors still need to register and login, referring to the vendor table. Therefore, I’m assuming I cannot use the ‘sign up or Log the user in’ functions and instead need to use the “create a new thing” option for vendor registration. Is this correct?
For logging in this vendor what exactly should I be doing that confirms that they are logged in? Should the way here be to use the “Make changes to a thing” option and create a “Signed in” field with Yes or No as an option in the table?
Once this vendor is logged in, my intention is to allow this 1 vendor access to their own vendor profile page and update if necessary (such as their vendor website). This website field is set to a “Current Page Vendors” “Website” text field and a separate input field to update it, but no vendors data is present, suggesting that the vendor login has not been successful.
This seems like it should be simple to do and I’ve looked over the forum and documentation, but it’s just confusing me further. Can anyone help with the above?
I’ve done similar things in the past, but always end up coming back to using the User object to reference Users, and having different “Roles” that the User can belong to. I may be a Vendor, but to manage my account and login and such, I’m really just a User.
I’d think about this type of logic chain: I’m a user with the Vendor Role. I belong to Vendor Company (or the Vendor Company belongs to me, whichever). When I navigate to the Vendor Profile page, use the data from the Vendor Company that belongs to me.
Thanks for your reply, so in short, the user table should be split between everyday users (say consumers) and vendors under the heading ‘Role’. So I’m guessing then I would split to 2 login pages, a consumer page and a vendor page and use the “Only When” function to login that role on the correct page. Only When Role = Consumer / Only When Role = Vendor
Based on this, am I correct in thinking that the Sign Up/Login User functions can only work with the USER data type and not on another? Hence why your approach is preferable?
I’m not against this, but the vendor data fields I have is extensive in comparison to a consumer and it’s natural to want to keep them apart.
Excuse the way I’m describing things, this whole logical approach to doing things is completely different to how I’ve lived most of my life
I am looking at the same items. I will have 4 user types eventually with their own information. I have been trying to figure out what is the best method and all I see is building 4 user data types, then upon login create “4 pages” or 4 different login areas. Basically a page geared to that user type they could bookmark for later access, thus using their user type on the platform without any issues as it’s all separate.
How did you end up finishing up solving your issues?