[geeklog-devtalk] geeklog-devel digest, Vol 1 #452 - 8 msgs

geeklog-devel-request at lists.geeklog.net geeklog-devel-request at lists.geeklog.net
Wed Dec 15 17:42:01 EST 2004

Previous message: [geeklog-devtalk] geeklog-devel digest, Vol 1 #451 - 8 msgs
Next message: [geeklog-devtalk] geeklog-devel digest, Vol 1 #453 - 6 msgs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Send geeklog-devel mailing list submissions to
geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."

Today's Topics:

1. Re: Custom user attributes in GL2 (dwight at trumbower.com)
2. Re: Filtering in GL2 (Dirk Haun)
3. Re: Custom user attributes in GL2 (Vincent Furia)
4. Re: Filtering in GL2 (Tony Bibbs)
5. Re: Custom user attributes in GL2 (Tony Bibbs)
6. Re: Custom user attributes in GL2 (dwight at trumbower.com)
7. Draft of schema for GL2 (Tony Bibbs)
8. Re: Custom user attributes in GL2 (Tony Bibbs)

--__--__--

Message: 1
Date: Wed, 15 Dec 2004 16:16:44 -0500 (EST)
Subject: Re: [geeklog-devel] Custom user attributes in GL2
From: dwight at trumbower.com
To: geeklog-devel at lists.geeklog.net
Reply-To: geeklog-devel at lists.geeklog.net

The easiest way I know of, one table.

column name - String
column type - specifies, long, int, string ect
column data - data as a string

Might need xref table to show where it is used. At least this is how would
start.

> Anybody have any input on how to best address providing the community

> with fairly easy way to add custom attributes for users in GL2?

>

> I don't I have a good idea on how to do this. My hopes are that plugins

> would have their own one-to-one mapping from the core user table to

> their own user table with addition information. Assuming that is OK,

> how do we handle things the site admin simply wants to add (e.g. msn id,

> pgp key, etc).

>

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>

--__--__--

Message: 2
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Filtering in GL2
Date: Wed, 15 Dec 2004 22:21:09 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony,

>Quote handling in GL2 should be transparent to the developer. Recall

>that all custom SQL goes into a named query file and that the SQL that

>goes in there should use prepared SQL as opposed to the kind of SQL

>found in 1.3.x.

What about SQL injection attempts then?

There's several sorts of filtering that have to be done, and ideally (I
think), they should be handled by different "entities" (for lack of a
better word), as opposed to the all-in-one approach that 1.3's
COM_applyFilter implements.

I.e. an SQL request should be parsed for injections / malformed SQL by
the entity that handles SQL (would that be Propel then or Creole?).

JavaScript, unwanted HTML, etc. should be handled by the module that
handles the post (or whatever data is being processed), as it may be
acceptable for one module, but unacceptable for another.

bye, Dirk

--
http://www.haun-online.de/
http://geeklog.info/

--__--__--

Message: 3
Date: Wed, 15 Dec 2004 16:57:58 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net

I'm with Dwight. This way all user data is in one place (and the
plugins can put user data there as well).

-Vinny

On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com
<dwight at trumbower.com> wrote:

> The easiest way I know of, one table.

>

> column name - String

> column type - specifies, long, int, string ect

> column data - data as a string

>

> Might need xref table to show where it is used. At least this is how would

> start.

>

>

> > Anybody have any input on how to best address providing the community

> > with fairly easy way to add custom attributes for users in GL2?

> >

> > I don't I have a good idea on how to do this. My hopes are that plugins

> > would have their own one-to-one mapping from the core user table to

> > their own user table with addition information. Assuming that is OK,

> > how do we handle things the site admin simply wants to add (e.g. msn id,

> > pgp key, etc).

> >

> > --Tony

> > _______________________________________________

> > geeklog-devel mailing list

> > geeklog-devel at lists.geeklog.net

> > http://lists.geeklog.net/listinfo/geeklog-devel

> >

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>

--__--__--

Message: 4
Date: Wed, 15 Dec 2004 16:17:22 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Filtering in GL2
Reply-To: geeklog-devel at lists.geeklog.net

My response is below.

Dirk Haun wrote:

>What about SQL injection attempts then?

>

>There's several sorts of filtering that have to be done, and ideally (I

>think), they should be handled by different "entities" (for lack of a

>better word), as opposed to the all-in-one approach that 1.3's

>COM_applyFilter implements.

>

>I.e. an SQL request should be parsed for injections / malformed SQL by

>the entity that handles SQL (would that be Propel then or Creole?).

>

>JavaScript, unwanted HTML, etc. should be handled by the module that

