mdoering

If you want to dive deep, I just reapplied a customization I had made. On the order form for new customer signups, I wanted to force users to use their email address. In order to do this you need to change the following: MAKE A BACKUP BEFORE ALTERING {install directory}/plugins/order/views/templates/standard/main_signup.pdt To force e-mail, you'll need to change line 247 to: $this->Form->fieldHidden("username_type", "email"); Then you'll need to delete lines 248-256, and 246 Be cautious about editing, and if in doubt, change the field type to hidden as above and give it a static value then remove the label.

Because 100% of our tests include things like QA when failing over to a standby site, QA when recovering back to our primary site, and performing QA when rolling code to production... There's a lot that can get missed when you start dealing with systems that span vlans, subnets, and data centers. The only way to ensure the best possible experience for users is to impersonate one, up to and including arguably the most important part of the business model... spending money. I'm not trying to start an argument or debate on the topic, just trying to put in a feature request...

Well for one I can't spring for a second blesta license right now to stand up a dev environment... But even if I had a dev environment, having a test user that can process test transactions on the live system is an important asset when rolling code from dev to prod to ensure everything works as expected. Let's put it this way, I'm a systems engineer at a bank with several million customers, we have full dev, test, staging, and prod environments, and we still use test users on our production websites as we do our QA testing after rolling changes to prod or failing back to our main data center from our standby site.

If I'm understanding this correctly you want to disallow the ability to sign up with more than one username with the same e-mail. I didn't like the ability to use a username at all so I simply removed that field from the sign-up form thus forcing people to use their e-mail address as their username... That should have the same effect if I'm not mistaken...

One other thought is to possibly add a checkbox on the admin view for a client to mark them as a "test" user so that only transactions from that client are processed with the test API key... This would be far more flexible and would allow testing on the live system without interrupting legitimate transactions.

Here's another +1 for the roadmap... Even if it didn't have dates, seeing the list of priorities would help narrow down where things stand...

I would like to eventually see the ability to either remove an item from the order form, or optionally display a user defined message when stock reaches 0 on a per-package basis. Some items may be temporarily unavailable while others may have been limited quantity one-time deals... Having the flexibility to specify the message per-package where you set quantity or optionally remove it from the order form would be great... The easy thing is to make it disappear which is the present intended functionality, but there are a number of marketing, SEO, and customer service reasons for some things to always be visible, even when out of stock.

Would like to see the addition of a Test and Live key field on the stripe payment gateway module page with a drop down or radio button to set the currently active key. I find myself constantly flipping between the two and having an easy way to do this would be great. Additionally, it would be helpful if there was a persistent alert bar at the top of the admin page similar to maintenance mode that showed that the Stripe API was currently in Test mode.

Yes, that is what my intent was. I apologize if I wasn't clear. The "One other thing" post was meant more as a feature request than bug fix...

Thanks again Paul. One other thing... would it be possible to have a user defined message when stock reaches 0? Some items may be temporarily unavailable while others may have been limited quantity one-time deals... Having the flexibility to specify the message per-package where you set quantity would be great...

I'm assuming that setting an item to restricted also makes it disappear from the order form like setting it to inactive does? Is there any way to have it visible but not orderable per my original question? Being able to order a product that is at a quantity of 0 is a huge oversight... potentially a show stopper for our deployment... If we get to a 0 quantity on a product at 3am I don't want orders to continue to pile up that will require refunds to be sent out... I'm assuming it's simple enough to determine if an item is out of stock when the page is rendered... when it makes the call to get the price it could also check quantity and if not greater than or equal to 1 then return a "Temporarily Sold Out" or other user configurable message instead of price and also hide or deactivate the "Select" button for that item...

Hi all! First off, this is a fantastic product... I'm loving the ease of administration, plugin/module integration, and everything else about blesta over our original platform (WHMCS) I have a slight problem however, which is likely 100% user error... I have entered some products which I want to be displayed but that are not yet available. I have set the quantity to 0 but for some reason I'm still able to order (all the way through to payment, receiving an invoice, and having the service provisioned) Is there any way to have something visible but "out of stock"? Thanks in advance.