Jump to content

aaronfreed

Members
  • Posts

    15
  • Joined

  • Last visited

aaronfreed's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. thank you, @TellMeWhy. that worked like a champ. and thank you, @CoopperBackpacki got the jquery version to work, but i like your / direct native approach and will likely use it elsewhere.
  2. @NiceDuck interesting tidbit (at least to me): one cannot call a virtual field with a calculated value to the header. one CAN, however, pull a calculated field to the header.
  3. i have a flow of registration forms with an 'exit' url on each page, which allows the users to exit before the full registration is complete. before following the click URL, i want an 'are you sure' confirmation message to be displayed to the user. if 'yes' then the click URL would be loaded; if 'no' then nothing would happen. i have the following html/jquery code in the footer of forms that are part of the registration process: <a class="exits" href="https://c1dcs255.caspio.com/dp/0db19000a392125dc37d41b6a8ab">exit</a> <script type="text/javascript"> $('.exits').on('click', function () { return confirm('Are you sure? Your order will not be registered.'); }); </script> straightforward as this seems, i can't get it work. i never get a confirmation popup.
  4. changes to authentication field values do not update until the session is ended and then re-started.
  5. the answer is this: in rules for datapages based on virtual calculated field queries of Yes/No variables, the values are Y and N.
  6. @Nuke354 i opened a ticket on this one. support figured it out: the values are Y and N. i told them that the handling of Yes/No variables was inconsistent in caspio (e.g. triggers use true/false) and that perhaps an audit was in order.
  7. thank you, @kpcollier that sounds like a far more efficient approach than what tech support just gave me, which was to go to each field in the view and manually un-include it and then re-include it. i told them i hoped they didn't consider that to be resolution, but rather only a temp workaround. i appreciate your taking the time to help me out.
  8. i have changed / added / renamed fields in some tables. i have checked the views which use those tables, and have ensured that the changes are reflected in the view (e.g. ensured that 'include all fields' is checked). however, whenever i use a VIEW for a datapage, the 'datasource' fields that are available for record-level security or for lookup tables in dropdown elements show only the old fields and the old field names. the only way to see the correct fields is to use the table as the datasource, but of course that shouldn't be the case. all this is to say, it seems that dropdowns in datapages for lookup tables and record -level security are using cached versions of the original view/table. a screenshot is tough to pull off, but perhaps this example will help: current table fields: field ABC (originally named field AB) field XYZ (not originally in table or view) current view fields (match table, as expected): field ABC field XYZ fields available for dropdowns and record-level security in datapages (does not match table; unexpected behavior): field AB (not field ABC, and not field XYZ)
  9. i figured it out. i was changing the value of a field that was used in the active authentication. that is, it appears that authentication fields do not update unless/until you logout and then re-login. thus, i was getting null values because the field value was null at the time i logged in. i think this is something that needs be addressed. thoughts?
  10. hi, @Nuke354 i have/did try with single quotes and no joy. just to ensure that i had general structure correct, i set a rule to require a field if the CASE statement resolved to zero, which proved that this approach should work. unfortunately, it is the case that the CASE always resolves to zero so that is non-starter. but it does tell me that 'Yes' is wrong. i've tried 'yes' and 'True' and 'true' and True and true and 1 and 0...can't figure it out. instead of querying the view, i am now querying the table directly: SELECT FC FROM test_profile WHERE id=target.[@field:test_profile_id] the 'Yes' that i see when i query the table (as shown in the second screenshot above) , doesn't seem to be a string (as demonstrated by the failure of the CASE statement). perhaps it is just an alias for a boolean. but that begs the outstanding question...what is the value of the boolean that the CASE statement can read? thanks for taking the time help.
  11. my one authentication is built from a view based on a user_ table. when i build a report from that view, all fields present their expected values, that is, they show the values that are in the user_ table. however, when i build an HTML page and select authentication fields for embed (using the 'insert parameter' feature), not all fields present their expected values. for instance: [@authfield: user__first_name] prints out the user's first name on the HTML page and [@authfield: user__last_name] prints out the user's last name on the HTML page and even [@authfield: user__display_name] (which is a function that concatenates the first and last name) prints out the user's first name on the HTML page HOWEVER [@authfield: user__original_user_id] displays nothing even though it has a text field value of IAQM6XBX in the user table (upon which the authentication view is built, and, again, which prints out just fine in a tabular report built from that view) AND [@authfield: user__has_a_pool] displays nothing even though the text field has a value of 'Y' in the user table, and even though it prints out just fine in the tabular report built from the view. the only theory i have for why this might be is that the fields that are displaying nothing did not exist when the table was first created; they were later added. that is, i suspect that some caspio features don't update after initial creation (such as authentication view fields). i have created new views based on the updated table, but that hasn't helped. the only thing i haven't tested is creating a whole new table, which i am loathe to do. a perhaps related issue is that i have noted that when i change / add fields in tables - and ensure that those changes are duly reflected in the views that they participate in - datapage lookups for those views still do not reflect the changes in the table fields. in other words, if i were to change 'field ABC' to 'field XYZ' in a table, i can confirm that the change is reflected in view. however, when i select that view as a lookup table for a datapage's dropdown field, i will still see 'field ABC' and not see 'field XYZ'. that is, it is as if the original blueprint of the table/view is preserved. so, any thoughts? thanks for reading this far.
  12. @Nuke354 so the original virtual fields formulas, which work as expected (as indicated in my second visual), use the following formula format: SELECT profile_FC FROM _v_profile_plus WHERE profile_id=target.[@field:test_profile_id] as you can see, these queries return Yes and No values (but whether those are values or aliases, i don't know. whatever they are, the problem is that those calculated values (established by checkbox in another form), aren't being recognized by the rules engine. i have tried checking for 'Yes' 'yes' 1 and 0 and nothing works. i tried creating an additional virtual field for each as per your suggestion, so that i could convert the query results into values that the rules might be able to read, but i am getting an 'invalid formula' error with no additional details. that formula is: CASE WHEN [@cbParamVirtual1] = 'Yes' THEN 1 ELSE 0 END i also tried CASE WHEN [@cbParamVirtual1] = 'Yes' THEN '1' ELSE '0' END
  13. (and @Nuke354 i apologize for the slow response, i didn't realize that i wasn't automatically following this post...the answer to this question is very important for me).
  14. hi @Nuke354 i have tried "virutal field 1 is equal to Yes" (or 'yes' or 'true' or 1)....and nothing works.
  15. BLUF: does anyone have any suggestions on how to make a submission form's rules engine read the values from a virtual calculated field? i am using virtual calculated fields in a submission form to query five boolean variables in another table which specifies which of the five fields in the form should be required (this is customizable by the user through a separate form). the queries successfully execute and i am getting expected results (i.e. 'Yes' and 'No' for each of the five variables), which are based on the user's selection of a profile in a dropdown in the same form (e.g. profile a, profile b, profile c, which, again, they configure through another form). the queries are dynamic...they correctly recalculate as the user changes their 'profile' selection. i've attached a screenshot of the interface. i need to use these virtual calculated fields ('Yes' and 'No') values in the form's rules so that i can specify which of the fields are mandatory based on the selected profile. though the rules engine seems to be able to distinguish between 'is blank' and 'is not blank' on the virtual fields, it seems incapable of reading the values. that is, i have tried "virutal field 1 is equal to Yes" (or 'yes' or 'true' or 1)....and nothing works. does anyone have any suggestions on how to make the rules engine read the values from a virtual calculated field? p.s. for the form submission, i am using a view which joins the profile table with the test entries table. however, since only the test entries are editable in the view, i don't have access to the profile values (even though they are duly joined through the view) and therefore can't use them directly in the rule. this is why i have had to resort to using virtual calculated fields with sql queries.
×
×
  • Create New...