• Welcome to KonaKart Community Forum. Please login or sign up.
 

Creating manufacturer logins to load their own products

Started by egreenplace, January 24, 2008, 04:23:13 am

Previous topic - Next topic

egreenplace

Hello,

Can anyone help me locate how to enable merchants (manufacturers) to login into my website respectively and add their products to my website. So I want to create a user name and password for each one of them and and give them the ability to login and manage their own products within my website categories with out being able to see or modify anything else on the admin website. Thanks for this great product :)

Bonnie


kate

Hi Bonnie,

The default installation provides is a user authorised to maintain the product catalog - try logging on as cat@konakart.com (password princess) and see if the permissions that are provided match what you're looking for.   If so, you just need to create more admin users with the same access rights as the cat@konakart.com user.

I'm not certain if this meets your exact requirements though.  You mentioned you wanted these particular users to manage their own products.   With the above solution the users would see the entire catalog of products, not just their own.   There's no way to restrict users by manufacturer at the moment.

Is it unacceptable for you to have one manufacturer being able to modify other manufacturer's products?  I imagine so,

Please let us know,
Kate

egreenplace

Thank you for your help. I would like the option of having each manufacturer get their own login account and not be able to see the other products when they login to manage their account. If this happens in the future please let me know. In the meantime I will work with the shared product account. Thanks again for this great product :)

Bonnie

kate

Hi Bonnie,

Glad you like the product!

We'll think about this idea for the future.

In the meantime, if you don't have too many manufacturers involved, you could consider a solution where you run separate konakartadmin webapps with different databases - one for each manufacturer.   This way you can verify the product catalog changes made by a manfacturer in his private database before syncing these with the main shop's product catalog.

You would have to write the synchronisation utility yourself, but you have all the APIs to make this kind of thing possible!

Kate

egreenplace

Quote from: kate on January 24, 2008, 03:49:00 pm
Hi Bonnie,

Glad you like the product!

We'll think about this idea for the future.

In the meantime, if you don't have too many manufacturers involved, you could consider a solution where you run separate konakartadmin webapps with different databases - one for each manufacturer.   This way you can verify the product catalog changes made by a manfacturer in his private database before syncing these with the main shop's product catalog.

You would have to write the synchronisation utility yourself, but you have all the APIs to make this kind of thing possible!

Kate


Thanks for the reply Kate. So you suggest that I have multipe installations of Konakart? One for each manufacturer since I will have no more than five. five of them. Then each one will have exclusive access to the product/categories in one konakart. Then I sync up all the tables from these konakarts to my production konakarts. If this sounds like what you were suggesting. Do you know off of the top of your head which tables I will need to sync up?

Thanks so much
Bonnie

p.s. you guys are great for replying quick!

kate

Hi Bonnie,

Well, it's more of a "workaround" to implement the solution you want, but with just 5 manufactureres it might be appropriate.   I think you've understood exactly what I was suggesting.

Yes, just have 5 konakartadmin webapps (you don't need 5 konakart webapps, just 5 Admin Apps).  Point each to a database that's different for each manufacturer.   In each of the 5 only allow each manufacturer user to edit products in a defined set of categories will make the sync a lot easier.  In each manufacturer database you would store only the products of the particular manufacturer.   So far, so good.

For the sync...  rather than doing this at the db level I would be inclined to write a synchronisation utility that uses the API.   Different keys in each db might cause you a headache with a db synchronisation but you could manage these with some code that uses the API.   

Another alternative is to just have 5 konakart stores, one for each manufacturer?   They could even have slightly different branding?   This may even be a better solution???

Regards,
Kate

egreenplace

Thanks Kate! I really appreciate your continuous help on this. Can I ask where the best place to start looking at in order to know how to synchronize using the API? Is there an example or documentation for how that is done? I am not so technical, and I have access to one programmer, but I have to tell them what to do or where to look.

Thanks for clarifying about using 5 different KonaKart admin pages. That makes sense and I think I know how to do that. If I can figure out how to use the sync API, I think I am all set. Thanks again.

kate

Hi Bonnie,

Depending on how sophisticated you make the synchronisation utility, you could find this to be quite an undertaking if you don't have a strong java programmer available.   You might need to consider simpler workarounds?  To know what these might be we would have to know more about your particular circumstances, and what your budget is!   (Normally this kind of thing would be a consulting engagement for us).

There are plenty of examples in every download package of using the APIs so they're a good place to start to figure out how to call the API.  It'll be very simple to do that for a java programmer.

Next you need to study the product retrieval API calls and the product update and insertion API calls.   It may be appropriate to write one utility that extracts data from the manufacturer databases into a intermediate files, and another that loads these intermediate files into the main database. 

This is all very well, but synchronization where you allow deletes, updates and new inserts can be non-trivial.  You may find that in your case, rather than having to create an all-singing, all-dancing general-purpose solution,  you can make the utility a lot simpler for for your specific circumstances.

Regards,
Kate