Is JS access to userProperties working in GS9.3?

[Vaguery]

Trying to run the following simple script, and nothing is changing in the listings I’ve selected. The manual says get/set both should work for both listings and inventory items. Am I missing something?

function run(){	
	let these = selectedListings;
	these.forEach((listing) => {
		listing.userProperties["CBLOCATION"] = "BK01";
		consoleLog(listing.title + " : " + listing.userProperties["CBLOCATION"]);
        // just checking! and lucky thing, too!
	});
}}

When I run this, I get the titles, but nothing has changed in userProperties. I also cannot add a new key-value pair.

In other words, it seems like this should work for anybody; it should (1) set the value of a key called “CBLOCATION” whether that exists or not, and (2) read the updated value and print it.

[ilja]

Something seems to have changed (in macOS?), that prevents the JavaScript engine from changing a listing’s userProperties. I’ve slightly tweaked the whitelist of what listing properties are readable/writeable from JavaScript, and now it seems to work again as intended.

Fix will probably be in 9.3.1 release, let’s if there are other low hanging fruits to be picked.

[ilja]

While toying around and I discovered the problem might be with your particular JavaScript. Can you run this code and see if it works as intended?

function run(){
	for (listing of selectedListings) {
	  var userProps = {"CBLOCATION" : "BK01" };
	  listing.userProperties = userProps;
		consoleLog(listing.title + " : " + listing.userProperties["CBLOCATION"]);
	}
}

[Vaguery]

Well it completely replaces the entire userProperties map, destroying any other key-value pairs that have been set.

[ilja]

That’s easily fixed:

function run(){
	for (listing of selectedListings) {
	  var userProps = listing.userProperties;
	  userProps["CBLOCATION2"] =  "BK01";
	  listing.userProperties = userProps;
		consoleLog(listing.title + " : " + listing.userProperties["CBLOCATION2"]);
	}
}

[Vaguery]

Yes I was just coming back to provide this.

OK so… thanks? But also meh?

I mean, yes it is a fix for now, but it’s sort of magical handwaving isn’t it? Pulling a coin out of your ear. Why should a script have to duplicate the listing’s map, change that, and then replace the original with the new one?

BTW, the same trick also works fine with the JS I provided. The problem is not the syntax I used, but rather that the User Properties map does not have a working setter in the app. In other words, you cannot set a particular user property, you can only replace the entire user properties map.

later

This minor improvement of my older code also works:

function run(){	
	var these = selectedListings;
	let targetKey = "CBLOCATION";
	let newValue = "BK01";
	
	these.forEach((listing) => {
		var updatedProperties = listing.userProperties;
		updatedProperties[targetKey] = newValue;
		listing.userProperties = updatedProperties;
		consoleLog(listing.title + " : " + listing.userProperties[targetKey]);
	});
}

[rlmartin]

Here is some low hanging fruit to be picked. Quantity is all moved to zero (0) during an automatic end and restart listing scenario in listings with variations in 9.3.

[ilja]

The current behavior is owed to the fact, the the userProperties dictionary is a temporary object, which is derived on the fly from GarageSale’s internal representation.

So unless you re-set that dictionary in your listing after modifications with something like listing.userProperties = userProps, your changes will get lost.

[ilja]

Thanks for the heads up. Do you know if your variations are linked to inventory items through their SKUs?

[rlmartin]

No, I don’t use inventory in the sku

[Vaguery]

@ilja

So unless you re-set that dictionary in your listing after modifications with something like listing.userProperties = userProps, your changes will get lost.

Got it! It does the job, and I do appreciate your help.