Alex

Ah. Do you have to contact sales to purchase or?

In order to use the multi-company features you need a Blesta license for each company, correct?

From my perspective, my inaccurate description stems from not understanding what was going on with this add-on/checkout/restricted/inactive system. Only as a result of this thread has it become clear to me what the "Default" label is intended to represent, and therefore I understood that this option did not directly relate to an add-on. I think we can all admit that option sitting alone with no additional verbiage is quite unclear and open to interpretation. (Hence the real need to make this label editable.) For me, this all alludes to the larger picture which if you'll recall I had taken the time to explain in-depth to you. I know it's necessary for you to break issues into smaller tasks, but I would have expected to you realize my confusion based on extensive recent conversations we've had relating to these issues. No hard feelings, we're all imperfect and busy people. But, it is pretty clear where my confusion came into play and what I actually meant a few posts into this thread, prior to it being closed or re-confirmed. This really needs to be water under the bridge if progress is the goal, though. At this point I'm on the side of progress, in any direction. The #1 option doesn't hurt us, I just view it as unnecessary. I understand you have a wide audience to consider but I think it's difficult to please everyone, and catering to every oddball caveat usually leads to clunky, bloated systems. (Something I am happy to say Blesta is not!) I think this is one of the options which has such a limited audience (and for those off-cases which have been identified, I have presented what I believe to be a more robust solution.) that it makes good sense to ignore/avoid/overlook it until sufficient demand is proven. This concept is less about this particular issue and more about prioritizing and organizing the development and system itself, which I think I failed to communicate in my previous posts. You can learn more about this seemingly hard nosed but highly regarded and proven successful method of prioritizing software feature requests based on customer feedback in world-renowned books such as Lean Startup. You can definitely see these methods being employed by Google, Facebook, 37Signals, Intuit, and many other highly successful web applications. If you've masterminded a method by which avoid these pitfalls then be all means, ignore me, but otherwise it's worth considering whether every caveat is worth implementing. Especially when Blesta v3 is so young and still has every opportunity to avoid such pitfalls. I wouldn't have the guts to test a hypothesis which required myself to do things which are widely considered pitfalls that are difficult to recover from. And for me, building Blesta to cater to every odd case falls into this category. If every feature has an option/setting then those seeking a simple solution for a single industry will be daunted by the configuration and management task of using the software. So, you're effectively outing a market segment if you try to cater to every market segment... ain't that ironic? Anyway, I perceive Blesta's target audience to be people seeking a simple solution for a single or a few related industries. I think any further discussion on this topic would be counter-productive in that it's a simple option to implement and I've done enough to inspire a different perspective in general, which I hope will prove helpful to Blesta on many issues, not limited to this particular one. For this particular topic, it's less of a concern to us with 3.1 offering configurable options than it was originally, and the two solutions proposed will both work for us. It has begun to feel like this thread is ruled more by technical/emotional riff-raff than by matter of fact, open-minded and friendly discussion. I am not assuming or implying any intentional wrong-doing on the part of Blesta, nor am I willing to partake in a hostile debate. I am simply advocating for a methodical and prioritized development process, in hopes of helping, not disrupting. I do hope this helps to clarify my position in a friendlier manner and I apologize for any confusion and miscommunication on my part.

Paul, This was not meant as an attack on Blesta or it's founder's integrity in any way. However, a founder's integrity or even an organization's general values are not always utilized by each member in each situation. This is the nature of humans. Regardless, I perceived it more likely that the mindset driving the issue which you've quoted was subconscious and mentally pervasive, not a cunning act. In this case, one's open mind regarding a particular topic can begin to dissipate, as I suspected was the case here. As you well know I enjoy contributing ideas, advice and code to the project, but my time is very limited. Seeing as I've explained this issue prior to this thread (to you via email), had it approved as a bug, waited for it to be released in 3.0.2 where it's not completely fixed, reported that here, had the thread closed as a non-bug, messaged you and had the thread reopened where you stated that Cody misunderstood, etc, etc... it's becoming a bit of a drain to reiterate all of the same issues repetitively. Therefore, I thought it more effective to be very frank in my approach and stop the buck here, but again, it was not intended to be offensive. Kind regards, Alex

