Bubble Support Case: DEF-PRIV-001
App: tlhg-v3 (Development environment) Page: wf3_test Element: DropdownVendor Data Type: Vendor
1. Original Problem Statement
A Buyer-role user’s session can retrieve a correct count of Vendor records via Search for Vendors:count (returns 3), proving the search successfully locates and returns three records. However, reading a field value from that same search — Search for Vendors:first item's name — returns blank for the Buyer, and the DropdownVendor element (built on the identical unconstrained search) displays no Vendor names to the Buyer at all. This occurs despite an unconditional Privacy Rule (“Public Directory”) that grants both Find this in searches and View access to the name field, with no condition referencing the current user, role, or any other user attribute. An Admin-role user, tested against the same page, same search, and same Privacy Rules, receives the correct count, the correct first item’s name, and all three Vendor names populated in the dropdown.
This case has since progressed from a UI-level symptom to VERIFIED raw network evidence (Section 5) confirming the discrepancy occurs server-side, before any client rendering.
2. Editor / Configuration Evidence
Relevant Privacy Rules (Vendor Data Type):
Rule 1 — “Public Directory”
- WHEN:
This Vendor is not empty - Find this in searches:
checked - View access includes:
name (along with average_rating, badges, business_models, country, description, hair_origins, hair_textures, languages, logo, longevity_score, physical_presence, profile_status, review_count) - This condition does not reference Current User, role, or any user attribute. It evaluates true for any existing Vendor record, for any user.
Rule 2 — “Vendor Account Owner”
- WHEN:
This Vendor's vendor_account's user is Current User and This Vendor's vendor_account's is_active is yes - Find this in searches: disabled by the Bubble Editor itself, with the built-in warning: “Rules that use ‘This Vendor’s X’s Y’ can’t grant search access right now” — contributes no search access under any circumstance.
- View access:
address,email,phoneonly (does not includename).
Rule 3 — “Admin”
- WHEN:
Current User's role is Admin - Find this in searches: checked
- View access: all fields checked (24 fields including
name) - Does not match Buyer (Buyer’s
role= Buyer, confirmed directly on the User record).
Rule 4 — “Everyone else”
- No condition (Bubble’s automatic catch-all for users not matched by any dynamic rule)
- Find this in searches: unchecked; View access: none
- Per Bubble’s documentation, this applies only to users who don’t match any dynamic rule — since Buyer matches Rule 1 unconditionally, Rule 4 should not be operative for Buyer here.
DropdownVendor configuration:
- Choices source: Dynamic —
Search for Vendors, Type: Vendor, zero constraints, no sorting - Option caption:
Current option's name - Visible on page load: On; Disabled: Off
- Conditional tab: empty (only style-only inherited conditionals on hover/focus/invalid)
- Custom States: none, on the element or the page
- Workflows referencing this element: none
- Parent element (GroupPurchaseForm): no content type, no data source
- Page (wf3_test): no content type, no page-level data dependency
Vendor Data Type field audit: only one field named name exists (custom, text type); no duplicate or similarly-named field found across the complete field list.
Vendor record data audit: the two Vendor records used in testing have identical values across all compared fields, including vendor_status = Active. No record-level inconsistency found.
3. Runtime UI Debug Evidence
Two Text elements were added directly to page wf3_test, outside any parent group, with no constraints:
Search for Vendors:countSearch for Vendors:first item's name
Buyer session (fresh “Run as,” Unique ID 1785014326812x6667750915652524 confirmed via the Bubble-generated authentication URL for this session):
Search for Vendors:count= 3Search for Vendors:first item's name= blankDropdownVendor, opened = one empty selectable row, no Vendor names
Admin session (fresh “Run as”):
Search for Vendors:count= 3Search for Vendors:first item's name= actual Vendor name (e.g., “Wholesale Wigs Test Account”)DropdownVendor, opened = 3 Vendor names listed
This was reproduced twice, roughly one week apart, with no configuration changes made to the app in the intervening period, confirming the behavior is stable and not transient.
4. Independent Buildprint Findings (Supporting Evidence — Not Decisive Proof)
Buildprint, a third-party Bubble app-inspection tool with read-only access to the connected app, independently reported the following. This is included as corroborating context; it is not treated as decisive proof on its own, since it was not independently verified through a tool we could directly audit ourselves. It is consistent with, and does not contradict, the Editor evidence above:
- Vendor Privacy Rules resolve as described in Section 2, with Public Directory granting unconditional Find + View access to
name_text. - App-level Search Privacy Mode setting:
automatic. - DropdownVendor uses an unconstrained
Search for Vendorwith caption referencingThis Vendor's name_text; no plugin, backend workflow, or intermediate state involved. - All three Vendor test records confirmed to have valid, non-empty
name_textvalues. - Buyer and Admin role values confirmed as expected on their respective User records.
- The Vendor Data Type does not exist on the Live branch — this feature is Test-branch-only, ruling out Live/Test branch drift as an explanation.
- A 21-day server log window returned no standard log rows for this search (inconclusive — element-level data-source searches may not be written to standard logs; advanced/APL log sync was not enabled).
- Buildprint could not independently reproduce a live Buyer session (no test-user credentials were available to it without violating read-only constraints).
The network-level evidence in Section 5, captured directly via browser DevTools by our own team, is what elevates this case from “unexplained Editor/runtime contradiction” to verified server-side field omission.
5. New Raw Network Evidence (VERIFIED — Directly Captured, Not Inferred)
Using Chrome DevTools → Network tab, the exact XHR request Bubble issues to populate DropdownVendor’s search (endpoint name: search) was isolated and its raw Response body captured directly, for both a Buyer and an Admin session, on the same page, against the same data.
Buyer session — raw response body
{
"hits": {
"hits": [
{
"_version": 23,
"found": true,
"_source": {},
"_type": "custom.vendor",
"_id": "1784407196294x225229393973997000"
},
{
"_version": 79,
"found": true,
"_source": {},
"_type": "custom.vendor",
"_id": "1784407297452x370810329653358000"
}
],
"total": 3
},
"extras": [],
"at_end": true,
"search_version": 1786188247617
}
Admin session — raw response body (same request, same page, fresh “Run as”)
{
"hits": {
"hits": [
{
"_version": 23,
"found": true,
"_source": {
"name_text": "Luxury Wigs Salon Test account",
"logo_image": "//7d7802e163a9cbf49063acd5f7f00935.cdn.bubble.io/f1784407115250x950276594708563...",
"country_text": "France",
"vendor_status_option_vendor_status": "active",
"business_models_list_option_business_model": ["retail"],
"physical_presence_list_option_physical_presence": ["has_salon"]
},
"_type": "custom.vendor",
"_id": "1784407196294x225229393973997000"
},
{
"_version": 79,
"found": true,
"_source": {
"name_text": "Tolle Perucke Test Account",
"logo_image": "//7d7802e163a9cbf49063acd5f7f00935.cdn.bubble.io/f1784407229275x312030891448772...",
"country_text": "Germany",
"vendor_status_option_vendor_status": "active",
"business_models_list_option_business_model": ["retail"],
"physical_presence_list_option_physical_presence": ["has_retail_store"]
},
"_type": "custom.vendor",
"_id": "1784407297452x370810329653358000"
}
],
"total": 3
},
"extras": [],
"at_end": true,
"search_version": 1786188809731
}
(A third record, not shown in the captured screenshot, is included in the total: 3 count for both sessions.)
6. Buyer vs. Admin Side-by-Side Comparison
| Field | Buyer response | Admin response | Match? |
|---|---|---|---|
_type |
custom.vendor |
custom.vendor |
identical |
_id (record 1) |
1784407196294x225229393973997000 |
1784407196294x225229393973997000 |
identical record |
_id (record 2) |
1784407297452x370810329653358000 |
1784407297452x370810329653358000 |
identical record |
found |
true |
true |
identical |
total |
3 | 3 | identical |
_source |
{} — completely empty |
fully populated (name_text, logo_image, country_text, vendor_status_option_vendor_status, business_models_list_option_business_model, physical_presence_list_option_physical_presence) |
 only point of difference |
