Note: This question applies to either DNN3 or DNN4.

Hello:

Accessible by the Host account, the Lists module has been a big help when I need to store reference or lookup information.  I would like to create a end-user version of this module which would be accessible to an admin of the site with the following aspects:
1) The admin would not be able to see the list data created by DotNetNuke.
2) The list data would not span across multiple portals.

To create such a module would be simple enough, but I would need to be able to group or catagorize the data in two ways:
1) Category for what is DNN created list data vs. admin list data entered by the end-user.
2) For the admin entered data only, what portal is this data for.

I see that there is a DefinitionID field and a Description field that I could use to accomplish this, but am not sure if DNN uses these fields, in which case I run the possibility of conflicting with DNN.  Has anyone used the Lists module and/or data in a custom way and know of any potential risks of doing so?  I am not too concerned about the need to backup and manage this extra data, which I plan on doing for any updates to the site when new releases of DNN are applied.  I thought of creating another list table with new stored procedures, etc., but see this as a bit redundant.

Thanks for your help and I hope I wasn't too confusing!

John

There has been made an enhancement to the lists table in DNN 4.5.0, to support lists per portal, see charles comment here, though I cannot find the associated Gemini item. I can see the portalID field in the lists table, but unfortunately, I cannot find an UI enelent to maintain portal specific lists.

Hi Vmasanas:
In versions prior to 4.5 there are two fields that do not appear to be used in the Lists table.  I was only asking if the use of these to fields, definitionid (I could stuff the portalid in), and description, which I could enter any value say, 'enduser', would cause any logic errors when using Host > Lists.  This solution could be considered a hack, and I would need to create a custom module, but it sounds feasible.  I will most likely move on to 4.5 for this and many other reasons.

Thanks!

John