>handles the post (or whatever data is being processed), as it may be

>acceptable for one module, but unacceptable for another.

>

>

That's understandable. However, it is worth noting a few things:

1) As a GL2 standard, any custom sql (i.e. that not automatically
created by propel) must be in a prepared statement format. This
standard automatically makes GL2 less vulnerable (read the section "Why
use prepared statements" on this page:

http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html

Now, I realize this is MySQL specific and I hope to maintain DB
independence but nearly all 'real' DBMS support some form of prepared
statements.

2) Saving using the save() method on the Propel generated domain objects
all get converted to prepared statements. So, not to be naive, SQL
injection may still be possible but it should be considerably harder for
a programmer in GL2 to allow for such a thing to happen.

That only takes care of, to a large degree, SQL injections. All your
other points are valid and I think that having a single class with a
bunch of atomic filter methods for various things (i.e. javascript,
html, etc) makes sense at the kernel level...not necessarily at the
plugin level. I only say that because if we have at least a base
filtering class in the kernel, each plugin can override it as needed (in
fact, I think this makes sense as a 1.3.x enhancement).

And if I heard right, Blaine will be doing a draft of this class, no?

--Tony

--__--__--

Message: 5
Date: Wed, 15 Dec 2004 16:24:09 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net

I'm fine with data driving the custom user stuff..l

I would still say, though, you'd want real columns in the GL2 user table
for thing we know we need (i.e. username, password, etc) for performance
reasons alone, right? Regardless, going this route will make the use of
Propel a little bit messy as the user class generated by propel won't
know anything about the custom attributes in the database.

Also, for clarity, are you suggesting we do this for all plugin specific
user attributes? I don't think you are and if you are we probably want
to discuss the pros/cons between that and having a plugins specific user
table with a one-to-one relationship with the kernel user table.

--Tony

Vincent Furia wrote:

>I'm with Dwight. This way all user data is in one place (and the

>plugins can put user data there as well).

>

>-Vinny

>

>

>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com

><dwight at trumbower.com> wrote:

>

>

>>The easiest way I know of, one table.

>>

>>column name - String

>>column type - specifies, long, int, string ect

>>column data - data as a string

>>

>>Might need xref table to show where it is used. At least this is how would

>>start.

>>

>>

>>

>>

>>>Anybody have any input on how to best address providing the community

>>>with fairly easy way to add custom attributes for users in GL2?

>>>

>>>I don't I have a good idea on how to do this. My hopes are that plugins

>>>would have their own one-to-one mapping from the core user table to

>>>their own user table with addition information. Assuming that is OK,

>>>how do we handle things the site admin simply wants to add (e.g. msn id,

>>>pgp key, etc).

>>>

>>>--Tony

>>>_______________________________________________

>>>geeklog-devel mailing list

>>>geeklog-devel at lists.geeklog.net

>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>

>>>

>>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>

>>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>

>

--__--__--

Message: 6
Date: Wed, 15 Dec 2004 17:36:01 -0500 (EST)
Subject: Re: [geeklog-devel] Custom user attributes in GL2
From: dwight at trumbower.com
To: geeklog-devel at lists.geeklog.net
Reply-To: geeklog-devel at lists.geeklog.net

Ok, I'm confused. I don't see username and password as custom attributes.

Custom attributes are usually used to enhance the base package and allow
customers to add a few fields of data to customize a screen. The old days,
you just created 5-10 fields, called user1, user2,...user10. So every
table had 10 extra fields.

The new way puts only the fields you want in a combined table, just like
your List Of Values(LOV) table.

The hard part is displaying these fields. The easiest way is to have them
all grouped together at the end of a screen. Know when people want to move
them around in different places, it gets tricky.

Also if you need to handle select option fields, radio fields and check
box fields there will need some more supporting tables.

Dwight

> I'm fine with data driving the custom user stuff..l

>

> I would still say, though, you'd want real columns in the GL2 user table

> for thing we know we need (i.e. username, password, etc) for performance

> reasons alone, right? Regardless, going this route will make the use of

> Propel a little bit messy as the user class generated by propel won't

> know anything about the custom attributes in the database.

>

> Also, for clarity, are you suggesting we do this for all plugin specific

> user attributes? I don't think you are and if you are we probably want

> to discuss the pros/cons between that and having a plugins specific user

> table with a one-to-one relationship with the kernel user table.

>

> --Tony

>

> Vincent Furia wrote:

>

>>I'm with Dwight. This way all user data is in one place (and the

>>plugins can put user data there as well).

>>

>>-Vinny

>>

>>

>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com

>><dwight at trumbower.com> wrote:

>>

