Robert, 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.
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. And if there is no [user] for a 4D user I'd add a record. 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. With #1 you can limit who can create users to who can get to EDIT USERS. It's easy to create [users] as you need or update the 4D user id but not easy to link up the 4D user with [users] if they are created already. I prefer #2. But either way works depending on what you need to do. 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.' You can see if this password was used when the user logs in with VALIDATE PASSWORD using that password. If it validates it means they used it and you can prompt them to changed it. What you can't do is get the password from the 4D user. So while you can create 4D users easily you blow out the old passwords if you update the structure. 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. This is great if you have a number of installations with their own users but you need to update the structure. On Wed, Nov 14, 2018 at 11:36 AM Robert ListMail via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Kirk, what was your method of keeping use rand 4d recs in sync? > > Thanks, > > R > > > On Sep 2, 2016, at 10:52 AM, Kirk Brooks <lists.k...@gmail.com> wrote: > > > > You have to explicitly > > offer some way to log in as a different 4D user or, as I eventually did, > > tie my user records to a 4D user. > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