7. Exact Technical Contradiction
Buyer and Admin receive the same underlying Vendor records, identified by identical Vendor IDs, with the same total of 3 records found. The only difference between the two responses is field projection: Buyer’s _source is an empty object; Admin’s _source is fully populated, including name_text.
This directly verifies that the failure occurs server-side, during field projection/privacy filtering — before DropdownVendor ever renders anything. The UI-level symptom (blank text, empty dropdown) is a downstream consequence of a server response that already omits the field data.
8. Why Common Configuration Explanations Have Now Been Ruled Out
| Explanation | Status |
|---|---|
| The Vendor records don’t exist / are corrupted | Ruled out — Admin’s response shows fully valid, populated data for the identical _ids |
| The search returns zero records for Buyer | Ruled out — total: 3 and found: true for both hits, identical to Admin |
| Buyer receives different (wrong) records | Ruled out — _id values are byte-for-byte identical between Buyer and Admin responses |
| The problem is in DropdownVendor’s Option Caption expression | Ruled out — the empty _source occurs in the raw server response, before the Option Caption (a client-side rendering expression) ever executes |
| The problem is a client-side rendering/binding failure | Ruled out — the field data is already absent in the raw network response; there is nothing for the client to fail to render |
| Buyer’s role is misconfigured | Ruled out — directly confirmed on the Buyer User record (role = Buyer) in earlier Editor inspection |
| The Public Directory Privacy Rule doesn’t actually grant Buyer access | Contradicted by configuration — the rule as configured in the Editor is unconditional and explicitly grants both Find and View access to name, with no user-specific condition |
9. Question for Bubble Support
Why does the Bubble runtime return the same Vendor records and IDs to a Buyer but return an empty _source field projection, despite the Public Directory privacy rule explicitly granting search access and View access to name_text, while an Admin receives the full _source for the identical records?
We would appreciate Bubble engineering’s assessment of whether this is consistent with:
- A privacy rule evaluation issue specific to field-level
_sourceprojection, as distinct from record-level Find/search matching (which is clearly succeeding for Buyer) - A caching issue (server-side) affecting privacy-filtered field projection, particularly following recent temporary Privacy Rule or Search Privacy Mode changes on this Data Type (both since rolled back — see prior diagnostic history below)
- A known platform limitation or defect in how multiple matching Privacy Rules combine field-level View permissions for non-Admin roles
- Any other internal mechanism not visible from the Editor or from standard server logs that would explain identical record-level search results with divergent field-level projection, by user role, under an unconditional rule
10. Request for Bubble Engineering
We are not requesting configuration troubleshooting. The configuration has been repeatedly audited (Section 2) and, per Bubble’s own documented Privacy Rule behavior, appears correct. We now have direct, raw network evidence (Section 5) proving the divergence occurs server-side, in field projection, prior to any client-side rendering.
We are requesting that Bubble Engineering investigate the server-side privacy/field-projection behavior responsible for this divergence, and confirm whether this is a known issue, a Development-environment-specific behavior, or a genuine platform defect.
We’re happy to provide additional screenshots, the full raw network capture, screen recordings, or direct Editor access if that would help your team reproduce or investigate this.
Appendix: Prior Diagnostic Experiments (for context)
- Maximally permissive temporary Privacy Rule — added to Vendor with a blank WHEN condition, Find enabled, only
name(+ Bubble-enforcedSlug) enabled for View. Buyer still received 0 options. Rolled back after test. - Search Privacy Mode toggle — switched Automatic → Strict, no change in Buyer or Admin behavior. Reverted to Automatic.
- Full UI hierarchy inspection — parent groups, repeating groups, reusable elements, conditionals, custom states, visibility, disabled state, inherited data sources, page workflows, page type/data — no differentiating configuration found.
- Fresh reproduction after ~1 week — identical results, no configuration changes in between, confirming stability of the behavior over time.
Both diagnostic changes (1 and 2) were fully reverted, with post-rollback regression checks confirming both sessions matched pre-experiment baseline behavior. No configuration changes from these experiments remain active in the app.
Summary: Verified vs. Not Yet Verified
VERIFIED (directly, via raw network capture and Editor inspection):
- The Vendor records exist and are valid.
- The Buyer’s search successfully finds the records (
total: 3,found: true). - The Buyer receives the same Vendor record IDs as Admin.
- The Buyer does not receive Vendor field data (
_source: {}) in the raw server response. - The Admin receives full Vendor field data for the identical records.
- The problem is not caused by DropdownVendor’s Option Caption.
- The problem is not caused by empty or corrupted Vendor source data.
- The problem is not caused by the search returning zero records.
- The problem occurs before the UI renders anything — it is present in the raw server response itself.
- Bubble’s runtime applies different field projection to Buyer versus Admin for the same Vendor records, despite the configured Public Directory rule granting View access to
name_textunconditionally.
NOT YET VERIFIED:
- The exact internal Bubble mechanism causing this incorrect field projection.
We are not asserting that a Bubble platform bug is definitively proven. We are presenting this as strong, directly-verified evidence of a server-side privacy/field-projection anomaly that is inconsistent with the app’s configured Privacy Rule permissions, and requesting Bubble Engineering’s investigation into the underlying mechanism.