Page 19 of 27
Posted: Wed Sep 27, 2006 8:11 am
by sike
i think all contributors should register with the wiki to make tracking changes easier (at least it does for me (: ).
somehow i am in a cleaning mood and so i would propose to move all coding related stuff into its own sub hierachy (like requirements).
any comments?
cheers
Christian
(chra at the wiki)
Posted: Wed Sep 27, 2006 8:29 am
by onion2k
sike wrote:i think all contributors should register with the wiki to make tracking changes easier (at least it does for me (: ).
I think most of us are, but the wiki forgets who you are between sessions even if you check the "Remember Me" option. I added a few things earlier without realising so they went in anonymously.
Posted: Wed Sep 27, 2006 3:02 pm
by nickvd
Just wanted to ask astions to please put the wiki url into his sig, I keep forgetting to bookmark it, and i dont feel like sifting thru 19 pages to find the posts with the url...
/me is lazy
Posted: Wed Sep 27, 2006 3:15 pm
by ok
Posted: Wed Sep 27, 2006 4:37 pm
by Benjamin
Added. If anyone has any clues about the wiki not remembering you let me know. For some reason it is remembering me even if I close the browser and reopen it. It may only remember people for a certain amount of time. I looked through the configuration file but I don't see anything in there that allows you to change it.
Posted: Thu Sep 28, 2006 8:08 am
by ok
I also have the same problem - the wiki remembering me if I close the browser and reopen it, but sometimes while I surf the wiki, it forgets me.
(My nickname: Ok)
Posted: Sat Sep 30, 2006 3:57 pm
by ok
Posted: Wed Oct 04, 2006 1:49 am
by Stryks
I would suggest that a single payment option be bundled with a default install, this being payment via check (cheque for us aussies) / money order.
It's one of the only payment options that are really usable out of the box anyhow. That and/or direct deposit. I've done many osc installs and it's really frustrating that it comes with all these payment and shipping modules that you must turn off and then replace with more relevant modules.
There are of course allowances that must be made for future modules to function, especially payment modules, but why clutter a brilliant core application with modules which are redundant for many users.
Also, when it comes to designing the product input / storage / display sections, alot of consideration should be given to the complexity of products to be sold via the cart. Pretty much all of my installs require AT LEAST the nightmare which is the 'product attributes' function, and one case in particular required some extensive work to allow single click addition of multiple instances of a specific item(pastels in this case) from a range of up to 6 shades per color with over 30 different colors available.
This last is an extreme case obviously, but I really think it would pay to consider the different products that the system may be used to sell. At the minimum I would hope to see the ability to give basic options such as color or type per product. Even better would be to alow child products and / or alternate product versions, all with or without the ability to provide images or in the case of colors, even an html color swatch.
It's early days I know, and it doesnt pay to dwell on these complexities now, but still, I thought it would be good to put the ideas out there for consideration.
Actually, I'd really ove to help out with code and the like, but yeah ... with the caliber of some of the code contributors, I fear I would be more or a liability than an asset.
Cheers guys and good luck. If there is anything that needs a complete overhaul, osc is it.
Posted: Wed Oct 04, 2006 4:52 am
by Jenk
We have discussed using an SKU number as the product ID, so adding multiple variants of the same product won't be an issue. (The SKU is unique for each product and variant)
However, grouping products (with drop downs or checkboxes or radio's for variants) seems a plausible route to take. It won't be difficult to get the group functionality, and neither should being able to create/ammend groups and add them into the catalog. Perhaps even separate it to a module.
Posted: Wed Oct 04, 2006 4:59 am
by onion2k
Jenk wrote:We have discussed using an SKU number as the product ID, so adding multiple variants of the same product won't be an issue. (The SKU is unique for each product and variant)
However, grouping products (with drop downs or checkboxes or radio's for variants) seems a plausible route to take. It won't be difficult to get the group functionality, and neither should being able to create/ammend groups and add them into the catalog. Perhaps even separate it to a module.
In my opinion all products should have seperate SKUs. A red T-Shirt should have a different SKU to a green T-shirt. There should be a table (or multiple tables) to define how they relate to one another, but they should definitely be seperate products in the database.
But I'm not designing this, so it's not up to me.
Posted: Wed Oct 04, 2006 5:01 am
by Jenk
That's what I have described - each product and each variant have their own SKU

Posted: Wed Oct 04, 2006 6:35 am
by onion2k
Jenk wrote:That's what I have described - each product and each variant have their own SKU

I knew that.

Posted: Mon Oct 09, 2006 6:22 am
by sike
seems like the wiki is down?
Posted: Mon Oct 09, 2006 10:50 am
by Jenk
It does indeed sike.

Posted: Tue Oct 10, 2006 3:40 am
by sike
aaaaassstiiiioooonnnsss... please tell me it's only a temporary downtime.
please (: