take a look at tony's multiple file attribute in the mp, thats a good stepping stone i guess

Where is that? I searched the forum and his site, found nothing.

mp=marketplace

Thank you. Had a look at it. It's using simple attributes, just like the others in Concrete.
What I need to do is something different. I'll try to explain in detail.
Say I want to create a new attribute type called DatabaseAttributeType. To use this attribute, you'll have to choose a Table name (say Users) and Column name (say uName).
Once assigned, it will list the field values and allows to choose from.
This can apply to anything, like eCommerce products, pages.. etc.

Did you ever figure this out? I'm trying to create a Select attribute that lists all the users in the database. Right now, I have to manually add new users to a standard select attribute...

> I'm trying to create a Select attribute that lists all the users in the database.
> Right now, I have to manually add new users to a standard select attribute...

Where/how will that select attribute (list of users) be used? To which "type" of object (user, collection, or file) does it pertain?

Perhaps my add-on would suit your needs...

http://www.concrete5.org/marketplace/addons/enhanced-user-list/...

It allows you to place a customizable list of users anywhere on any page of your site.

-Steve

Basically, I'd like to list on each user's profile page all the other pages throughout the site that have been "tied" to that particular user. These wouldn't be pages for which they're the owner, but just content that in some way relates to that user. There will be pages that would appear on several profile pages. so my first thought was a select-multi attribute that pulls its options from the database users table...

Thanks

> I'd like to list on each user's profile page all the other pages throughout the site
> that have been "tied" to that particular user.

So, what you want is a page list - not a user list. Is that right? And you want to filter the pages by one or more criteria such that only pages which are somehow "related" to a specific user appear in the list? Is that right?

So then, are you saying that the select attribute is a collection attribute and not a user attribute? And that one or more specific users will be manually chosen for each and every page created on the site?

-Steve

Not exactly.

Suppose in the Dashboard, under Users and Groups, I have User 1, User 2, etc.

When I'm adding pages throughout the site, I wanted to have an attribute where I could select the names of one or more users. (See attached.) Those select options would be populated by the database, so that as new users are added, they'll appear as options in this attribute.

On the profile page for each user (eg., mydomain.com/index.php/profile/3/), I'm currently displaying all the User Attributes that are part of the record. I would like to then display a list of all pages where this user's name has been selected.

Am I approaching this wrong? If there's a better way to do this, I'm certainly open to suggestions.

Thanks.

> Not exactly.
> Suppose in the Dashboard, under Users and Groups, I have User 1, User 2, etc.
> When I'm adding pages throughout the site, I wanted to have an attribute where
> I could select the names of one or more users.

In fact, that is what I described. You want a collection (i.e. page) attribute of type "select" which lists all the users in the system, and the page list on each user's profile page will be filtered to show only pages "linked to" the user whose profile is being viewed. In that case, the add-on I referenced won't help.

In other words, you want to establish a many-to-many relationship between users and pages -- i.e. a user can be associated with more than one page and a page can be linked to more than one user -- right? If so, following are some things to consider:

1) You'd have to handle pagination if the list of users grows very large.
2) While you'll probably want the user names to appear in the list, you should store the user ID as the actual key. (IOW, you don't want the pages tied to user name or email, both of which can change.)

For those two reasons alone, I don't think a "select" type attribute is the best choice. Seems like a custom attribute/solution is in order. If you're an experienced C5 developer and you're feeling adventurous, there is something in the core called a "Pile" which is not well documented but might be worth examining. The comments in the code state:

"Essentially a user's scrapbook, a pile is an object used for clumping bits of content together around a user account. Piles currently only contain blocks but they could also contain collections. Any bit of content inside a user's pile can be reordered, etc... although no public interface makes use of much of this functionality."

-Steve

Thanks again. The thought of that list getting long had occurred to me. For this site, there aren't going to be more than 15-20 users, but I definitely see the downside to this approach...

It looks like this Pile object is barely documented at all. But I'll read through the code and see if I can make sense of it.