Looking for a printer friendly page with filtered RG through URL

I need help with something that seems simple, but I can’t find a solution. Below, I put the context with images, in order to be very clear my procedures, the results and the problem to be solved.

In Figure 0 I have the basic idea: I have a repeating group on a page dedicated (on the left) to the list of users with filtering. In it, the supervisor can have the list of users and filter (first letter of the name, name, gender, operating unit, etc.). As I’m learning to use Bubble, I focused on filtering on two variables: gender and unit. Because I have men and women as employees of a company that has two operating units (1 and 2). So, my need is to filter whatever is on the left page (large, spacious, user-friendly for data exploration) and, once I find the listing I want, I navigate to another page. This new page on the right is narrow, where I have the same repeating group, but with smaller letters, in a friendly arrangement for printing on paper or in PDF (using the PDF generator that any browser has).

The right page repeat group, while having the data arranged to be more suitable for printing, has the same constraints configured. However, the constraints on the right page, unlike the left page, which has a filtering configuration area, are determined by the parameters contained in the URL. Such parameters are sent from the left page through workflow. So far so good.

Figure 1 shows the unit filtering field, a dropdown menu with manual entries (Unidade 1 and Unidade 2) [Unidade means Unit in my language]. This field is a text type for now, but this should be a dynamic field in the future. The dropdown options must be the result of a query to a table with the operating units that the system administrator decides to register. I’ve put in units 1 and 2 manually, for now, just for simplicity.

Figure 2, however, already has the Male and Female genders as options obtained dynamically from a table called Gender, in which the administrator can place other genders that eventually the gender inclusion policy of his company determines. At first, the Male and Female genders are registered.

As shown in Figure 3, the repeating group of the dynamic user listing page is relatively simple, with several constraints to allow for the aforementioned filtering.

Its result is shown in Figure 4, which already has gender (with Male option) and operational unit (with Unit 2 option) filtering, as indicated by the red arrows. It works! Excellent. Thus, when I click on the printer icon (see green arrow), a workflow performs a navigation with sending parameters. The workflow itself is shown in the corner of the figure (I used Photoshop). This is where my problem starts. Note that configuring the sending of the Unit parameter is simpler than configuring the Gender parameter. Why? Because Unit comes from a dropdown with options manually inserted in the element (text type variable), while Gender comes from a dropdown with options obtained from a table (Gender type variable).

At this point, I have divided my development into two distinct parts, so as not to complicate the understanding of the problem. First I show, in Figure 5, how the print-friendly page has its repetition group configured (green arrow) with only the Unit variable filtering. The goal is to get just the Unit filtering to test the thing working, with the address anydomain.com/printer?uUnit=Unit%202 (uUnit is my filtering variable, “Unit 2” is my choice as %20 is a space in coding). Note, by the white arrow, that the type of variable to get from the URL is text.

Figure 6 shows the happy result of the process indicated in Figure 1. On the previous page (the one on the left in Figure 1) I had filtered only Unit 2 users, and I managed to pass this filtering to the Printer page, configured to print on paper Letter format or have a PDF generated with friendly data for listing.

However, when I do the same process for the Gender variable, I run into the problem. See in Figure 8 that repeating the configuration shown in Figure 7, but now using a variable whose origin was a dropdown with dynamically determined options, my variable is no longer of the Text type, but of the Genre type. In this case, the Gender type could be XYZ type, as Gender is the name of the table where the Male and Female data are inserted.

The result is shown in Figure 8. Despite repeating the process doing a single filtering, now only the Male gender is chosen to be passed to the print page, although the filtering works on the first page and even manages to pass the parameter through the anydomain URL .com/printer?uGender=Male, the repeat group does not use such a parameter. As you can see on the figure, the filtering in the printer friendly page does not work. The paramater is present in the URL, the constraint is configured to get this paramater (see figure 7), but it does not work.

  • Can anyone help me find where I’m going wrong?
  • Or simply this type of filtering cannot be done with a parameter obtained from a URL whose type is not text?