luca.pizzato reports on 2018-09-12:

Hello,

i have a problem with the update of the form skip logic.

When i try to use the Advanced control mode (it works in standard), even with a simple logic [baseline_arm_1][sex] = '1' it goes on fatal error like this:

REDCap crashed due to an unexpected PHP fatal error!

Error message: Uncaught Error: Unsupported operand types in 
/var/www/html/update/modules/form_render_skip_logic_v3.3.3/ExternalModule.php:308 

Stack trace:
#0 /var/www/html/update/modules/form_render_skip_logic_v3.3.3/ExternalModule.php(373):
   FormRenderSkipLogic\ExternalModule\ExternalModule->getFormsAccessMatrix(113,NULL) 
#1 /var/www/html/update/modules/form_render_skip_logic_v3.3.3/ExternalModule.php(51):
   FormRenderSkipLogic\ExternalModule\ExternalModule->loadFRSL('record_home',NULL) 
#2 [internal function]:FormRenderSkipLogic\ExternalModule\ExternalModule->redcap_every_page_top('36')
#3 /var/www/html/update/redcap_v8.5.11/ExternalModules/classes/ExternalModules.php(1320): 
   call_user_func_array(Array, Array) 
#4 /var/www/html/update/redcap_v8.5.11/ExternalModules/classes/ExternalModules.php(1405):
   ExternalModules\ExternalModules::startHook('form_render_ski...', 'v3.3.3',Array) 
#5 /var/www/html/update/redcap_v8.5.11/Classes/Hooks.php(37):
   ExternalModules\ExternalModules::callHook('every_page_top', Array) 
#6 /var/www/html/u

File: /var/www/html/update/modules/form_render_skip_logic_v3.3.3/ExternalModule.php
Line: 308

this is an installation of REDCap where i use custom hooks too. maybe some problems with it?

Thanks,

Luca

If you place a condition in an instrument inside a multiple event, the condition is not true only in the current event instance but in all instance of the repeated event.

In this example i set that if the baseline data in incomplete it should disable the three month intrument.
The second instance should be visible according to the rule

I have a longitudinal study in which I've enabled "Repeat Entire Event (repeat all instruments together)" for one of the events which contains more than one data entry form, thus all data entry forms will have an instance query parameter (if it is not present redcap will assume the first instance) when you enter the form from the record status dashboard. However, it looks like the FRSL is not taking this instance query parameter into account when it calculates the nextStepPath, so after you click "Save & Go to Next Form" on the first form for the repeat event it doesn't keep the same instance query parameter, thus it always loads the first instance of the next form when really you want to edit that next form for the instance you were just on for the previous form.

REPO Steps:

1. study configured with at least two events and at least two data entry forms/instruments are mapped to the second event.
2. Configure the second event to be "Repeat Entire Event (repeat all instruments together)" in the "Enable optional modules and customizations" section of the project setup.
3. Complete both data entry forms for the first instance for a record id.
4. On a record dashboard for the same record id used in step # 3, click "Add new" to add the second instance of the repeatable event.
5. Complete the first form for the second instance (Note on this page the instance=2 query parameter). When you press "Save & Go to Next Form" to start the second for this instance query parameter is not there and thus REDCap loads the first instance of the "next form" that you created in step # 3, instead of taking to the next form for the same instance you were on for the previous form.

NOTE: I do not have any FRSL configuration set for this REDCap project.

REDCap v 8.10.1
FRSL v 3.3.3

While FRSL has some survey support, the documentation does not mention it. At the very least we need to say something like this

FRSL works with the Auto-continue to next survey option of Survey Termination Options. It has not been well tested with Survey Queues.

versions: REDCap 13.7.22 · PHP 8.2.12 (Linux/Unix OS) · MariaDB 10.6.16

The 'form_render_skip_logic' module threw the following exception when calling the hook method 'redcap_every_page_top':

