Again, how to avoid the (1) on entries (things) with same text on identification field? (updated)

Need help App Organization
1

This is happening:

Kazam_screenshot_00000

That “(1)” is seemingly invincible. I’ve set data privacy rules and search constraints in a way that the user will never see the other entry that has the same name.

What happens is that this store has a list of customers. Fine. And every customer has a list of products. “Alface branca” is a product, and every customer of that shop has a thing named “Alface branca” under his product’s list, however the price for each customer is different, that’s why I need them to be different things (clones) for each customer’s list.

In other words, the products have the same name but different prices and different “from which customer it is” fields. So if I constrain the search for customer, only his product will show up, that’s what I show in the picture, only that specific customer’s product with his own price has showed up.
However another customer also has that “alface branca” with another price, then since these things have the same name one of the customer’s search result shows up with this (1).

What are strategies to defeat this and not show the (1) in this case?

Thank you for the attention.

Edit: More explanation as I’m aware this is a case by case thing.

My tables (data types) are like this:

I have this thing called Base Product…

Kazam_screenshot_00002

And every customer has a personal catalogue, because every customer is priced differently. The catalogue is a list of the thing I’ve shown above, the Base Product, inside the Customer thing.

Kazam_screenshot_00003
Kazam_screenshot_00003992×185 16.8 KB

So when the user (is a store) searches for a Base Product name to put into the customer’s order, for example, Tomato, only one Tomato entry will appear (like in the first image) due to search constraints and privacy roles, however it will appear with (1) or (2).

How can I better organize this so that (1) is prevented? I really tried reading the forum, but every case is unique and I couldn’t come up with anything based on the concept shown to others.

2

What if you kept Product and a Customer’s variant of that product separate, like this:

Product

  • Name (text)
  • Description (text)

Variant

  • Product (Product)
  • Price (number)
  • Customer (User/Customer)

User/Customer

  • Name (text)
  • List of Variants (Variants, list)

That way the search would always be on the more static Product table or a specific Customer’s List of Variants’ Products. There will only be one product of each thing, but multiple variants can reference the same product.

Gaby at Coaching No Code Apps (formerly Coaching Bubble)

Courses & Products, Tutorials, Private Coaching, and High-level Development

Start Learning Today :mortar_board:

3

I actually had the same exact thing happen to me yesterday. I am still struggling with it a little bit, however, I managed to get rid of the (1) (2) etc.

How I did it:

In the search of the product I used Grouping and filtered out the name of the product and showed the first one in the list.

Grouping Explanation: [New Feature] Grouping and Aggregating Data

I am still struggling with being able to click on it to show relative data but it seems like a step in the right direction. If you get passed this please post the answer so I can take a look too. I would appreciate it. :grin:

4

This seems like something that would be super helpful to new users. Not sure why the search functionality isn’t more helpful. Maybe we can do a feature request for this. Just a way to group data in a search to not have (1) (2) etc if we choose to do so.

5

Agree. I’m still working on a few possible solutions based on what you and @romanmg said, but honestly would be much easier to just tick a box “do not differentiate similar entries with a (1)” or something along that line.

We have to isolate the entry we want anyway, no need to force a differentiation. I’m just having to go an extra mile and use more server capacity because of that cosmetic issue.

6

So, Gaby’s suggestion is the “right” way to do this.

But if you don’t want to do that…

However, isn’t the thing that reads “alfa branca (1)” just a text? (It’s Product’s Name field or whatever. You’re expecting “alfa branca” But Bubble helpfully appends “(n)” to differentiate it from other results with the same name.)

Couldn’t you just append :search and replace on the text object to replace (*) with nothing? (Or regex it out.)

7

Would you have the time and kindness to tell more about why is this? Or point to some reading available online. My only previous experience with databases is MS Excel, nesting vlookup functions within elseifs and other vlookups functions. So Bubble was a great jump for me!

I thought the searchbox input was meant to be used as is in every situation, but it doesn’t seems to be the case. It is just an excel vlookup in the end!

8

As a feedback, I’m commenting again. Mainly because @J805 also has an interest in this! Hence the tagging.

After falling into a endless maze of workflow actions and data types and then noticing that I had 15 new “do a search for”, sometimes nested, on a workflow that was essential to be quick and easy on server… I decided to throw away and think a new data organization.

What I did was just like Gaby said, just slightly different from her example, but her line of thought was what I applied. I also understood why that is the “right” way, Keith! I’ve created a list of index products, and also created a price thing (table) that holds a value (number), a customer in a field and an index product in another field.

Like this:

Index product

  • To which store it belongs [a store/custom thing] (so I get to show the right index to the user)
  • Name [text] (so this can be searched upon)

Price of a product

  • To which store it belongs [a store/custom thing] (so I get the right price to the user)
  • To which product this price belongs [a index product/custom thing] (also to use as a search constraint)
  • To which end customer [customer/custom thing] (also to use as a search constraint)
  • Price’s value [number] (this is what gets cloned into the order)

Then my workflow that creates an ordered product clones the name from the index product and the price value from the price object that matches the constraints: has the chosen client (inputed by user in another searchbox input) and has the chosen index product (also chosen in the searchbox input, it’s the one shown in the image).

Really, just searching through 40 items is much better than searching through 800+ items and still having that “(n)”.

My workflows are much simpler and quicker now :grin:
If anyone knows about a tutorial or some reading on database organization that helps here with Bubble… I’d appreciate the suggestion :hugs:

A bit unrelated, but only now I’ve started using the API workflow feature… no wonder why I had some messy list based workflows before… thanks for Gaby for putting up a nice video tutorial on that! I’ve just cleaned some mess in my wf actions.