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

download option isn't working

Started by john_g, September 27, 2007, 07:40:34 am

Previous topic - Next topic

john_g

Hi,

I see a download option for some products under Software category. But, while checking out I dont see any option to download. Even, after the order has been processed, the download option doesn't get enabled.

Can someone tell me how to enable the download option.

Thanks in advance.

-- John

paolo

Hi John,

Actually the delivery mechanism for digital downloads isn't fully implemented in the current version of KonaKart. It will be available in the next release in the mid to end of October timeframe. We are testing it at the moment. The way that it works is that after a customer orders and pays for a digital product, he will see a link in his Account page that will allow him to download the product. The link will be made available for a programmable number of days or for a programmable number of downloads, before it expires.

For your information, the next release will also contain a security subsystem for the Admin App where users can be assigned roles giving them access to different admin functionality. It will also contain auditing to keep track of what each user has inserted / edited / deleted and read.

-Paolo

leonardovarela

Is there a way to bypass(make it work in an 'unclean' way) the current 'problem' of the download feature. I have to show the download option in a comparission with osCommerce on monday. I really like Konakart but the download software feature is a must. Thanks for your quick answer.

paolo

Hello Leonardo,

If it is just a demo you could always hard code a download link in the JSP or change the email template to include a link that the customer can click on.

However, in all fairness I don't think that this should be the deciding factor between KonaKart and osCommerce. Our download solution is only about 3 weeks away and so unless you need to get a live site up and running in the first half of October, it shouldn't be considered to be a problem.

The first fundamental decision that you should make is whether you prefer a Java cart with SOAP Web Service APIs, an AJAX Admin App and support for multiple DB vendors or a PHP cart that only supports mySQL. Since our first version which pretty much contained the core osCommerce functionality, we have added many features such as :

  • Reporting Engine

  • Promotions, Coupons and Merchandising

  • AJAX based One Page Checkout

  • SEO optimizations

  • Management of returns



However, we can still use the osCommerce contributions that consist of DB data such as the zones of a country etc.

Most people that we know of that use KonaKart, do so for the following reasons:

  • They are more comfortable with Java than with PHP and would never consider using a PHP solution. They appreciate the robustness, performance and scalability that a Java based solution can offer them.

  • They consider the APIs to be very useful for integrating KonaKart with other existing systems and for embedding KonaKart into an existing application such as a CMS application or a Social Network etc.

  • KonaKart slots nicely into their existing software / hardware infrastructure since they are already running Java applications

  • They can get commercial support from the company that develops KonaKart

  • They like the KonaKart feature set and have some in house skills to be able to customize the UI and make minor modifications to the Struts actions and even write their own payment or shipping gateways.



I have no idea of the type of application you are aiming to develop so I can't give any more specific information, but I hope at least that these notes can give you a clearer understanding of why you should or shouldn't choose KonaKart compared to osCommerce.

-Paolo




leonardovarela

Paolo

Thanks for your quick answer

We are building a University Software shopping cart.
Here are some of the things that we're looking into.

- Be able to download software. [Must]

- the login page to collect extra info (Account controller name,
email, phone #), recharge number(just a number that needs to be checked),
etc. and of course this needs to be added to the database. [Must]
We will use our own login module and we need to get rid ofthe login/create account
features and log students automatically when they already have an account.

- to be able to automatically create a user/student account and populate the
fields for the 'customer' based on their ID. [Desired]

- to do the same for their account controller.  This may be possible
to do as an incremental lookup with AJAX if the ph database allows
that kind of traffic.[Desirable]

- the reports need to be modified to show more info (invoice number,
recharge number, controller info). This shouldn't require any changes
to the db, but will require changes to the code that queries the
db and generates the reports. These will be minor changes. [Desirable]

- email additional people at various stages of the
shopping process.[M]

That is the specific items that we will be considering. I've been readingand it seems there are parts of the code that is not released. Will that interfere with the changes we want to make?

How can the changes to the database affect future realeases of Konakart?

Thanks in advance



paolo

Paolo

Thanks for your quick answer

We are building a University Software shopping cart.
Here are some of the things that we're looking into.

- Be able to download software. [Must]

I've figured that one out  :)

- the login page to collect extra info (Account controller name,
email, phone #), recharge number(just a number that needs to be checked),
etc. and of course this needs to be added to the database. [Must]
We will use our own login module and we need to get rid ofthe login/create account
features and log students automatically when they already have an account.

We've already done something similar using our login. You can use 10 custom fields (5 for customer and 5 for customer address) to gather custom information. Validation rules can be entered for these in the struts validation file (validation.xml). You can log in students automatically using the API .

- to be able to automatically create a user/student account and populate the
fields for the 'customer' based on their ID. [Desired]

You can do this via the API. In fact the way that we've integrated with other student applications is to attempt a log in and if it fails with an unknown user, then do a registration, all automatically using the API.

- to do the same for their account controller.  This may be possible
to do as an incremental lookup with AJAX if the ph database allows
that kind of traffic.[Desirable]

Not sure what you mean here

- the reports need to be modified to show more info (invoice number,
recharge number, controller info). This shouldn't require any changes
to the db, but will require changes to the code that queries the
db and generates the reports. These will be minor changes. [Desirable]

Very simple to add new reports using BIRT. When you add them, they are automatically picked up by our Admin App so that you can launch them with a single click.

- email additional people at various stages of the
shopping process. [MU]

You can create a superclass of one of our classes and get called whenever an order is saved and the status is changed . This allows you to implement whatever logic you like. ( http://www.konakart.com/configurationfaq.php#how_can_i_make_something_happen_when_an ) . You can also send an email using our velocity templates, through the KonaKart API.

That is the specific items that we will be considering. I've been readingand it seems there are parts of the code that is not released. Will that interfere with the changes we want to make?

Not as far as I can tell.

How can the changes to the database affect future realeases of Konakart?

One of the reasons that we don't release the source of our engine code is to get people to use the engine APIs. We do our utmost to guarantee backwards compatibility for the APIs so that when we add new features, they don't break the existing API calls which should make the upgrade process nice and simple. Our JSPs don't contain business logic so you should be able to customize them and not have to make changes every time we come out with new versions, unless you want to use the new functionality of the version.

-Paolo


Thanks in advance

leonardovarela