Error: Undefined constant "USERID" in /url/redcap_v13.7.22/Classes/Piping.php:1401
Stack trace:
#0 /url/modules/form_render_skip_logic_v3.3.13/ExternalModule.php(319): Piping::pipeSpecialTags()
#1 /url/modules/form_render_skip_logic_v3.3.13/ExternalModule.php(398): FormRenderSkipLogic\ExternalModule\ExternalModule->getFormsAccessMatrix()
#2 /url/modules/form_render_skip_logic_v3.3.13/ExternalModule.php(56): FormRenderSkipLogic\ExternalModule\ExternalModule->loadFRSL()
#3 /url/redcap_v13.7.22/ExternalModules/classes/ExternalModules.php(3165): FormRenderSkipLogic\ExternalModule\ExternalModule->redcap_every_page_top()
#4 /url/redcap_v13.7.22/ExternalModules/classes/ExternalModules.php(3330): ExternalModules\ExternalModules::startHook()
#5 /url/redcap_v13.7.22/ExternalModules/classes/ExternalModules.php(3363): ExternalModules\ExternalModules::ExternalModules{closure}()
#6 /url/redcap_v13.7.22/Classes/Hooks.php(42): ExternalModules\ExternalModules::callHook()
#7 /url/redcap_v13.7.22/Classes/HtmlPage.php(144): Hooks::call()
#8 /url/redcap_v13.7.22/Config/init_functions.php(614): HtmlPage->PrintHeader()
#9 /url/redcap_v13.7.22/Libraries/PEAR/Auth.php(587): loginFunction()
#10 /url/redcap_v13.7.22/Libraries/PEAR/Auth.php(530): Auth->login()
#11 /url/redcap_v13.7.22/Classes/Authentication.php(1850): Auth->start()
#12 /url/redcap_v13.7.22/Classes/Authentication.php(893): Authentication::checkLogin()
#13 /url/redcap_v13.7.22/Classes/Authentication.php(646): Authentication::tableBasedLogin()
#14 /url/redcap_v13.7.22/Classes/System.php(902): Authentication::authenticate()
#15 /url/redcap_v13.7.22/Config/init_project.php(7): System::initProjectPage()
#16 /url/redcap_v13.7.22/DataEntry/record_home.php(3): require_once('...')
#17 {main}

URL: /url/redcap_v13.7.22/DataEntry/record_home.php?pid=58&id=74-4&arm=1
Server:
User:
Project ID:
Module Name: Form Render Skip Logic (form_render_skip_logic)
Module Author(s): [email protected], [email protected], [email protected]
Run Time: 0 seconds

Hi,

I found a bug involving having a repeating instrument and using the "Save & Go to next form" button. I hope you can replicate this.

When I'm on a repeating instrument and "Save & Go to next form" it incorrectly appends the "instance=n" parameter to call the next instrument. This is not an issue when I'm on the first instance of a repeating instrument as it calls the next instrument with instance=1, but when I'm on the second or higher instance, it will call the next instrument with instance=2, 3, etc. which completely breaks the data entry on that page if that next instrument is not actually set up as repeating.

At first I thought this was a new REDCap bug, but the bug disappeared after disabling FRSL. This even happens with a completely empty FRSL config.

When the "Save & Continue to Next Form" was the last button selected by the user then it is not disabled by frsl_data_collection_instruments.php until a different button is pressed.

Somehow Flight Tracker (another EM) reported the error of your module:

Your cron job failed for pid 1541 with the following error message:
Error Message: Optional parameter $record declared before required parameter $event_id is implicitly treated as a required parameter
File: E:\redcap\modules\form_render_skip_logic_v3.3.13\ExternalModule.php
Line: 97
{"type":"8192", "message":"Optional parameter $record declared before required parameter $event_id is implicitly treated as a required parameter", "file":"E:\redcap\modules\form_render_skip_logic_v3.3.13\ExternalModule.php", "line":"97"}

Hi,

We are suddenly experiencing an error that I think* may be related to the Form Render Skip Logic but not 100% sure. It suddenly stopped working last week but seems to only be affecting users assigned to 1 (out of 3) data user groups on our project. I am not assigned to a DAG so my view looks fine/normal.

Here's a screenshot below of the Dashboard view. It starts at Record ID 264-69, where, based on a response in the "Patient Initial Screening Chart Review" form, the "Patient Approach" form should or should not appear. But, now, as you can see, all forms are showing up. If you think this may be a fix I can make to the Form Render Skip Logic set-up, I will greatly appreciate any suggestions!

FRSL is not working in the Record Status Dashboard when Dynamic Data Pull (DDP) is enabled.

When DDP is enabled, it modifies the record table by adding an extra column as shown in the figure bellow.

This extra column appends one extra <a> element per row:

