Hi. In the same 4 examples of databases like sqllite, postgresql, hash and other, in all of them you could do that, at the same way.
with out so many complications. the example just show, in a basis way how create at user group with admin could controle that, without many complication, indeed, you could use the same table at dspam actual model as Table A, then create the join table and the admin table who has the pointer to the join table, and then, seek for all id's in the join table who has that pointer, in this moment you had all users could be administered by this user. i'm affraid it's not a big deal for the codemasters of dspam. greetings. edgar On Sat, 05 Dec 2009 21:23:26 +0100, "Steve" <[email protected]> wrote: > -------- Original-Nachricht -------- >> Datum: Sat, 05 Dec 2009 17:06:53 -0300 >> Von: "Edgar Díaz Orellana" <[email protected]> >> An: [email protected] >> Betreff: Re: [Dspam-devel] Control multiple users from one login on >> web-ui > >> >> >> Hi. >> > Hello, > > >> I guess just create 3 tables on mysql engine, with only that you could >> create all type of group, users and joins. >> >> like >> >> Table A (Users) Table B (Joins ) Table C ( Groups ) >> r...@localhost [1] Admin (* all users) >> ad...@localhost [2] Admin (* all users) >> >> ad...@somedomain [3] 1 ad...@somedomain [4] >> j...@somedomain [5] 1 >> ot...@somedomain [6] 1 >> u...@somedomain [7] 1 >> otheru...@somedomain [8] 1 >> >> Then when ad...@somedomain [9] logons, could admin all users there could >> admin. >> >> and so on. >> >> Just think about >> > You think to narrow. Using MySQL is fine but what about the SQLite users? > What about the PostgreSQL users? And what about the users using the Hash > driver? (The one using a SQL based driver are easy to handle but Hash? > Hmm...) > > As I said before: Making a proper solution would require us to think about > it first and then do something that not only has the capability to be used > on the WebUI but can be used for the whole group (and user) management > currently implemented in DSPAM. > > For me hacking some SQL queries is as easy as 1-2-3. But it's not just > about me. We should think in bigger circles. > > But Paul's approach to wrap something around the current CGI script could > be a possible way in doing the hack while still not changing to much in the > original script. I have to take the time to think about it and look how I > could implement something like that without raping the original CGI script. > I will for sure NOT add it to stock DSPAM. Contrib would be the better > place for that. > > // Steve > >> On Sat, 05 Dec 2009 16:49:37 +0000, Paul Cockings wrote: >> >> Links: >> ------ >> [1] mailto:r...@localhost >> [2] mailto:ad...@localhost >> [3] mailto:ad...@somedomain >> [4] mailto:ad...@somedomain >> [5] mailto:j...@somedomain >> [6] mailto:ot...@somedomain >> [7] mailto:u...@somedomain >> [8] mailto:otheru...@somedomain >> [9] mailto:ad...@somedomain >> [10] http://my-dspam-install/manager.cgi >> [11] http://my-dspam-install/users.cgi >> [12] http://my-dspam-install/users.cgi >> [13] mailto:[email protected] >> [14] >> mailto:[email protected] ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ Dspam-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-devel
