You are viewing limited content. For full access, please sign in.

Discussion

Posted to Laserfiche Cloud

Discussion

Laserfiche Cloud

Address Field Missing for Canadian Laserfiche Cloud Users

Laserfiche Cloud Laserfiche
Updated September 27, 2022
posted on May 13, 2022

Hi everyone. 

So we are new to Laserfiche Cloud and are discovering some of the "changes" from on prem to Cloud. One of which is the lack of Address Field. 

Laserfiche has informed us that the Address Field is not available for Laserfiche Cloud Canada customers. This seems a little unfair as we have been using and will be using an Address Field for many of our forms. Rather than creating an Address Form template as we would like to use some of the ones in the Marketplace, are there other organizations out there in Canada that are in LF Cloud who would like to see this field available for its customers? 

1 0
replied on May 13, 2022

Hi Sherri,

I believe the address field is not present in the CA Cloud release because there were concerns that it (at this time) was specifically a US address field components and that customers outside the US would not want to use a non-globalized field in that way. I don't believe self-hosted has non-US based address fields either. Can you provide more information into what you feel you are missing with the field not being there, and if it would have even worked for you being based around US address assumptions? Thanks!

0 0
View 2 previous replies
replied on May 18, 2022

We were able to use the address field previously by adding in some javascript to reflect Canadian Province, postal code. This was able to import from our on premise LF Forms but we cannot add any new ones.

 

$(document).ready (function () {
$(".Country").parent().children().css('display', 'none'); 
  $(".State").siblings().text('Province');
   $(".Postal").siblings().text('Postal Code');
  $(".Address1").siblings().text('Mailing Address');
}) 

 

CDNAddressfield.JPG
CDNAddressfield.JPG (26.37 KB)
Download
0 0
replied on July 12, 2022

Have you been able to find any solution to this?

0 0
replied on September 7, 2022

Hey @████████,

We completely agree that there needs to be a solution.  Forms processes can be created in a self-hosted system where the address block is used.  This form can be uploaded to the LF Cloud system where the Address block will still exist on the form or a process is uploaded from the Solution Templates with the address field.  

Where this gets hairy is when you want to reuse that address block or use the variable in the process or on another form within the process.  The variable cannot be used, and to make matters worse, within the classic designer, selecting All Variables will cause the variables to not load properly.  The variables not loading properly has been verified via LF Support Case 226657.  This causes issues with other variables also, logged as bug 394343.  The only way to use all variables (minus the address variable) is to convert to the new designer or remove the address field from the forms.

If the Address block can be added back to the CA Cloud then it can be manipulated with JAVA like the code that Sherri above posted.  This is used to make the ZIP Code/Postal Code and State/Province change.

OR

If the address block can be added back to the LF Cloud CA instances with a switch for ZIP/Postal Code and State/Province then all would be even better in my opinion.

0 0
replied on September 26, 2022

Sorry for being late to this party, but I'm having a hard time understanding the benefits of this address field with JS overrides over individual fields for the address components that wouldn't require relabeling with JavaScript.

0 0
replied on September 27, 2022

Hey Miruna,

The benefit of the address block of fields is that you can add the field block and it is pre-formatted.  If adding individual fields on the old designer, then CSS is needed to organize them.  Yes using the new designer allows for the ease of organizing but many of our clients are moving from an self-hosted system where the upgrade to include the new designer was not done with the expectation they were just moving to LF cloud instead.  Now that they have moved to cloud, the old designer designed processes that exist in the self hosted system get exported then imported into cloud Process Automation.  This causes issues, as mentioned above in regarding the bug.  But also requires a rework of forms.  If ever they want to add a new address block they would need to add individual fields and set CSS.  For some clients CSS was not needed and now they have a hurdle to learn due to the address field being not available.

Next the client would think, I will just convert to the new designer to make the CSS go away.  Once converted though there is other major rework that is needed to make the forms in a process look similar to the old form, keeping it familiar to the end users.

Including the address field block in cloud then adding some simple java to hide "State" and "Zip" seems simpler.   Or even better, add the Address Block fields back to CA cloud with a selector like a currency field.  US or CAN.

0 0
replied on May 13, 2022

Can you give some more context for this question? If we're talking about repository metadata, it's as customizable in the Cloud as it is self-hosted. The management interface is even the same: https://app.laserfiche.ca/laserfiche/management.aspx#?tab=metadata&subtab=mdFieldsTab.

I'm not aware of any functional differences between the regions that would limit the customizability of the product.

You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...