HI Kirk, thanks for taking the time to weigh-in on this… I’m in need of some clarification, see below:
> I include a field in the [Users] table for the database id and database > name. The significance of that value depends on the rules you set up for > yourself. I assume that these are arbitrary values…. How might you use this ID (Integer?) and the Database Name? I’m assuming that the scope is limited to this single database. > 1) You could say the 4D structure is the authority in which case if the > structure doesn't, or no longer, has that user's db id in it that [user] is > inactive and I'd clear the db id field. Are you looking for a [User]DB_ID in the structure? Clearing an ID from the structure? Okay, I think I understand now… Since the structure is the “authority” in this case I’m thinking you are using the 4D dialog and allow the user to login… you GET USER LIST then lookup the user_ID via user_name that was retrieved from Current User and then see if the user is in the [user] table? However, the more I think about it, I bet your perspective is coming from a custom dialog… where the [user] table could be used first and that the 4D users could still be the authority… > 2) Or you can take the other approach and say that every 'active' [user] > will have a 4D login and create any that are missing. Okay, that makes sense… > With #1 you can limit who can create users to who can get to EDIT USERS. WHAT?!? :) Please clarify what you mean here. > It's easy to… update the 4D user id… What do you mean by update the 4D user ID here... > The tricky part about creating 4D users is keeping out of the password > business. Part of my goal was to not have to manage passwords. I want users > to be responsible for that. But you still need some control. Plus when you > create a user you have to assign a password. My solution is to have a temp > password field in [users]. If a user has their password reset by admin, for > whatever reason, a temp password is assigned to the 4D user and saved in > the [user] record. My rule is 'the next time you log in with the temp > password you have to change it.’ Great Idea! With this current DB the Admin is managing users and passwords via “Edit Access”. Only about 10 users but I suppose the Admin knows everyone’s PW. > This is where USERS TO BLOB and BLOB TO USERS comes in. These > commands preserve the 4D user passwords. To allow me to update the > structure I save the users with USERS TO BLOB every time the server shuts > down. And then every time is starts up I look for the user blob and call > BLOB TO USERS. So in this case where you USERS TO BLOB and BLOB TO USERS, is the 4D structure the authority? How was it originally populated? I can see it starting from [users] that updated 4D or where the Admin created a bunch of users that got synced to [users] or where no users table was used at all since it could be maintained in 4D if you needed no additional user info stored and if you were not using your password reset feature. I very much appreciate your detailed post—for some reason I’m having trouble getting full clarity. Thanks, Robert ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
