vidierre

Hi @ParkLoey I'm still studing the CASPIO Directory functionality, after the Rel.41 I was hoping to get the solutions but, again I was unable to make working the Single Logout Function within a SAML environment. My feeling is that Directory functionality is built for Enterprise plan where other stuff can be integrated (i.e. self service reset psw) form a "Growth Plan" point of view cannot be used as-is. You wrote that your "thoughts about Caspio's Directories was just for Caspio app use" but this is not what CASPIO declares into the documentation: Up to now I cannot use directory in my app because: May be I am not still able to use them There is no mechanism for self registration - You can workaround as you like but at the end one real person has to logon into CASPIO account and activate the registered users There is no mechanism for self password-reset The attributes returned on logon are only: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name email NameID My overall feeling is that CASPIO, from its first steps at the beginning of 2000, is becaming tied only with high budget companies. There are some things that is very incomprehensible why he didn't try to modify them to make more appealing the platform.

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.

Please mark as best answer if this is what you are looking for. I defined this table: where there are 2 orders (OR-001 and OR-002) whit some items. Then I defined this task: After running the task the table is changed in this way: Note the totals in sum_of_dollar_value. Is this what you need?

it seems that image cannot be seen....

I am quite shure that the functional goal can be obtained, but you should abandon the radio button concepts to set the score. In this way you could use 5 html fields with the levels in a radio-like representation and one html field that lead you to a form in a pop-up where the valuation can be done using radio button like the one you attached. (I assume you take questions from a table containing more set of questions relatedt to each Agency Feedback.

It should be enough to go in the aggregate field: Select the Advanced tab Select None for the Group-level aggregation in the Group Options Section

Hi @DaveS, you are addressing one real big topic related to many (all?) low-code platforms: the low-code paradigm. I try to explain, but it will be not a quick socialmedia-style answer, because it is fundamental to get to the deep of this topic. Quoting some sentences from CASPIO website itself: Create Custom Cloud Applications Fast Low code accelerates the software production timeline With low code, business professionals and IT teams build custom apps that match their business processes. Low-code databases are a great solution for outdated systems built around MS Access and Excel spreadsheets Low-code platforms primarily enhance an IT team’s production Developers take advantage of low-code platforms to rapidly assemble software applications that would take exponentially more time if coded line-by-line. Programmers utilize low code’s pre-built app interfaces to bypass manual coding. The great promise is speed and this promise is made to the developers, the programmers. It means that the developing methods and architectural knowledge are still needed. Which experienced developer has not be faced with the issue that to improve an app the whole data design should be scrapped? Which experienced developer has not be faced with the issue that to improve an app a big effort of reverse engineering has to be made because is not known (or is forgetted) how work the apps? These aspects lead to the importance of the app documentation and the low-code platform knowledge. None of you, maintaining or improving a CASPIO application, have ever asked yourself "did I do this in a trigger, in a formula field or in a formula in a datapage?". Low-code doesn't mean low-design. The initial mantra in the low-code arena of "democratizing access to app development" is disappeared because "allow you to create applications without knowing programming" is the same of allow you to build or repair a blast furnace without having knowledge of metallurgy, you can blow up. Nowadays none remember the developer's mantra of '80 "to build a software do not start with coding, it is the last step to be done in order to verify what you have designed". The big mistake is to believe that software develop is coding. Your example to describe the difficulty: It is the main issues of all low-code platforms, they have almost no-kind of support to the app documentation. But it is a very very old question of every software either coded or low-coded. In your post you describe another big lack in the low-code arena: The madness that comes out, on about all low-code platforms, is that after you deploy at incredible speed you app: every change has to be developed on the production environment where your users work at your own risk OR you have to pay with money and time to build your development environment and move changes from it to production. I know about customers that, after such considerations and facing the impossibility to improve their app or scale it without re-writing, have decided to swich back to a traditional coding approach. At this point I have to make a loud and clear statement: this doesn't mean that low-code has to be avoided and I still consider CASPIO one of the best platform combining a right price and a solid set of capabilities useful for developers. I can share with you my rule-of-thumb low-code developing methodology used to minimize these issues: The very first thing I want to know and clarify with my customers is the potential growth of the users number - very often I can set the proper customer's expectation in this phase. This set also my right attention during the app design. [this step is not low-code related] Then I try to define the most complete set of use-cases - this is done with customer stakeholders and final users (or SME of final users) and I try to group with a logic such usecases. Together, but in a different document, I write down some requirements araising from discussions. This is the very first canva used to desing my app and the result is a two-section word document tha is the starting point of my documentation. [this step is not low-code related] Then I use the table section of caspio to build the data model - In this phase I do not define any datapage, trigger, view and much less any front-end web page. This usually lead to write down a third section that includes all my doubts and questions for the customer. [this step has to be done with CASPIO and NOT with other data-design tools] Using the relationship view I test use-cases of point 2 - this lead to add more questions to my 3rd sections and/or some data remodelling. Usually in this step I add my own use-cases that rise up from experience and from non-functional requirements. (how users has to be defined? a self-registration-flow is needed? there is the need of any state-machine to handle workflows? Is app log required? Is data auditing nedded? etc. ) Usually the first, of a neverending cycle, customer review take place - the goal is to address all issues listed in the 3rd section writing how or why I address it or discard it. In this step I try to make more consistent the grouping of use-cases. The datapage developing start - I start to shaping the needed datapages from one group of use case (and if necessary the webpages also). Generally the very first are not about the core use cases but rather from the non-functional requirements. In this step I build, with my own standard, a solid folder structure to avoid to be lost in the firther steps. This is one of the cornestone pieces of my documentation. [this step is CASPIO related] The development travel - At this point I start to cycle from step 2. to 6. showing to customer results. In every cycle the step 6. growth also with front-end development and data model-refining. Only at this time I design some Views that could be necessary. When this end? Who can say? The main issue to avoid: DO NOT SELL YOUR SPEED CAPABILITY TO CUSTOMER, let them to discover how speed are you, do not transform this strength in your cage! I know it is a long answer, but your issue it's huge even if it can be said in few words.... PS I used my method also to revamp or migrate apps that someone else wrote.

@CoopperBackpack I tested it and I want thank you again it is an easy and elegan solution. More than what I used to use!

@CoopperBackpack is very interesting the iFrame into the footer. I have to test it. Thank you.

@DaveS reading your answer raised another thought to me. When I refer to Applications, it is referring to a set of "functionalities and business logic and tables/view" BUT also to a set of users. It means that, in my situation, App are not using shared elements and are self-consistent. So I never be faced with export/import issues for more than one app..

@CoopperBackpack the requirement is understood. This method I already used to display, on a different page, more datapages of one entity. I didn't thought it would be used also for this. You know, when you are pointing one thing and you don't use lateralthinking.... Thank you is a good solutions!

I have two tabular datapages showing data from two differents tables. One is a persons table with one row for each person, the other is a documents table containing a set of rows for each person. Both are deplyod on the same page, persons on top and document on bottom. I whish to be able to select one row from the persons datapges and showing in the documents datapages only the ones related to that person. Anyone has some tips about this?

I think there is not fixed rule, these object can help you to give a structure to your work I can say how I use them, but it is my way, so may be that others have a different opinion. I use Applications to group functionalities and business logic and tables/view nedded. i.e. one application ("school") to handle all functions nedded to selct candidates to enroll in classes; one application used to show statistics; one application to handle logs and shared objects (tebles), etc. etc. I also group into appplication all logic that require one type of authentication. So I have a "school" for candidates and students, one for teachers and so on. Inside each application I use Folders to group datapages for their scope. i.e. Inside the "school" application I have a folder with all datapages for classes, another for recruitment and another to manage all parameters tables. But this could not be the best way, is how I use them. I am very interested to know how others use them.

I'm pretty confident that the work CASPIO is doing on the directories will continue until they become a crucial mechanism. As of now, it seems to me that they're missing (or maybe I just haven't figured them out) two essential features for real-world production use: 1. User self-registration with email verification. Currently, I'm managing this with some data pages and traditional authentication. 2. Self-service password recovery. This was my thought until 44.0 now I have to try it.

Up to now Directories seem a feature developed only for some enterprise CASPIO customers. To be truly usable it miss of: A forgot password mechanism , allowing users to recover their psw A self-registration capability BUT I really believe that they are working on it. And who knows, maybe in the end we will also have other useful features available!