I have a requirement where i am importing some attribute data through integration into maximo.However the client demands the field value needs to hidden or encrypted with special characters and only the last few numbers to be shown similar to a bank account number. How do i achieve this?
An example suppose the field value is 1234567 client wants this to be shown as ****567
Here's a simple solution that should do it: define a persistent attribute (accountnum) to save your account number and a non persistent one to display its partially masked version (maskaccountnum).
Create an attribute launch point automation script to initialize the non persistent value.
Python Example:
if not mbo.isNull("accountnum") :
mbo.setValue("maskaccountnum", "****" + mbo.getString("accountnum")[-3:])
Add your non persistent attribute to your application.
I created a non persistent attribute as stated by JPTremblay.
and upon getting confirmation with client for a fixed range of numbers for the attribute ACCOUNTNUMBER there was no need for a dynamic script.
so i just created a object launch point script.
event is chosen as Initialize
and just one line of code
mbo.setValue("maskaccountnum", "************" + mbo.getString("accountnum")[-5:])
this did the trick. Language was chosen as Jython.
Related
I am trying to implement automatic phone number formatting into NetSuite I am having some issues getting my script to work. Basically if someone enters a phone number into a customer record, "1234567890" for example, it will automatically format to "(123) 456-7890". You can see my script below along with the error message I receive when creating a new script record.
Fail to evaluate script:
{"type":"error.SuiteScriptModuleLoaderError","name":"UNEXPECTED_ERROR","message":"missing ; before statement (SS_SCRIPT_FOR_METADATA#21)","stack":[]}
Why do you need a script for this? NetSuite already does this, based on the Phone Number Format setting at Setup > Company General Preferences. Check you have this field set correctly according to your preference.
If for whatever reason it turns out you do need a script for this, there are several issues with the script you posted:
There is a syntax error - mismatched parentheses/braces. Your code editor is trying to show you that with the red brace on line 8 and the red squiggly underline on the last parenthesis (line 23).
NetSuite record level client scripts must implement an entry point function. For formatting phone numbers this would be a fieldChanged() entry point. You would need to wrap the logic contained in lines 10 to 20 inside a function, and then reference that in the return statement at the bottom. EG: If you called the function phone() your return statement would be return {fieldChanged: phone}.
You are using SuiteScript 1.0 API functions (nlapiGetRecordId() and nlapiLoadRecord()) in a SuiteScript 2.0 script. Under some circumstances these functions may be available so it might work, but even if it does, it certainly isn't best practice.
Loading the record isn't necessary. When you implement an entry point function, the function is passed a context parameter. IE: function fieldChanged(context). That context parameter contains a reference to the current record (context.currentRecord). Work with that instead of attempting to load the record separately.
We have been running a SSRS report subscription in share point integrated mode for last 6 months.It was fine. This report had cascaded parameters which is auto populated based on user's access.For data driven subscription the user name was passed and internally other 4 access level parameter which are each a multi select parameter get populated. From last few days subscription was not going out on schedule time and below error was displayed. Even if we pass only one user from the query who has all proper access we are still getting the same issue. Also the parameter name which is displayed having no default or user defined value get changed. we have checked most of the users and they have proper access i.e value derived for each of the cascaded parameters.
Error: This report requires a default or user-defined value for the report parameter 'XXX'. To run or subscribe to this report, you must provide a parameter value.
The cascading parameters are like below
AAA -> XXX->YYY->ZZZ
Earlier the error message said parameter 'YYY' was missing a value.
As users come and go and move positions you will inevitably run into issues with their access. What I would suggest is that for each cascading parameter, have a default value that gets selected when there are no actual values available. For example, the value could be "N/A". And the report should successfully run and return no rows. You could even add a No Rows Message to it.
Basically what I want to do is create a form whilst within another form and pass values from the earlier form to the second. Complicated I know but here is what I got.
#Do(#Command([Compose];"LPK"); #SetField("PR_Make"; PR_Make))
The fields in both forms have the same name and this code is called when first document is attempted to be saved.
I think instead of editing the field on the second form it just saves a field as itself instead. Any help appreciated.
The best and common way is to enable form property "Formulas inherit values from selected document" in second form "LPK".
Add a default value formula to second form's fields you want to inherit and put just the name of field itself in. For your example default value formula it would be
PR_Make
Make sure you save document first and then create the new document.
Knut Hermann's answwer is the 'standard' way of achieving such things but there are other methods- eg you can use environment variables ..
Something like:
#Environment("PR_Make") := PR_Make;
#Command([Compose];"LPK");
Then set the default value for PR_Make in your new form as ..
#Environment("PR_Make")
FYI Environment variables are written to the user's Notes.ini file and so remain even after Notes has been closed and re-opened. #Environemt doens't work too well with Web applications as it uses the server's notes.ini.
An alternative would be to use profile documents:
#SetProfileField( "PRDefaults"; "PR_Make" ; PR_Make;#Username);
#Command([Compose];"LPK");
.. in the default field for PR_Make on new form :
#GetProfileField( "PRDefaults"; "PR_Make"; #Username);
Profile documents are stored as a kind of hidden document in the Notes database and persist with the database. The last parameter sets a further subdivision by username so each user gets their own profile doc - a bit like a personal profile for "PRDefaults". You can miss this last parameter #Username out, to have one profile doc per database but there's a risk of two people trying to use it at the same time and clashing.
Profile docs also work with web applications.
I am using load runner 9.5. I am facing a problem during Dyanmic data handling. Scenario is given below-
I have Library management application. Login-> Select book(data display based on User credential) -->Purchage and Logout.
Ex: Guest user: 50 Books display to choose
Admin : All Books display choose
Normal user : 100 Bokks display choose
Please help me How to handle these type of dynamic data based on user role. Is there need to create different script with different role ?
Please follow the below steps -
Record the same flow with the same user credential 2 times (Replica of first script)
Compare the scripts using W diff
Find the values which are different like purchase order, timestamp and user session.
Correlate the values which are highlighted in yellow means value which is different in each script.
Have you had the benefit of training in LoadRunner and a mentor for your first year of work in this field?
For the documents stored in the database, I would like to create a human readable key to uniquely identify the document. e.g. PO20090110-001. How do I go about doing that?
When saving a document you can put together the first part of the number by using the date or any technique you like (ej. "PO" & format(date, "YYYYMMDD") & confDoc.getitemvalue("doccounter")).
As for the counter I like to store it in a configuration document and update it when each doc is saved. If there are lots of documents created during the day you can run into rep conflicts on you configuration document, if this is the case you can have an agent on the server do the actual assigning of the number, the drawback to this is that you don't get the number right away when saving.
Hope this helps.
One solution used in our help desk is to take the initials of the current user and add it to the a number in the last document in a view. Add one to the number and store that it the new document along with the ititals and the new number as the key.
It's not simply.
Create field for uniquely key and this key saving onSave (or other event), but you must protect this number to be unique.
You can create agent, which checking number on domino server and if agent find conflict then notify application administrator or other responsibility person to resolve this.
Or each replica generate own number and after replicate on domino, agent assign number in right format.
You can create a "nearly" unique key in Domino simply by using the #Unique function, with no arguments. This will generate a string key, based on the current user's first and last name and the current clock time. You will end up with a string something like: "ESCR-12345678".
I say "nearly" unique, because it is not really like an identity column in SQL - Domino does not guarantee it will only give out a particular string once. If you use #unique in a server-side agent which generates many id's at once - for example, and agent that loops and uses #unique within the loop, you can get into a situation where #unique will return a duplicate - because you create 2 docs within the same second and because your "username" is always the server's canonical name. But, outside of that scenario, #unique is generally safe to use.
If you then need to open or reference docs by this ID, just create a view sorted by that ID and you can a url in the form ../myView/id?readDocument.