[SOLVED] Can you change a thing based on a conditionally visible/not visible element?

So this is my setup (and can’t get my head around a solution):

User creates a product [cost 30] and defines field “fee [10]” or “no fee [0]”

Customer buys product and in the two scenarios is presented with:
A. product 30 + fee 10 = sum 40 (element is visible when user defined fee [10], when product was created)
B. product 30 + fee 0 = sum 30 (element is visible when user defined fee [0], when product was created)

Because the fee [10] needs to be included depending on the visibility of the fee element, I can’t just use the DB value (because then it’s always included visible or not visible). To solve this I created a temporary field fee [temp] which should copy the fee element value in the DB and be included in the sum:

when element fee [10] is visible; product 30 + fee [temp 10] = 40.
Finally, another workflow would change fee [temp 10] to 0.

I think this is a valid solution but can’t get fee [temp] to copy and save to the DB.

Any suggestions?

Hey @jonaspalmqvist instead of doing this based off of visibility, could you have the Fee field value set up when the product is created? So if a User is creating a product and wants to include a fee, they could check a checkbox (not limited to that) regarding whether to include the fee or not; the workflow events could be:

First Event:
“When Button Create Product is clicked and when Fee Checkbox is checked”
Data --> Create a New Product --> Fields to Change: Price = 30 (or, Input Price’s Value), Fee = 10.
*Assuming Price is a field (type: Number, List: No) and Fee is a field (type: Number, List: No).

Second Event:
“When Button Create Product is clicked and when Fee Checkbox isn’t checked”
Data --> Create a New Product --> Fields to Change: Price = 30 (or, Input Price’s Value), Fee = 0.

1 Like

Splendid @fayewatson! Just the way it’s set up. You validated my thinking. :slight_smile:

The fee IS created when the product is created. (it can also be changed in users’ “edit product” section)
product price is a field (type: Number, List: No)
fee is a field (type: Number, List: No)

No checkboxes though. What I didn’t tell you was that there’s a delivery/pickup selection included too. The user allows for delivery (fee) or customer pickup (no fee), so no matter what, the calcs have to include/not include the fee when the customers go through checkout, based on this condition. It’s the frontend I’m actually struggling with.

Ohh I see. :slight_smile: I think you’d want to create a new Data Type for this. Can you share a link to the editor? If not, are Users able to add multiple products to their cart, and are then charged a one time delivery fee (if they chose that method)? Or is the fee per product no matter what?

I think you’d want to create a new Data Type for this.

hmm. Why do you think that and how do you see it? I was hoping I could avoid this until the purchase is made. Then I’ll need it to handle the data included for order confirmations etc.

Editor by PM.

Users are in this version only able to add single products to their carts (and most likely later too). Or really, there’s no cart per say. The purchase feature is included in all product pages. The delivery method is actually chosen by the creator of the product right now, and not the customer. In this version there’s delivery or pickup. What determines if the customer should pay the fee or not is then based on the choice made by the seller.

So first, a seller creates a product. Then, a User can view that product and click Order (but the User doesn’t have the choice to select pickup or delivery). After a User clicks Order, the Seller is notified and then decides if the total price charged to the User will be Price + 10 (delivery) or Price + 0 (pickup)?

So first, a seller creates a product. Then, a User can view that product and click Order (but the User doesn’t have the choice to select pickup or delivery).

Technically correct. The prototype will only allow one option, delivery or pickup. It’s set by the creator. Later, the creator will be able to set both delivery and pickup and it’ll be up to the customer to choose.

(1) After a User clicks Order, the Seller is notified (2) and then decides if the total price charged to the User will be Price + 10 (delivery) or Price + 0 (pickup)?

1, correct.
2, no. the delivery price is set just like the product price so when a customer buys the product, it’s already there.

Makes more sense?

Ok I think I got it now :slight_smile: but if anyone else thinks I am missing something please jump in! Since you have the field ‘Delivery Option’ you can set up two workflows for the Order button regarding that field, decided by the Seller.

For example:

When ‘Order’ is clicked and when Parent Group’s Creation’s Delivery Option is “Delivery
Create a New Order →
[include fields you would need for this, like Seller, Buyer, Buyer Contact Info, Name of Item, etc.]
The Price field here will = Parent Group Creation’s Price + Parent Group Creation’s Delivery Fee + Admin Fee

or,

When ‘Order’ is clicked and when Parent Group’s Creation’s Delivery option is “Pickup
Create A New Order → [include fields mentioned in first example], the Price field here will = Parent Group Creation’s Price + Admin Fee

You are right, the Order Data Type doesn’t need to be created until a User places an Order. In order for the Creation price calculation to be correct before the User clicks Order, you could set up conditional formatting on those texts. For example: now you have the Total text set as:

You can set up a conditional statement on that text to be:
“When Parent Group’s Delivery Option is Pickup” →
Text = “Dropdown nr portion’s value * Parent Group’s Creation’s Price + Parent Group’s Creation’s Buyer’s Admin Fee kr” *(The same as the default text, excluding the delivery fee). That way your user is viewing the correct price of the product, depending upon whether the Seller chose Delivery or Pickup for their Creation.

Does that solve what you were trying to do? If any of that was confusing or if I am missing something please let me know!

Aaah, you’re thinking conditionals on the order button. Didn’t think of that. I was so focused on conditionals on the pickup/delivery element. As long as I can show the correct cost to the customer. Will try it and let you know.

Big thanks so far.

EDIT: looks like it works very well to have multiple conditions on the “total value”. I’ll add more delivery options later. Then it’s easy (if all else is good) to add another condition. This way, I don’t have to create a temporary delivery fee field either, only to have a value when a certain element is visible. You’re solution is much smarter.

Big Big thanks for the help @fayewatson. one step further now.

In addition, it seems there is no way to change a thing based on a visible/not visible element. Bubble likes to work with data straight between DB and frontend, and not passing some intermediate rule/relay. If anyone else has any input on this now general question, pls feel free to add.

1 Like

No problem at all @jonaspalmqvist :slight_smile: Glad it is working! You can Make Changes to a Thing based on if the element is visible using a Do When Condition is True (Every Time) Event, but I don’t know if I’d recommend that because it would mean a workflow would be counted every time the elements are visible/not visible no matter what?

Yeah, that’s what I tinkered with before you helped me out. I had the app write to two fee fields, of which one was temporary and updated every time delivery would be visible (with your “do when”). This was under the condition that pickup/delivery was available as a choice.

However, you helped with a better solution, a one much more resource efficient.

Good to know for future references though. Up until very recently, I was confused about the “and” in “and when” for events. Especially for custom events. It’s not intuitive Imho when you’re presented with a “and when” straight. It indicates there should be a first set of logics defined. I’ve been confused about it.

Yeah, that’s what I tinkered with before you helped me out. I had the app write to two fee fields, of which one was temporary and updated every time delivery would be visible (with your “do when”). This was under the condition that pickup/delivery was available as a choice.

However, you helped with a better solution, a one much more resource efficient.

Good to know for future references though. I guess now the original question is [SOLVED].
@fayewatson’s :balloon: :point_left:. Up until very recently, I was confused about the “and” in “and when” for events. Especially for custom events. It’s not intuitive Imho when you’re presented with a “and when” straight. It indicates there should be a first set of logics defined. I’ve been confused about it.