How do I enable Smart Identification for an Object?
It was added to OR with SI enabled but I am not sure why it got set to FALSE. How do I set it back to TRUE for this Object?
Smart identification basically has two phases.
When the test object is created (via record or learn) if SI is enabled all the properties needed for identification are captured
When a test is run, if SI is enabled the properties captured may be used if the regular properties aren't good enough.
One of the implications of this is that the SI settings that were active when the object was created impact the identification during run. If you change the set of properties, the original properties are still used. Since in your case no smart identification properties were captured the Enable Smart Identification option is disabled for this object.
tl;dr;
The solution to your problem is to enable SI for you object and then run the test in Update Run Mode (be sure to check the Update test object description checkbox).
Related
The code below shows that I am trying to get the "encodedpassword" attribute value from the User type's JsonAuditRecord using the ReadAuditGateway.
JsonAuditRecord userJsonRecord = getUserJsonAuditRecords_withReadAuditGateway(query);
String encodedPassword = userJsonRecord.getAttributeAfterOperation("encodedpassword");
System.out.println(encodedPassword); //Hybris1808 would print the actual encoded password
System.out.println(encodedPassword); //CX2011 prints **** instead
After upgrading to CX2011, I found out that the User type's encodedPassword is audit blacklisted. Also, any blacklisted attributes would have their value obscured e.g. ****. I understand the rational behind that (possibly a security enhancement). However, to allow our custom code (that requires the un-obscured value of the encodedPassword) to continue working, I have tried to remove it from the audit blacklist by making sure that the two properties below are not set with any value in my local.properties
audit.user.blacklistedProperties=
audit.userpasswordchangeaudit.blacklistedProperties=
However, after performing "ant all" and restarted my local Hybris server, the encodedPassword is still obscured..
May I ask other than changing those properties above, are there other steps that need to be done? e.g. overriding some OOTB methods.
Also, I have tried to read the Audit Report section in the SAP Commerce Documentation, I do not see the audit blacklisting part is being documented. I would appreciate if someone could also provide any links that relates to this topic.
audit.user.blacklistedProperties=encodedpassword
audit.userpasswordchangeaudit.blacklistedProperties=encodedpassword
Those two properties above are already defined in one of the project.properties files as shown above (where 'encodedpassword' is blacklisted). Thus, if we were to leave those 2 blank in the local.properties file, Hybris will treat it as NULL and it will ignore/skip it. In other words, it won't do anything by declaring empty properties.
To rectify that, the easiest way is to assign some other fields as the blacklisted properties in the local.properties file.
e.g.
audit.user.blacklistedProperties=fooAttribute
audit.userpasswordchangeaudit.blacklistedProperties=fooAttribute
I used some of the Hybris reserved Deployment code and then later changed to non-reserved deployment type codes. Do I need to Initialize the system in-order to reflect the changes with new deployment code or just an Update works. There are many items that deployment code has been changed. Why update doesn't work?
When you use a reserved code in your deployment table, you're likely to add the attributes of your object in an existing table. If you have attributes with the same name, it'll surely be a mess in the table (I don't know how hybris will choose the table type for example).
When you run an update with the good deployment code, it will create a new table which is just fine. The other table which has been used by two objects will still remain potentially broken because hybris won't delete any column.
That's why you should initialize your system to have a clean DB. The issue is that you'll lose all your data.
If you need to migrate data it will be probably quite hard because you must have to look on the broken table and distinguish between the attributes that should not be there and the others. So I hope for you that it's just a dev issue!
Actually i would suggest you to do initialize rather than update more likely that the update will not work for you in this case and probably you will get some error messages saying invalid pk xxxxxxxxxxxx because of unknown typecode yyyy.
As you may know the typeCode (deployment code) is an essential operator for the generation process of PKs in Hybris and thanks to it Hybris can ensure the uniquenessity of the PKs, so even if you change the old typeCode with a new one it's very likely that Hybris will still keep the old typeCode somewhere hence PKs already generated will never be consistent with the new typeCode.
So that's why you should never change the typecode of an item once given.
My suggestion is :
To make a backup of your existing data (you can export it from HMC,
you may take a look at alain.janinm's answer here).
Then initialize your System.
Then re-import the data again.
Note : that typecodes between 0 and 10000 are already reserved for hybris
particular items.
SuiteScript v1, but I'll switch to SS v2 if it's the only way to make it work.
I've tried:
salesOrder.setFieldText('shipcarrier', 'More');
salesOrder.setFieldValue('shipcarrier', 'noups');
salesOrder.setFieldValue('shipcarrier', 'nonups');
But UPS is always selected once the record is saved.
shipcarrier is a bit of an odd thing.
I'm not sure it is actually sticky - in some contexts it appears to be and in some it doesn't.
It appears to be pointless to set unless you are also setting shipmethod.
salesOrder.setFieldValue('shipcarrier', ffShipCarrier); //'ups' || 'nonups'
salesOrder.setFieldValue('shipmethod', ffShipMethod)
PS from cja: My conclusion/solution: Setting shipmode does nothing unless recordmode is dynamic and shipmethod is set at the same time. If both those conditions are met then the value shipmode will be updated.
NetSuite support have warned me against using this solution:
"With regards to your concern, I am able to set the Ship carrier field on the Sales Order record in the client script(nlapiSetFieldValue('shipcarrier', 'ups');) however I was unable to set the value of the field in the server side script. Upon further investigation, the field (ship carrier) isn't exposed in the Record browser hence the field isn't officially exposed for scripting needs. Please refer to the following Suiteanswer article for your reference.
"I am really glad that the solution worked for you perfectly. In order to explain further, I would say it is not advisable to write scripts using unexposed fields in the record browser. It may change in the future without any prior notification and can cause problem and NetSuite will not hold any kind of responsibility for the same.
"User groups contains simple solution to complex tips and tricks provided by the experienced customers. On the other hand, NetSuite Support are stickly adhering to the official documentation/processes to assist any of its customer. The solutions provided in the User groups are totally upto the consent of the customers and can be implemented at their own risk if not confirmed in the official documentation or NetSuite Support."
You need to use setFieldValue and pass the internal id of the "More" ship carrier.
nlapiSubmitField('salesorder', recordid, 'shipcarrier', 'nonups');
I am trying to figure out how you can specify that context.newRecord be in dynamic mode. I have a beforeSubmit UE script and I need the record to be in dynamic mode.
In 1.0, I can just do nlapiGetNewRecord({recordmode: 'dynamic'}); but if I tried context.newRecord({isDynamic: true}), I get an error.
Unfortunately, you appear to have taken advantage of an undocumented feature within SS1.0:
SS2.0 shows the type as DeferredDynamicRecord (the same as record.load({...isDynamic:false})) vs. DynamicRecord as you get when using record.load({...isDynamic: true})
Even worse, the context object appears to contain a copy of the newRecord object, and is not (at least at the time it's available to us) actually executing an api call to retrieve it.
All signs point to you can't edit the newRecord object in dynamic mode in either of the *Submit methods.
What's the difference between NSLocale currentLocale vs autoupdatingCurrentLocale? It's not obvious from reading the documentation.
When the user changes their system locale settings, the autoupdating one automatically updates to the new locale.
The currentLocale only retrieve an locale object one time from the current user's settings. autoupdatingCurrentLocale updates the locale object on the fly so you don't need to validate. You might think autoupdateingCurrentLocale is the prefer way, it is per Apple documentation; however, since the returned object may be cached, you don't really need to hold on to it indefinitely when using currentLocale, verse autoupdateingCurrentLocale.
If you are using autoupdatingCurrentLocale, note that this API do not cache the locale object, so you will need a way to compute cache upon receipt. One way is to use notification such as NSCurrentLocaleDidChangeNotification method call.