>>

>>>The easiest way I know of, one table.

>>>

>>>column name - String

>>>column type - specifies, long, int, string ect

>>>column data - data as a string

>>>

>>>Might need xref table to show where it is used. At least this is how

>>> would

>>>start.

>>>

>>>

>>>

>>>

>>>>Anybody have any input on how to best address providing the community

>>>>with fairly easy way to add custom attributes for users in GL2?

>>>>

>>>>I don't I have a good idea on how to do this. My hopes are that

>>>> plugins

>>>>would have their own one-to-one mapping from the core user table to

>>>>their own user table with addition information. Assuming that is OK,

>>>>how do we handle things the site admin simply wants to add (e.g. msn

>>>> id,

>>>>pgp key, etc).

>>>>

>>>>--Tony

>>>>_______________________________________________

>>>>geeklog-devel mailing list

>>>>geeklog-devel at lists.geeklog.net

>>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>>

>>>>

>>>>

>>>_______________________________________________

>>>geeklog-devel mailing list

>>>geeklog-devel at lists.geeklog.net

>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>

>>>

>>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>

--__--__--

Message: 7
Date: Wed, 15 Dec 2004 16:38:22 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Draft of schema for GL2
Reply-To: geeklog-devel at lists.geeklog.net

This is a multi-part message in MIME format.
--------------090608010507060008080606
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Here is the database creates for GL2. NOTE: this does not work in MySQL
yet...I tried it and got a few bugs to work out but I'm sending it more
for conversation than actual use. Tomorrow I will work those kinks out
and generate the first Propel classes from them.

Please review and critique...

--Tony

--------------090608010507060008080606
Content-Type: text/plain;
name="create.sql"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="create.sql"

CREATE TABLE gl2_list_of_values (
lov_id int unsigned NOT NULL auto_increment,
group_name varchar(30) NOT NULL,
short_name varchar(40) NOT NULL,
description varchar(128),
enabled tinyint NOT NULL DEFAULT 1,
sort_order mediumint NOT NULL DEFAULT '0',
PRIMARY KEY (lov_id),
INDEX (group_name),
INDEX (short_name),
INDEX (enabled)
) TYPE=INNODB;

CREATE TABLE gl2_event (
event_id int unsigned NOT NULL auto_increment,
event_name varchar(40) NOT NULL,
description varchar (255) NOT NULL,
PRIMARY KEY(event_id),
INDEX(event_name)
) TYPE=INNODB;

CREATE TABLE gl2_plugin (
plugin_id int unsigned NOT NULL auto_increment,
plugin_name varchar(128) NOT NULL,
version varchar(20) NOT NULL,
homepage varchar(128) NOT NULL,
enabled tinyint unsigned NOT NULL DEFAULT 1,
PRIMARY KEY(plugin_id),
INDEX(plugin_name),
INDEX(enabled)
) TYPE=INNODB;

CREATE TABLE gl2_eventListener (
event_id int unsigned NOT NULL,
plugin_id int unsigned NOT NULL,
PRIMARY KEY(event_id, plugin_id),
FOREIGN KEY (event_id) REFERENCES gl2_event(event_id),
FOREIGN KEY (plugin_id) REFERENCES gl2_plugin(plugin_id)
) TYPE=INNODB;

CREATE TABLE gl2_user (
user_id int unsigned NOT NULL auto_increment,
registration_date int unsigned NOT NULL,
profile_views mediumint unsigned NOT NULL DEFAULT 0,
items_per_page tinyint unsigned NOT NULL DEFAULT 10,
language_id int unsigned NOT NULL,
user_name varchar(25) NOT NULL,
password varchar(35) NOT NULL,
enabled tinyint unsigned NOT NULL,
email VARCHAR(128) NOT NULL,
comment_mode_id int unsigned NOT NULL,
comment_order_id int unsigned NOT NULL,
comment_limit tinyint unsigned NOT NULL default '0',
cookie_timeout int unsigned NOT NULL,
locale varchar(3),
date_format_id int unsigned NOT NULL,
blocks_enabled tinyint unsigned DEFAULT 1,
PRIMARY KEY(user_id),
INDEX (user_name),
INDEX (enabled),
INDEX (email),
FOREIGN KEY (comment_mode_id) REFERENCES gl2_list_of_values(lov_id),
FOREIGN KEY (comment_order_id) REFERENCES gl2_list_of_values(lov_id),
FOREIGN KEY (date_format_id) REFERENCES gl2_list_of_values(lov_id)
) TYPE=INNODB;

