[ic] password protection of categories

[johny brabo]

----- Original Message -----
From: Chris Rapier <rapier@psc.edu>

> How about this...
>
>You have users pick items that go into their own
>special catalog. You can do this by extending the
>user database to include product number specific
>to that user or create a new table keyed on the user
>name which contains catalog information. Now, when
>the user logs in with their password (you
>can check this easily - in mv it was mv_login I'm
>guessing its ic_login
>now if its true then do this if not bounce them to a
>login page) it reads this table and builds a catalog
>specifically from those items. Anything you can do in
>the main catalog you'd be able to do in this one. Its
>pretty easy actually once you start using fields from
>the user catalog as keys in the main product catalog.
>People wouldn't be able to view this user catalog
>without knowing the proper login name and password
>which would thus protect it

This actually makes a lot of sense. This seems a nice
solution wich I haven't thought of yet. Alhough it
solves the problem on a "per-user" basis.I think I
have the beginning of a solution to do this on a
"per-catalog" basis, so the administrator can easily
make a new password protected category: see bottom of
this mail.

>Whats even cooler is that if the row keyed on the
>user name is defined in the user catalog datebase
>then it will display products. If not then it will  
>display account information (address, billing, past
>orders and so forth)or some such thing like that.
>That way people can create a public catalog and a
>private account. You can also make it so that they
>can't create a public catalog without filling in all
>of the necessary account information by burying that
>process in the private account page.
>

I don't really get this. What exactly do you mean by
"if the row keyed on the user name is defined in the
user catalog database"? Do you mean that
it's possible to build pages based on the contents of
a user's database. That's also very nice, your email
allready suceeded in making me wanna scream
"eureka" much harder than archimedes when he
discovered his law :-)

>I hope some of this makes sense. I'm being a little
>disjointed with my descriptions.
>I've actually implemented a lot of this stuff in
>minivend. It not a difficult task once you really
>wrap your head around the way you
>actually access tables. You'll need to drop into
>perl for some of this
> but nothing major.
>
>Good luck.

This is a solution I figured out. I haven't tried it
out yet, I will only do
that in a few weeks, after figuring everything out and
then some snowboarding :-)

First I make a few results pages that are each build
from another productsdb: 

results1.html <- products1.txt
results2.html <- products2.txt
...

Now I can easily controll access to all these results
pages using the userdb-acl option from the docs: Their
acl record only get's set for a results page when they
entered a password they receive by normal mail:

[if value accesspassword=passwordreceivedbymail]
[userdb function=set_acl
location="pages/results1.html"]
[else] goto password-page
[/else]
[/if]

This has the advantages that the shop-administrator
can easily make a new category, and send the password
for it by normal mail. He can also reserve items for
this category. eg. he takes out 5 shirts from
products.txt and puts it in products1.txt (changing
only the sku, so that I have no problem with
quantities.

Now I only need to figure out how I can easily let the
admin copy items from one database to another, but I
think [export] is going to be of some help here. And
also how I can make this thing a little bit more easy
by not making 20 results pages but combining
everything in 1 page.

I hope all this makes sense, and maybe hear some
remarks on this.

thanks.







__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/