The FRSL fails when Record Status Dashboard is opening. The following message is shown in the browser console:

This error is thrown when FRSL tries to process the <a> element that comes from the DDP code.

After this error, the JS code stops and the module does not work as expected.

I coded a workaround for this problem that just ignores the <a> element that comes from DDP stuff:

The code itself:

 if (formRenderSkipLogic.location == 'record_status_dashboard' && 
            this.href == "javascript:;" && this.outerHTML.indexOf("triggerRTWSmappedField") != -1){
            return;
        }

Well, I don't know if this workaround is the best solution, probably not, but its working.

Development of the form_render_skip_logic module stopped in December of 2021, immediately after the release of REDCap 12.0.0 with its new feature Form Display Logic on 2021-11-22. The REDCap's native Form Display Logic has a more robust design and performant design that filters forms on the backend. It's absolutely the preferred solution for hiding forms based on logic.

CTS-IT, the developer of FRSL, encourages every FRSL site to migrate to REDCap's Form Display Logic as soon as possible. CTS-IT will make no further releases or bug fixes of FRSL. CTS-iT has no plans to make any updates for compatibility with PHP8. If someone wants to take over maintenance of this code, they are welcome to do so. CTS-IT does not recommend continued use of FRSL and does not have the resources to offer assistance in further development of this module.

Sorry for the late notice of these decisions in this forum. We had thought the message was effectively communicated in the REDCap Community, but that has proven to be incorrect. We regret the delay in posting this notice.

As you can see in this image, the selector for Arm-Event dissapear.
We are currently using v3.3.11 in REDCap 10.8.2

FRSL 3.3.8 introduced a performance-enhancement that interacts poorly with DAGs causing all forms to be displayed in the Record Status dashboard in some cases.

The new feature notes when you are using the pager in the record status dashboard and queries a reduced set of records in line with the records being viewed. This works correctly when viewing all the records, but when you selecting a DAG, the feature queries the wrong set of records, generates a Javascript error, and shows all the forms. The javascript error can only be seen from the web browser's developer tools console.

This is happening on version 3.0.0.

In release 3.3.8, we declared that the Advanced Control Field is deprecated. I think this statement misses the reality of the issue with the advanced control field and exaggerates the problem. We need deprecate field logic and keep smart variables.

The problem was that field logic testing was eating our lunch when the product of record, form and event counts got high. The API call that processes field logic is too expensive to run at every page load across thousands of record * form * event combinations. We tried to optimize this but could barely improve the page load time. Yet taking the calculations out of the advanced control field and instead referencing a field that had the same calculation works fine, because each of the accessed fields was already pre-calculated and stored.

Smart Variables work fine in advanced control fields because they cost about the same as a field lookup.

I think we need to change the text in the warning to say something like "Warning: the use of equations in the Advanced Control Field is deprecated for performance reasons. It will be removed in a future version of this module." Later, we should remove the ability to process calculated fields, not smart variables.

Hi there,
We've had a different issue regarding the 'Save and go to next form' button.
Normally the redcap save &... button defaults to the last used option. However, because this EM overrides the standard method, it seems that the save button never defaults to 'Save and go to next form'. This means users need to select this option from the dropdown every time.
I can see this might be fiddly to workaround, and it's a small price to pay for the functionality of this module, but it would be good if this could be flagged in the documentation under 'Known issues' so that we can inform users.

The current branching logic behavior is:

• Before a record is saved for the first time, all forms are visible and accessible
• Once a record is saved, branching logic starts to work
  • It starts to work even if control field's form is not saved yet. In this case, control field is considered empty (no matter the existence of a @DEFAULT action tag) so all forms depending on the control field get hidden

For consistency, we need to create the abilities of:

• Enable branching logic for non saved records, so forms visibility can be set since the very first beginning
• Use control field's @DEFAULT action tag as the default control value

A complex FRSL 2.1.0 config failed to migrate to 3.x during 2.1.0 to 3.3.2 upgrade. I am providing an XML export the project and the relevant slice of the redcap_external_module_settings table. I am not able to share the data publicly, but could do so within the confines of University of Florida if that is helpful.
UniversityOfFloridaA_2018-08-15_1208.REDCap.xml.txt
frsl_external_module_settings.csv.txt

