Hi Al,
I spent quite a few days with Groupware of v15 and older. Tried to understand it, tried to remove some bugs and to add a few features. One of the problems is the Groupware analysis because one cannot have two analysises open at the same time, the project's analysis AND the Groupware's analysis. I never succeeded in moving the internal component "Groupware" with all of its features into a project's analysis. I decided to have my own "Groupware" and I wrote it.
- Users of my programs easily can switch from HFSQL Classic to HFSQL C/S. Groupware has to switch with it. Switching happens on basis of a HF7-connection, not on a simple HOpen(..)
- Administrators should be able to switch off Groupware completely while they would have the choice of using the protection of an admin-password for a few windows, especially those who're dealing with Groupware and sensitive data.
- Users and admins should be able to change their own password (= hash") - if the user's data allow for doing so. Only the logged-in user/admin can change the password.
- encryption of passwords is not good enough anymore and therefore is "old school". Hashing is the way to go. Salting the hashes is even better. See:
https://crackstation.net/hashing-security.htm
- I wanted to record the computer's name and the IP-address of the log-in.
- I wanted to know not only the log-in time but the log-out-time as well. A session-GUID does the trick. If the main window is closed without log-off then the Groupware's History file will be either empty or record an abnormal log-out.
- I wanted to unify the naming mix of "Admin" and "Supervisor" in PCS Groupware. "Supervisor" is Novell Netware slang while Microsoft is using "Administrator". I decided to go with admin.
- Since our programs are used by rather small audiences, maximum user count is about 50, so I happily left the complicated rights theater (in PCS Groupware a user can be member of several groups with different rights). Our users are rather simple-minded and wouldn't understand that anyway. A user is member of a group and the group has a number of rights, that's it. Administrators are members of of the admin-group and cannot be restricted in their rights. I neither need Windows authentification nor that of an Active Directory.
- I started out with rights management down to the control level but soon found out that handling such a diversity is no good for our customers, they simply don't understand the hidden complexity of the concept. This led me to let them stop unwanted access at menu-level only.
- Theoretically, Groupware should be usable in Java, Universal Windows 10 Apps etc too. The claim of platform-independency stops with WINDEV Java applications already. Ok, ok, my Groupware is for Windows apps only.
Kind regards,
Guenter Predl
office@windev.at
Edited 1 time(s). Last edit at 08/17/2019 09:33AM by gpredl.