I really do not understand the design of sec_users table generated by SECURITY module. Since this is not a sample App but rather fully functional add-on for SC to manage users etc. it should follow some simple design rules. For example sec_users table does have Primary Key but it is string key (at least when generated in MySQL) which is definitely not a god choice
I would like to opt-in to do some changes in the feature and make sec_… tables more professional.
ARTHUR
Yes please do. What features do u have in mind?
If i may suggest, reverse engineer the security related tables using MySQL workbench, then make changes that way. and share with us.
That is what I’m doing for some time already. I added several columns and it works but it is still pain on the but to deal with sec_ tables. The generated code for security modules operates on arrays. If you add any columns in front or between existing columns you will have to modify existing code (several places). The way it is designed is very inconvenient.
The main culprit is the lack of Primary Key based on INT() type column which makes this table very hard to link to any other table in the project.
User Login, password validation, assignment to the groups or Apps should be made based on Primary Key which should be INT(), NOT NULL, UNIQUE, AUTONUMBER
Yes at some pint I was thinking about creating completely new security App from scratch and sharing it with others so perhaps we could start a library of open projects and Apps which can be easily incorporated into everybody’s projects (as needed), but I’m not even sure if I stay with SC for to long because they are not making progress with the tool the way I expect (or I should say they do not listed to users needs but rather add what they think will be useful). On top of everything bugs management is just killing this product.
ARTHUR