I understand where you're going with this example, because I am indeed one of the customers with such requirements. We want to display a message more frequently than just at the bottom of the configurable options page, though. For example, in our current Blesta beta implementation such messages are stated at the bottom of the packlage listing, in your cart, and order summary, in addition to the configurable options form. ( Have a look: https://fullambit.net/portal/plugin/order/main/index/Web%20Hosting ) This is the sort of flexibility I would advocate for. (Maybe a configurable "Notes" area under each step of the checkout process, for any custom message to be added? This is another topic and feature request which really doesn't have much to do with my issue here.) Using a radio button input label as a way to deliver a paragraph-style message doesn't seem ideal at all. What if I want to add a link (which we do, as you can see from the aforementioned link to our beta implementation of Blesta) and images or some other block level elements to my message? Besides my desire for a better solution, the W3C standards mandate such an implementation invalid. A form with a single radio button option used as a checkout "note" or "message" simply isn't semantically correct. In fact, I have to wonder if a form with a single radio button is semantically correct under any circumstances. Can you imagine being a blind folk using a screen reader? That'd be enough to really confuse you. So I suppose WCAG comes into play as well; God forbid you're selling Blesta in countries where legal fines may accompany ignorance of web accessibility. It seems to me that you're trying to easily tack on additional functionality to existing code in hopes of avoiding the recognition of a blatant bug, or maybe just to be contrary, but I think it's working out something like a square peg in a round hole. Regardless, I think the points are clear from both sides and there should be enough documentation at http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#usage-summary and http://www.w3.org/TR/WCAG20-TECHS/html.html#H88 to make a wise decision, so I'll bow out of the discussion.

The question is, can you imagine a single solitary use case where having a pre-filled single radio button labeled "Default" under the "Available Add-Ons" section with no available add-ons is useful? Moreover, can you imagine a case where it isn't confusing for the end-user? I can't. If not, you're adding extra development and configuration to create that [ ] option when nobody has a use for it. Furthermore, this does not make the customer aware of what add-on groups exist. As an end-user, I would have no indication of anything other than unnecessary elements in the ordering system. I can't imagine an agument that this is a worthwhile portion of the checkout under these circumstances. In conclusion, it seems to me that a static boolean check to see whether any add-ons are marked active before outputting the "Available Add-Ons" checkout section in question would suffice to solve this issue.

I could be wrong, but wouldn't this limit us from easily adding it as a recurring add-on to their service on the admin-end? Even though it is hidden from the checkout, we use this to sell to customers whom call or email in for add-ons which Blesta can't yet quite handle they way we would like.

I understand. Thank you for explaining.

Just to be clear, I don't think the inactive/restricted addon packages appear available. If they are restricted or inactive, the correlated options do not appear on the configure page. Problem is, the "Available Add-Ons" section still appears with a lone "Default" radio button option. The section is completely useless and confusing without active add-on options in addition to the "Default" option.

I have hidden the portion of the page in question via the method described above if you are heading to the original link I posted for reference. However, if you view page source you will observe the code in question with display:none added.

Ah, sorry, I didn't realize the situation. Didn't mean to ignite a fire.

Ah, that would be my issue. Why not?

I think this issue relates to the larger issue of Add-Ons being basically useless in the order process. It's certainly the biggest issue with my deployment. Hopefully it will be resolved with the 3.1 configurable options update.

Oh, you need a separate license for each company/domain? Is there any documentation as to how you go about configuring an additional company?

I don't follow?

Yeah, Blesta license sales are popping up in several of the forums I read. It seems a lot of people don't want to wait for it to mature. If Blesta wasn't multi-company I might consider snatching up a few of these myself, but I have no real need.

It's going to be tough to sell right now I think. It was just recently $99 and a lot of people are in the same boat where they bought Blesta but don't find it as useful as they had hoped and would now like to sell their license. Hopefully v3 will be more feature-complete in the near future, so that people feel more inclined to use/keep their licenses. It should be easier to sell at that time, I would imagine.

Package options should appear on the admin-end when configuring/editing a package which uses that module/product, I think.

Firefox and Windows at the time of testing, I think. It was probably just that JS had crashed in FF or something. Thanks for clarifying, I'll do more testing.

+1 I would also like to see a publicly viewable roadmap. No matter how often it changes.

Can you create the friendly name field in the schema and add this as a configurable option in Blesta until SolusVM suports it?

This may fall flat, but I think I can make it work. I'll post back results when I've had time to test. Either way, thank you for the ideas, they have been helpful. (As with other hanging threads I have, it may be a few days before I get time to test.)

Ah! Thanks for clearing that up. Sorry if I am asking dumb questions, I'm admittedly trying to help prior to using the API myself.

Ah, that makes sense, but the documentation may be incorrect: getList( integer $company_id, integer $page = 1, array $order_by = array('name'=>"ASC") ) may should read getList( array ( 'company_id' => integer 1, 'page' => integer 1, 'order_by' => array ( 'name' => "ASC" ) ) ) or similar. The docs appear to show the passing of 3 separate vars to this method, not passing a single array with 3 values. A "bad parameters" error would have been helpful in that case, too. Mart is gonna laugh.

Ah okay, I understand the extra step now. I'm not sure if cPanel will support the local exchange when a domain is set to remote exchange, but I could set up an Exim smart route. But, I think we can avoid this problem... Blesta has an SMTP option for company outgoing mail which is seperate from the support department incoming mail settings. I can pipe the mail to the ticket system from the sub-domain, but use SMTP for outgoing mail from Blesta. Am I missing something? Outgoing mail wouldn't be delayed by SMTP, would it? I think it's still sent out immediately.