Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation since 04/30/2024 in Posts

  1. Hello! Caspio releases another new enhancement to the WebHooks feature, refer below: Caspio Webhooks allows your applications to communicate with third-party systems in real time when changes to data occur. In this release, we introduced the following updates: In non-HIPAA/Compliance accounts, webhooks logs now show the information sent and received. All accounts, including HIPAA/Compliance, now can: Send webhooks based on table events initiated by triggered actions and tasks. Configure webhooks for tables with triggered actions enabled for the same event as the webhook. A single REST API call can be used to activate or deactivate all events for a selected webhook. Source: https://howto.caspio.com/release-notes/caspio-47-0/#:~:text=Enhancements to Caspio Webhooks
    1 point
  2. I am afraid that here we shift in conceptual point of views. The detail you added shows a table (the one I used and that is a tipical concept of DBMS) that should bheave like a sheet (that is a tipical concepts of spreadsheets software). While spreadsheets easly refer data as-you-see and have primitives able to handle the previous-next concept or allow you to refer data by-cell, DBMS can have a likewise functionality implementing indexes. So the prev-next record is non necessary the prev-next record you see displayed but the one according the index you are referring to.... Speaking SQL, we can obtain the result you want in this way: SELECT index_key, order_nu, order_date, order_item, dollar_value, sum ( dollar_value ) over ( order by index_key rows unbounded preceding ) sum_of_dollar_value FROM Test_ordes; but I am afraid this is not possible to use in CASPIO. The workaround you could use is to add one more colum to the table that make the index of your table The change the task in this way: When you run it you get: ATTENTION: I think this is not a solution. It can be used as workaround if you consider: Values are not updated in realtime when you add a record, but only after the task runs We do not know what is the limits or constrains that could be arise when the table has a lot of records (perfomance? timeout?) The first to SET statements is the only way I found to initialize the variable. If you omit the first one the variable is instantiated as an integer and all decimals are lost The For statement cannot be done on the table, but on the SELECT result because you need to consider the ORDER BY The WHERE specification is needed otherwise you get the result of the last sum on all records..... I say again low-code bring an encapsulation of the below infrastructure and some capabilities you have using it directly are hided. Mark this as solved if you like.
    1 point
  3. For #2 and #3, The common workaround we do is that, have the DataPage where the user can generate the PDF be accessible to the target receiver as well. For example, include the URL of the DataPage in the email so the user can just go there an download the PDF on their own since we cannot attach them on the email.
    1 point
  4. For #2, do you mean like automatically save the PDF in the Caspio Bridge account as a record? If that's the case, I don't think we have that yet as well. PDFs are generated on the user level only to be downloaded, and it does not have any function to have them saved automatically as new record.
    1 point
  5. Hello, I'm not sure about the #2, but the #3 is not possible. Triggered Action cannot send an email with attachments. The only email function that has that is the notification email in DataPage level.
    1 point
  6. Hi Aleksandra, I'm not sure exactly what you need but if you want to only display the task/projects that are assigned to you you can use RLS(Record Level Security) for reference you may check: https://howto.caspio.com/authentications-and-connections/authentication/record-level-security/restrict-access-to-data-by-user-or-role/ . If that's not the case perhaps you can elaborate more?
    1 point
  7. Hello @ClayG, I agree that it is better to avoid using the List data type in more or less complex workflows. This data type has a number of restrictions, e.g. it is impossible to use it in Charts, Pivot Tables, Grouping, Aggregations, Formula Fields, and Calculated Fields. I would like to share some points regarding List data types and REST API for future reference. 1) Syntax example to add a field with List data type to the Table. { "Name": "Cities", "Type": "List-String", "Unique": false, "DisplayOrder": 0, "ListField":["London", "Paris", "New York"] } 2) As far as I know, the list of values in the List data type field is the subtable. Values are stored in this subtable in the format: "Cities": { "1": "London", "2": "New York", "3": "Paris" } If this field was added to the Table via REST API, the values are sorted in ascending order and indexes corresponding to the ordinal number are applied. 3) To insert(POST) or update(PUT) this field within the record one needs to refer to the value by referring to its index. Example: The same logic can be used for this PUT method: 4) However, we cannot reference the values that are stored in the subtable (we can reference them by index, but not by value). Therefore, it is impossible to use the List data type field in the WHERE clause (for example, I need to search for the records where the city has 'New' in the name: New Delhi, New York, New Orleans, etc.) It is impossible to use the following syntax: So, in the GET requests the List data type field just can be used in the list of fields to select from the Table.
    1 point
×
×
  • Create New...