Substruct patch

[ray]

I fixed a few things in the trunk and released a patch at
http://blog.rayvinly.com/articles/2008/02/05/patching-substruct

These are the things that were fixed/improved:

+ Added order fulfillment code
+ Fix OrdersController#ship_orders
+ Fix Email settings
+ Correctly checking SMTP Authentication Type when saving in Admin's
Preferences page
+ Send emails to all customers whose orders have just been shipped
+ Add user account login
+ Show order details to customers
+ Require login before checkout
+ Use only password, not previous order # to login
+ Fill in product descriptions to look more authentic
+ https support for production
+ Fill in Authorize.net account info
+ Mask CC # except last 4 digits in db (cc_number validation needs to
include 'X')
+ Encrypt password in DB
+ Add password confirmation
+ Calculate tax (StoreController#add_tax)
+ Add tax line to OrderMailer receipt view template
+ Add tax line to admin interface showing order items (admin/orders/
edit.rhtml and show.rhtml)

Maybe this can get patched in the trunk?

Ray,

[subimage interactive]

Wow...the patches are pouring in! I love it...

Lots of stuff here Ray. A few good things, a few that are already implemented, and a few that go against my design ideas...

I'll definitely take a look at it while I'm working on the update within the next week or two. Would you be extremely offended if I took only the parts I felt were applicable to the main distribution?

All items used will of course be sufficiently credited to you in the changelog.

--
--------------------
seth at subimage interactive
-----
http://sublog.subimage.com
-----
Cashboard - Estimates, invoices, and time tracking software - for free!
http://www.getcashboard.com
-----
Substruct - Open source RoR e-commerce software.
http://dev.subimage.com/projects/substruct

[te5torx]

+ Require login before checkout
+ Use only password, not previous order # to login

+ Add password confirmation

These changes need to be optional. These are impediments to checkout
that I would definitely not want in my checkout path. One of the
things I liked about substruct in the first place was the fact that
use accounts are implicitly created rather than explicitly. I agree
that password hashing should be used in the DB, but I do NOT want to
lose the ability to use an invoice number as a login. The better way
to approach the security issue, IMHO, is to implement an account lock
after 3 or 4 consecutive failed log-in attempts. Since the order
numbers are numeric, it makes sense to put reasonable measures in
place to prevent brute-forcing. The other approach could be to
include letters in the order number. A combination of both would be
very secure.





On Feb 5, 3:09 pm, ray <rayvi...@gmail.com> wrote:
> I fixed a few things in the trunk and released a patch athttp://blog.rayvinly.com/articles/2008/02/05/patching-substruct

[ray]

Yeah I figured you might have already implemented some of these. But
since the trunk has not changed for a while, I just went ahead and
made the changes.

And no, I would not be offended a bit if you only use some of it. I
am just happy to contribute :)

Ray,

On Feb 5, 6:49 pm, "subimage interactive" <subim...@gmail.com> wrote:
> Wow...the patches are pouring in! I love it...
> Lots of stuff here Ray. A few good things, a few that are already
> implemented, and a few that go against my design ideas...
> I'll definitely take a look at it while I'm working on the update within the
> next week or two. Would you be extremely offended if I took only the parts I
> felt were applicable to the main distribution?
>
> All items used will of course be sufficiently credited to you in the
> changelog.
>

> -----http://sublog.subimage.com
> -----
> Cashboard - Estimates, invoices, and time tracking software - for free!http://www.getcashboard.com

[ray]

The reasons I made these changes is that I feel previous order number
can be easily obtained from invoices/emails, and emails are inherently
unsafe unless you encrypt it. When a customer prints the email
invoice, that order number is on the paper. I would not be
comfortable printing them in the office. Also, as the trunk looks as
of now, a user can add items to cart, go thru the whole checkout
process without ever knowing what his password is. So if you have
checked the "Require login for returning customers" option in the
admin interface, the user will never be able to login because he
doesn't even know the password.

Passwords are remembered and transmitted over https and is thus more
secure.

However, I agree that it can be an option in the admin interface
whether to allow password only or password and order number.

Ray,

[ray]

Oh, there are a few things that I want to do too but am not sure if
they are in your plan:

- Sort the products by clicking on column headings (Name, Code, Price,
Quantity, Published?)
- Sort the orders by clicking on column headings (Order Name / Number,
Date, Status, Total) - will have to separate order name/number for
this to work?
- Add CCV check (last 3 digits on back of credit card)
- PayPal AND Authorize.net - right now they are in a pull down menu in
admin, should be checkboxes to allow both and possibly more processors
in the future

Is PayPal currently working in the trunk? I have not tried to use it
at all as I was mainly developing with Authorize.net. But I really
hope PayPal can be added soon, which I know you are working on, so I
don't want to duplicate your efforts here.

Anything in the current plan or we want to add?

Ray,

[subimage interactive]

Exactly....The path of least resistance is the one to follow. After all, the UI should make it easier for people to give you money, not harder. :p

[te5torx]

I can completely understand your reasoning here--and I think it would
be great to have control over this option. Choice is good. In my
case, there is more information in the email itself than what could be
found by logging in as the user.

My biggest concern is that there are as few steps as possible between
finding a set of products and pushing the final payment button and
that these steps are completely clear, unambiguous, and reassuring.

[rogerdpack]

> - PayPal AND Authorize.net - right now they are in a pull down menu in
> admin, should be checkboxes to allow both and possibly more processors
> in the future

Authorize.net SIM works similar to paypal IPN (payment is done off-
site). I would imagine with authorize.net you either want AIM (what
it has now) or SIM, not both. So...maybe have checkboxes but then
disallow the user from checking them both? Thoughts?
Thanks.
-Roger