CREATE TABLE gl2_user_supp (
user_id int unsigned NOT NULL,
signature varchar(128),
biography text,
first_name varchar(30),
last_name varchar(30),
homepage varchar(50),
PRIMARY KEY(user_id),
FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),
) TYPE=INNODB;

CREATE TABLE gl2_group (
group_id int unsigned NOT NULL auto_increment,
logical_name varchar(30) NOT NULL,
display_name varchar(50) NOT NULL,
description varchar(255) NOT NULL,
) TYPE=INNODB;

CREATE TABLE gl2_privilege (
code varchar(30) NOT NULL,
description varchar(255) NOT NULL,
PRIMARY KEY(code)
) TYPE=INNODB;

CREATE TABLE gl2_privilege_access (
code varchar(30) NOT NULL,
user_id int unsigned,
group_id int unsigned,
INDEX(code),
FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),
FOREIGN KEY(group_id) REFERENCES gl2_group(group_id)
) TYPE=INNODB;

CREATE TABLE gl2_group_assignment (
main_group_id int unsigned NOT NULL,
assigned_user_id int unsigned,
assigned_group_id int unsigned,
FOREIGN KEY(main_group_id) REFERENCES gl2_group(group_id),
FOREIGN KEY(assigned_user_id) REFERENCES gl2_user(user_id),
FOREIGN KEY(assigned_group_id) REFERENCES gl2_group(group_id)
) TYPE=INNODB;

CREATE TABLE gl2_ban (
ban_id int unsigned NOT NULL auto_increment,
user_id int unsigned,
ip_address varchar(11),
start_date int unsigned NOT NULL,
end_date int unsigned NOT NULL,
reason_id int unsigned NOT NULL,
PRIMARY KEY(ban_id),
FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),
FOREIGN KEY(reason_id) REFERENCES gl2_list_of_values(lov_id)
) TYPE=INNODB;

CREATE TABLE gl2_catalog (
catalog_id mediumint unsigned NOT NULL auto_increment,
catalog_name varchar(50) NOT NULL
date_created int unsigned NOT NULL
) TYPE=INNODB;

CREATE TABLE gl2_category (
category_id mediumint unsigned NOT NULL,
catalog_id mediumint unsigned NOT NULL,
category_name varchar NOT NULL,
parent_category_id mediumint unsigned NOT NULL,
image_url VARCHAR(128) DEFAULT 'NULL',
sort_num tinyint unsigned DEFAULT NULL,
enabled tinyint unsigned NOT NULL DEFAULT 1,
owner_id int unsigned NOT NULL,
group_id mediumint unsigned NOT NULL,
owner_permissions tinyint unsigned NOT NULL,
anon_permissions tinyint unsigned NOT NULL,
member_permissions tinyint NOT NULL,
group_permissions tinyint NOT NULL,
FOREIGN KEY (catalog_id) REFERENCES gl2_catalog(catalog_id),
INDEX (enabled)
) TYPE=INNODB;

CREATE TABLE gl2_item (
item_id int unsigned NOT NULL auto_increment,
type_id int unsigned NOT NULL,
user_id int unsigned NOT NULL,
category_id INT unsigned NOT NULL,
date_created int unsigned NOT NULL,
num_views mediumint unsigned NOT NULL DEFAULT 0,
state_id int unsigned NOT NULL,
num_emails mediumint unsigned NOT NULL DEFAULT 0,
num_ratings mediumint unsigned NOT NULL DEFAULT 0,
rating_sum int unsigned NOT NULL DEFAULT 0,
expiration_date int unsigned DEFAULT NULL,
parent_item_id int unsigned DEFAULT NULL,
PRIMARY KEY(item_id),
FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id),
FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),
FOREIGN KEY(category_id) REFERENCES gl2_catgory(category_id),
FOREIGN KEY(state_id) REFERENCES gl2_item_type_state(state_id),
FOREIGN KEY(parent_item_id) REFERENCES gl2_item(item_id)
) TYPE=INNODB;

CREATE TABLE gl2_item_acl (
acl_id int unsigned NOT NULL auto_increment,
item_id int unsigned NOT NULL,
user_id int unsigned,
group_id int unsigned,
rights smallint unsigned NOT NULL,
PRIMARY KEY(acl_id),
FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),
FOREIGN KEY(user_id) REFERENCES gl2_user(user_id),
FOREIGN KEY(group_id) REFERENCES gl2_group(group_id)
) TYPE=INNODB;

CREATE TABLE gl2_comment (
comment_id int unsigned NOT NULL auto_increment,
item_id int unsigned NOT NULL,
subject varchar(50) NOT NULL,
comment_text text NOT NULL,
parent_id int unsigned,
ip_address varchar(11) NOT NULL
PRIMARY KEY(comment_id),
FOREIGN KEY(item_id) REFERENCES gl2_item(item_id),
FOREIGN KEY(parent_id) REFERENCES gl2_comment(comment_id)
) TYPE=INNODB;