FRSL slows down the display of the record status dashboard. The script it slows down is DataEntry/record_status_dashboard.php Reducing the number of records displayed diminishes the problem, but we have production projects that take 13 seconds to display 10 subjects.

Could you review the performance on this page and look for ways to speed it up?

FRSL should not hook the behavior of the Add/Edit records page. In doing this, it slows down add/Edit records with no benefit. That page is record_home.php but without the qualifiers of an arm or id.

Revise the code at about

Hi,

there seems to be a bug with this module version 3.3.3 and REDCap 8.8.1 when using DAGs. It only happens for DAGs that don't have any records in them. The bug disappears as soon as there's at least one record in that DAG.
What happens is, when you create a new record in an empty DAG then all forms appear as enabled even though some shouldn't be according to FRSL rules. I say appear as enabled because when you actually click on any form nothing happens and you just stay on the page for the new record instead of going to the form.

Thanks for you help! It's a great module otherwise!

Howdy,

I previously submitted this issue to the redcap devs believing it was a core issue, but after experimenting it would seem that the problem stems from your EM's override of the "Save & Go to Next Form" button. When two users have created a new record and are entering data in the first instrument (i.e. both have Record 1 assigned to them) the one who hits "Save & Go to Next Form" first is, of course, correctly taken to Form 2 for Record 1. However, when the second person hits "Save & Go to Next Form" they too are taken to From 2 for Record 1.

Previous submission (redcap login of course):
https://community.projectredcap.org/questions/76216/record-id-not-updated-when-using-save-and-go-to-ne.html

I haven't been able to look over the code and suggest a fix.

Version 3.3.10
Redcap 9.5.3

Currently FRSL does not support "Auto-continue to next survey".

We are running FRSL on REDCap Standard Release 9.3.6. I just updated FRSL from 3.3.5 to 3.3.10 and now forms are not being skipped appropriately. As far as I can tell, this is only on the Record Status Dashboard, and when I am logged in as an admin. The issue goes away when I load "ALL" records or when I enter a specific record - then the correct forms are skipped. But looking at a project record status dashboard as an admin shows me all of the instrument for each record, including ones that should be skipped.

Problems seem to be associated when hiding more than 1 instrument (i.e., 2) consecutively, the survey does not seem to allow the user to progress to the next instrument.

For example:
Instrument 1
Instrument 2
Instrument 3
Instrument 4
Instrument 5 (leave as is)
Instrument 6 (skip/hide via external module)
Instrument 7 (skip/hide via external module)
Instrument 8 (leave as is)

Instrument 5 does not seem to progress when 6 and 7 are "skipped".

Hello,
I keep getting odd error emails although it seems to be working fine from the front end:

The 'form_render_skip_logic' module was automatically disabled because of the following error: Error Message: File: Line:

Any ideas of where to go from here?

When configuring the module, around control field 11, both the default and advanced control settings appear regardless of which option is chosen. I can't get either to work

frsl_dashboard displays forms it should not based on an erroneous substring match. Note how "Relevant Clinical Events szse" appears for all patients.

It should appear only for the patient SzSE1. The problem arises because there are two forms for relevant clinical events. Their names are relevant_clinical_events and relevant_clinical_events_szse. as the former is a substring of the latter, the latter is pattern matched in some places where it should not be. Here is the related configuration.

ufabi_custom_project_settings_changes for October 2017.txt

Revise frsl_dashboard.php to not display the relevant_clinical_events_szse or any other form name that is a superstring except where it is specifically mentioned.

Currently, FRSL configuration form is limited:

• Only one control field
• Only one operator (OR) for multiple conditions over the same instrument

The ideal solution for this is hijacking REDCap's branching logic form, which would be powerful and user friendly. But since this approach would take a considerable amount of time to implement, I would like to brainstorm middle ground solutions for this.

We could start, for instance, by hijacking the "Advanced Branching Logic Syntax" only - which is a simple text area field - alongside with a popup helper. Later on we could build on top of it.

@pbchase @tlstoffs any thoughts?

I'm fairly certain that line should be $controls[$i]['default'] = $cf['control_default_value']; . It looks like we are currently ignoring default values? There appears to be an additional issue on line 331, where we use "isset" to check if a value exists that will replace the default. Won't we always return true for the isset? Redcap will return the empty string for data that doesn't exist yet. Making these two changes (I just switched the last one to != "" ) I got defaults to work as I expected them to.

