| One other thing I did run into is that roles in my user source are a | separate table with a foreign key back to the username, rather than | space-separated as a column in the user table - for that reason, the default | SQL user source wouldn't work for me (since as it happens I do store the | crypt in the table at the moment - so near and yet so far). | | I probably could have done a fiendish CREATE VIEW... but I had about ten | minutes of downtime to get the site from 2.3 to 2.4.1! I'll take a look at | it again in a test setup.
The SQL Methods used are actually created inside the pgAuthSource Folder inside the acl_users. Should be pretty simple to do some sort of join, or alter the method inside pgAuthSource to fetch the roles seperately.
You just have to munge the roles into a list before returning out of the authSource though.
Hm... that'd be my next ask here at work. I am planning on building a new Generic SQL auth method that let's you specify what roles there are for a user using a one to many relationship model (actually a many to many relationship model). Also I want to break out the PostgreSQL dependencies, especially in the prop_source where both the field names and the table name are hardcoded in the python code. /dadrio