Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Just (a/some) few things that I have learned thus far in my journey of Leap form development. A mix of lessons learned, product quirks, etc.


Previewing Changes

While majority of the changes you make can be saved and previewed, the following changes require the application to be deployed in order to test:

  • Attachments
  • Submit Button Actions

Also, when you close the project and then "Launch" the application from the "Manage Applications" screen, the application will not include your saved changes. You must deploy to see your changes.

Print

(as of Leap v9.2.0.0_19)

  • Unless you see a "Print" button at the top of the form (when launched... not whilst in the Design mode), you really cannot Print. You can try.... but you cannot print... but no, seriously, go ahead and try.
  • In order for a user to "Print" what they have filled out:
    • User must submit
    • User must have a link to the record (i.e. link to the form that points to their record. A generic link to the form won't do
    • User must have "Read" access at whatever stage the their submission is at
    • THEN, they can print


If customer requirements call for an ability for the user to print/save as PDF etc. prior to submitting the form, you can go about it two way:

  1.  Do a submit action, call it "Save Draft" and point it to itself (as it's next stage)

    1.  This will allow the user to see the "Print" button when they re-visit the form; upon clicking it, they can print/save as PDF etc.

      ProsCons
      Simple / Straight-forward setupNO control over the output; cannot style the CSS (cannot include a custom print style-sheet
      QuickHave to write a few lines of JavaScript to tell Leap to mark fields as "Not Required" — because by rule, one can only submit the form when ALL required fields have been filled out

      		Involves like 50 steps before the user can actually execute the Print functionality

  2.  Do custom JavaScript that traverses the form fields and captures the fields and their values... sounds easy until you actually do it

    ProsCons
    FULL control over the CSS of the print pageTime consuming (comparatively) to implement
    No need for creating yet another submit button.Needs one to be proficient with not just JavaScript but also with Leap's custom JavaScript API
    User does not need to submit before they can make use of the Print functionality
    Once implemented in one place, applying logic to other stages—or even OTHER APPLICATIONS—is a piece of cake!

At the end of the day, it all boils down to:

  1.  Your requirements
  2.  Your proficiency in JavaScript AND with Leap's custom JavaScript API, and
  3.  How much time you have to get it done


Application Administration — Administrator Role

If you are an Administrator in the TEST environment, you will be an Administrator in PROD. Basically, however you have the application configured in the TEST environment will be how it gets deployed. Per group's Leap development policy:

Applications do not get changed AFTER going live whilst in PROD. (e.g. if you need to add/remove an administrator, do it in TEST, follow the normal release protocols, deploy the app in PROD, and then the changes would reflect in PROD).

<rant>


 Do you really want to hear my rant? FINE... click to expand

I am of the philosophy: only select few (read: several/limited) individuals should have access to the Administrator role in PROD... if the application access via designated roles can be limited, the better. It should definitely not include: (1) someone new that just joined the team or (2) one who has limited JavaScript knowledge, or (3) one who has limited Leap custom JavaScript API experience—I fit the 1st and 3rd category.

I am sure you must have heard/are familiar with the "too many cooks in the kitchen" idiom. In my ideal world (if I was in charge of permissions) it would be only the following types of individuals in a given application's Administrator role:

Anyhoo, due to the fact that we (Leap Dev Team) build SO MANY critical applications, this brought two concerns in my head right away:

  1.  Modification of applications, post go-live
  2.  Access to records

However, in PROD even an administrator role does not have the ability to "Change" the application... so that should definitely be comforting to you, if you are part of the Administrator role!

Then there is my "access to records" concern... Sure, a professional staff member is expected to conduct themselves with integrity, follow University policy dealing with data, etc. etc. etc. — basically, don't go poking your head where it does not belong or if not requested by Customer/supervisor etc. But what about if one of the admin's account is compromised? 

Alas, I was not consulted when the policy was set.


</rant>



  • No labels