We have a project with 60k records, 2k fields and 16 surveys. The type of the project is with repeating events.
We are using Form Render Skip Logic - v3.3.11 in this project with two control fields. Some of the target forms are with repeating events. The configuration is valid and the module is working fine except when we would like to access the "Record Status Dashboard":

The 'hook_every_page_top' hook did not complete for the 'form_render_skip_logic' module because of the following error. Stack traces are unfortunately not available for this type of error:

Error Message: Allowed memory size of 2147483648 bytes exhausted (tried to allocate 12288 bytes)
File: /opt/rh/httpd24/root/var/www/html/redcap/modules/form_render_skip_logic_v3.3.11/ExternalModule.php
Line: 300


URL: https://****************/redcap/redcap_v10.6.4/DataEntry/record_status_dashboard.php?pid=43
Server: ****************
User: *********
Module Name: Form Render Skip Logic (form_render_skip_logic)
Module Author(s): [email protected], [email protected], [email protected]
Run Time: 392 seconds

As you can read out from the error message, we are not able to load the "Record Status Dashboard" because the module "Form Render Skip Logic" is exhausting the memory limit. The problem seems to occur in the code around line 300, while "Building forms access matrix." A possible problem source could be time complexity: reaches here cubic time (n^3).

Possible fixes:

• Increase the memory limit:
  As the typical workaround this would make things only more problematic, since our memory limit is already high enough
• Enable support for repeating events :
  As you have mentioned in your docs, repeating instruments "are not fully supported" and "[p]roper repeating events support is planned for a future release." Since I am not into the code too much I only have this suggestion:
  -- optimize code while "Building forms access matrix" => reduce time complexity
  -- fix other problems in relation with "repeating events"

Can someone who knows the code comment on this?

The EM features were rolled into REDCap.

How about releasing a new version that sets the max php version to 7.4.*?

That way people will get a heads up.

Hi everyone,
I'm using FRSL v3.3.4 to conditionnaly skip instruments, whan a patient reports no exposure to say, [exp_1] and [exp_2]. Upgrading is not an option at the moment although I don't think it is related to the issue at hand
I'm in the following scenario:
instrument_1 contains demographics, as well as [exp_1] and [exp_2], both being radio buttons (1, Yes | 0, No)
instrument_2 contains several items that are only relevant when [exp_1] = '1'
instrument_3 contains several items that are only relevant when [exp_2] = '1'

My understanding is that FRSL does its hook magic when loading instrument_1. However, this means that instrument_2 and instrument_3 aren't available by default (and for whatever reason, setting default/fallback value to 1 does not seem to change anything, even with the Advanced logic and piping in the content of [exp_1] and [exp_2]). Is there any way to fix that ?

My understanding of hooks makes me fear there's no way out: there would need to be at least another instrument right after instrument_1, so that the updated content of [exp_1] and [exp_2] triggers the hook again and makes instrument_2 and instrument_3 available.

Any hint ?
Thanks and all the best!

Hello,

We found a bug with the FRSL when using Double Data Entry module, and we were able to replicate it. Here is the XML file to create the test project: Bug_FRSL_And_DoubleDataEntry_200706.zip

Steps to reproduce the issue

1. Create a test project using the XML file provided
2. Enable the Double Data Entry Module
3. Enable the Form Render Skip Logic 3.3.11 and configure it as following:
   a. Control fields: Control mode=Default, Field=Multiplicity, Arm: Arm 1 - Event: Event 1
   b. Branching logic: Condition=2, Target forms=form_2
4. Add another user (dde_1) in your project and define it as DDE Person#1
5. Log in as dde_1 and add a new record to the project:
   a. In the first form, select Multiplicity=Twins, and click Save & Exit Form
   b. The second form should be accessible, but it is still hidden. Besides if you click Record Status Dashboard, Form 2 of this record is not hidden but if you click Form 2, you still can't access the form.

If you try step 5, but logged in as a normal user, the issue is not present.

We are using REDCap 9.0.1 but we have also tried using REDCap 9.8.4 and the issue is still present.

There are certain significant use cases that would benefit from the ability to pipe variable or smart variables in the "Condition" field.

(For example, a study may desire to double blind instruments between different data collectors such that a baseline survey cannot be seen by data collectors collecting followup surveys.)