CREATE TABLE gl2_item_type_state (
state_id int unsigned NOT NULL auto_increment,
type_id int unsigned NOT NULL,
state_name varchar(30) NOT NULL,
description varchar(255),
PRIMARY KEY(state_id),
FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id)
) TYPE=INNODB;
--------------090608010507060008080606--

--__--__--

Message: 8
Date: Wed, 15 Dec 2004 16:41:15 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Custom user attributes in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Your saying the same thing I am. I was bit confused by Vinny's response
which sounded a bit like (put everything in there) which I am guessing
he didn't mean but I wanted to be perfectly clear on. I think your
table will be more complicated...you'll probably want things like
min/max values, required indicators, etc. That's in addition to the
ability to choose from a finite set of values.

The more I think about it, the more I think we might want to delay doing
anything with customer user attributes until we get to a point where the
kernel is up and plugins are being written. Thoughts?

--Tony

dwight at trumbower.com wrote:

>Ok, I'm confused. I don't see username and password as custom attributes.

>

>Custom attributes are usually used to enhance the base package and allow

>customers to add a few fields of data to customize a screen. The old days,

>you just created 5-10 fields, called user1, user2,...user10. So every

>table had 10 extra fields.

>

>The new way puts only the fields you want in a combined table, just like

>your List Of Values(LOV) table.

>

>The hard part is displaying these fields. The easiest way is to have them

>all grouped together at the end of a screen. Know when people want to move

>them around in different places, it gets tricky.

>

>Also if you need to handle select option fields, radio fields and check

>box fields there will need some more supporting tables.

>

>

>Dwight

>

>

>

>

>

>>I'm fine with data driving the custom user stuff..l

>>

>>I would still say, though, you'd want real columns in the GL2 user table

>>for thing we know we need (i.e. username, password, etc) for performance

>>reasons alone, right? Regardless, going this route will make the use of

>>Propel a little bit messy as the user class generated by propel won't

>>know anything about the custom attributes in the database.

>>

>>Also, for clarity, are you suggesting we do this for all plugin specific

>>user attributes? I don't think you are and if you are we probably want

>>to discuss the pros/cons between that and having a plugins specific user

>>table with a one-to-one relationship with the kernel user table.

>>

>>--Tony

>>

>>Vincent Furia wrote:

>>

>>

>>

>>>I'm with Dwight. This way all user data is in one place (and the

>>>plugins can put user data there as well).

>>>

>>>-Vinny

>>>

>>>

>>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com

>>><dwight at trumbower.com> wrote:

>>>

>>>

>>>

>>>

>>>>The easiest way I know of, one table.

>>>>

>>>>column name - String

>>>>column type - specifies, long, int, string ect

>>>>column data - data as a string

>>>>

>>>>Might need xref table to show where it is used. At least this is how

>>>>would

>>>>start.

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>

>>>>>Anybody have any input on how to best address providing the community

>>>>>with fairly easy way to add custom attributes for users in GL2?

>>>>>

>>>>>I don't I have a good idea on how to do this. My hopes are that

>>>>>plugins

>>>>>would have their own one-to-one mapping from the core user table to

>>>>>their own user table with addition information. Assuming that is OK,

>>>>>how do we handle things the site admin simply wants to add (e.g. msn

>>>>>id,

>>>>>pgp key, etc).

>>>>>

>>>>>--Tony

>>>>>_______________________________________________

>>>>>geeklog-devel mailing list

>>>>>geeklog-devel at lists.geeklog.net

>>>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>>>

>>>>>

>>>>>

>>>>>

>>>>>

>>>>_______________________________________________

>>>>geeklog-devel mailing list

>>>>geeklog-devel at lists.geeklog.net

>>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>>

>>>>

>>>>

>>>>

>>>>

>>>_______________________________________________

>>>geeklog-devel mailing list

>>>geeklog-devel at lists.geeklog.net

>>>http://lists.geeklog.net/listinfo/geeklog-devel

>>>

>>>

>>>

>>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

>>http://lists.geeklog.net/listinfo/geeklog-devel

>>

>>

>>

>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>

>

--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel

End of geeklog-devel Digest

Previous message: [geeklog-devtalk] geeklog-devel digest, Vol 1 #451 - 8 msgs
Next message: [geeklog-devtalk] geeklog-devel digest, Vol 1 #453 - 6 msgs
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the geeklog-devtalk mailing list