Core-715 Lives On

[Alex]

Hey guys,

 

I have a universal module Add-On package group with a single package connected with it. When I set that package to "Restricted" or "Invalid" it will still appear in the "Available Add-Ons" during check out.

 

You can see what I mean at the bottom of this page: https://fullambit.net/portal/plugin/order/main/configure/Web%20Hosting/?pricing_id=1&group_id=2

 

The Dedicated IP package is currently Restricted, although the behavior is the same if it is changed to Invalid.

 

Thanks,

Alex

[Alex]

This may be a seperate issue, but:

Available Add-Ons

Dedicated IP

[Radio Button] Default

 

I'm not sure where this "Default" radio button is generated from? In my universal module product for Dedicated IP we only have checkbox product/service options set up, no radio buttons.

[Michael]

This may be a seperate issue, but:

 

I'm not sure where this "Default" radio button is generated from? In my universal module product for Dedicated IP we only have checkbox product/service options set up, no radio buttons.

 

Default means nothing. 

[Alex]

Default means nothing. 

 

It means nothing? You mean it is equivalent to "No add-ons for this purchase" ?

 

If so, that is quite misleading in this circumstance.

[Michael]

It means nothing? You mean it is equivalent to "No add-ons for this purchase" ?

 

If so, that is quite misleading in this circumstance.

 

It's like you just get the default items. You don't pay extra.

[Alex]

It's like you just get the default items. You don't pay extra.

 

I don't understand. We have costs associated with the Add-On, so it shouldn't be included for free by default if that is what you're saying.

[Paul]

The term "Default" is planned to be configurable, ie -- give it your own label other than Default.

[Alex]

The term "Default" is planned to be configurable, ie -- give it your own label other than Default.

But why is it even showing the Add-On section if all of my Add-Ons are restricted/inactive?

[Alex]

For those of you who may be seeking a temporary work-around:

In the file

/plugins/order/views/templates/standard/main_configure.pdt

On line 171 change

<div class="heading options">

to

<div class="heading options" style="display:none;">

and on line 174 change

<section class="pad content">

to

<section class="pad content" style="display:none;">

This will hide the portion of the checkout process in question from being displayed in the browser. It's not true solution but it works if you just want to temporarily hide the "Available Add-Ons" section from the configuration page of checkout.

[Cody]

Closed as not a bug.

[Paul]

Reopened

[Alex]

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.

[Cody]

Added CORE-769 to address inactive/restricted addon packages appearing as available addons.

[Cody]

I'm unable to duplicate restricted/inactive packages appearing under "Available Add-Ons" during checkout.

 

Are you sure you're running 3.0.2?

[Alex]

Added CORE-769 to address inactive/restricted addon packages appearing as available addons.

 

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.

[Cody]

Just to be clear, I don't think the inactive/restricted addon packages appear available. If they are restricted, 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-ons in addition to the "Default" option.

 

I believe that's the intended behavior.

 

Couldn't you simply disassociate the addon group from that primary package group? After all, if there is no addon group, no section will be displayed.

[Alex]

I believe that's the intended behavior.

 

Couldn't you simply disassociate the addon group from that primary package group? After all, if there is no addon group, no section will be displayed.

 

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.

[Paul]

If a group contains no addons that can be ordered due to their status, the alternative may be to not display the group at all.

[Cody]

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.

 

That's true. But then this turns into a business decision as to whether or not customers should be aware that such an addon group exists prior to placing the order. Some would argue it should still appear, others like yourself disagree.

 

In any case, I don't see this being a bug, but could be a good feature request when configuring an order form:

 

[  ] Hide Addon Group if No Packages Available To User

[Alex]

That's true. But then this turns into a business decision as to whether or not customers should be aware that such an addon group exists prior to placing the order. Some would argue it should still appear, others like yourself disagree.

 

In any case, I don't see this being a bug, but could be a good feature request when configuring an order form:

 

[  ] Hide Addon Group if No Packages Available To User

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.

[Paul]

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.

 

We have a task to make the label "Default" configurable. Someone may have other options available offline, for quote and custom set up. In this case, they could use a label that says "Call for special options" or something. They want to indicate during checkout that there are options available, but they must be ordered separately, are special order, or custom/unique in some way.

 

We always ask ourselves whether a change will exclude a use case. Sometimes we can come up with an example and then it becomes obvious. Sometimes we can't come up with an example, but believe that there may be a case to be made that we haven't considered, in which case, the decision becomes less obvious.

[Cody]

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.

 

Yes, I can imagine such a scenario. Users selling services who wish to have addons available via Phone only may have addons:

 

Additional IP Addresses

(.) Default

 

Then have a disclaimer "Call to add additional IP addresses".

 

We already have a task to make setting the label for the default addon option configurable. That would then allow users to do the following:

 

Additional IP Addresses

(.) 0 - Call to add additional IP addresses 555.555.5555

[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.

[Paul]

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.

 

We appreciate your feedback, and think that it furthers the discussion. What you have to say is often very thoughtful and very useful.

 

However, let's not operate on the assumption that we're trying to pull one over on anyone. That might be how other people operate, but we don't work that way. We're very honest about what we do, why we do it, and how we do it. The label feature was planned before this discussion. We don't try to hide bugs.. we'll be releasing a patch today that fixes about 30 of them.

 

If we wanted to hide, we would encode the entire application.

 

Let's move forward with the understanding that we operate ethically and aren't trying to hide anything from anyone, or save face by pretending bugs aren't bugs. We may not be right 100% of the time, but that's what this forum is all about.

[Alex]

We appreciate your feedback, and think that it furthers the discussion. What you have to say is often very thoughtful and very useful.

 

However, let's not operate on the assumption that we're trying to pull one over on anyone. That might be how other people operate, but we don't work that way. We're very honest about what we do, why we do it, and how we do it. The label feature was planned before this discussion. We don't try to hide bugs.. we'll be releasing a patch today that fixes about 30 of them.

 

If we wanted to hide, we would encode the entire application.

 

Let's move forward with the understanding that we operate ethically and aren't trying to hide anything from anyone, or save face by pretending bugs aren't bugs. We may not be right 100% of the time, but that's what this forum is all about.

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