Using FRSL v3.3.3 on REDCap v8.9.1
A repeating instrument that should be hidden is showing as accessible in both the Record Status Dashboard and Record Home Page.
If an attempt is made to access an instance the user is returned to the Record Home Page, regardless of which page the user was on when attempting to access the instance.
This is a repeating instrument in an event set to Repeating Instruments where most other instruments are not repeating.
The user cannot access the instances entered for the instrument but the display is showing the instrument as accessible.

Happy to provide further info is required.

@tbembersimeao could you please test the following use case:

• create new record
• the control field must be in the first instrument
• the second instrument must be disabled
• hit Save and go to the next form
• you get redirected to the dashboard instead of the next available instrument

I tested the rest of your test cases on PR#9 and they work as expected.

Hi,

the changes introduced in 3.3.8 cause FRSL to display the status of instruments incorrectly on the record home page. For example when I try to access a certain instrument that should normally be greyed out (but isn't) the page simply refreshes and only then shows it as being greyed out.

Trying to install the module and receiving the following message:

REDCap crashed due to an unexpected PHP fatal error!

Error message: Uncaught Exception: The request to retrieve the name for module 683 from the repo failed: . in C:\inetpub\redcap\redcap_v10.3.3\ExternalModules\classes\ExternalModules.php:4320 Stack trace: #0 C:\inetpub\redcap\redcap_v10.3.3\ExternalModules\manager\ajax\download-module.php(6): ExternalModules\ExternalModules::downloadModule() #1 {main} thrown
File: C:\inetpub\redcap\redcap_v10.3.3\ExternalModules\classes\ExternalModules.php
Line: 4320

Is it possible that the module is designed for a different version of Redcap (10.3.3) or PHP?

Thanks

Hi,

9.0.3 broke the module when clicking Add / Edit records showing the following error:

The 'hook_every_page_top' hook did not complete for the 'form_render_skip_logic' module because of the following error:

Error Message: Uncaught Error: Call to a member function getUniqueEventNames() on null in /var/www/html/redcap/redcap_v9.0.3/Classes/LogicTester.php:336
Stack trace:
#0 /var/www/html/redcap/modules/form_render_skip_logic_v3.3.5/ExternalModule.php(305): LogicTester::logicPrependEventName(' if(chkNull([sc...', 'screening_phase...')
#1 /var/www/html/redcap/modules/form_render_skip_logic_v3.3.5/ExternalModule.php(374): FormRenderSkipLogic\ExternalModule\ExternalModule->getFormsAccessMatrix(157, NULL)
#2 /var/www/html/redcap/modules/form_render_skip_logic_v3.3.5/ExternalModule.php(51): FormRenderSkipLogic\ExternalModule\ExternalModule->loadFRSL('record_home', NULL)
#3 [internal function]: FormRenderSkipLogic\ExternalModule\ExternalModule->redcap_every_page_top('22')
#4 /var/www/html/redcap/redcap_v9.0.3/ExternalModules/classes/ExternalModules.php(1415): call_user_func_array(Array, Array)
#5 /var/www/html/redcap/redcap_v9.0.3/ExternalModules/classes/ExternalModules.php(1508): ExternalModules\ExternalModules::startHook('form_rende
File: /var/www/html/redcap/redcap_v9.0.3/Classes/LogicTester.php
Line: 336

New save option in REDCap 7.6.0 might create problems for the frsl_data_collection_instruments hook. Please test this hook in RC 7.6.0 to see if the new save options create problems.

I am on REDCap 9.1.1 and using version 3.3.7
In an event on a longitudinal project in production mode, if a user is on a form where the module has hidden the rest of the forms in the event, but there is another form in the event that is hidden due to user rights, but not hidden by the module, REDCap displays Save and go to next form. That takes the user to the form that should be hidden because of user rights, and the user gets an unauthorized message for that page. This doesn't happen in development mode.

The issue occurs here:

params.id is HTML escaped, but the key in formRenderSkipLogic.formsAccess is not! REDCap::escapeHtml() does not translate a space ( ) to a plus (+)!

Hi,

This has been a great tool for us and I was wondering if it was possible to add support to control/select the event in which a form is skipped.

Many thanks to your team!

Hi!

Can anyone please tell how can i skip forms using multiple control fields in FRSL?
It is kind urgent for a project submission.

Thank you.