JavaScript and User Properties?

I’m close to being able to build a new way to manage location-based inventory (see huge thread elsewhere), using existing GarageSale features, though it will not solve all the problems down the road.

Briefly, the ideal would be to store more info in the Inventory record, but I think I can do a little work just using the Listing records and User Properties.

The idea I’m exploring is to use a GarageSale Group to hold items with a User Property like LOCATION set to the name of the box it’s in. So listings of items in box “A0001” would have a User Property MY_LOCATION set to A0001, and so on.

I would still be stopping and re-starting listings randomly to generate hits on eBay, but with luck that is possible without losing the visible structure or the User Property values.

Good news!

  1. If I have listings stored in nested Groups, and I select a discontinuous subset of the listings without moving them out of the nested Groups, I can stop them, modify them, and Start them again without them moving.
  2. If I select all the listings in a “location” Group, I can edit the User Property manually describing where they are.
  3. When I stop and re-start those listings, the User Property is retained across launches.
  4. I can create a Smart Group which contains only listings with the User Property Key and Value I specify, which would be helpful just in case the Location nested structure I might build by hand gets borked.
  5. I can actually use the SKU field for what it’s intended for, maybe; that is, as a link between the Listings and Inventory item. But (see below)

Neutral news!

  1. I’m not sure how, if at all, I can use JavaScript or AppleScript to read or modify the User Properties map. Is there an exposed variable there, @ilja? I do not have a use case for this yet, but I am hoping to be able to assign my “location” User Property using a script based on a spreadsheet I can build, rather than doing it manually in GarageSale. (The editing interface in the app is good if I already have selected the 20-30 items in a location, but finding those will be easier if I work from a list)
  2. I’ll need to be able to print a table or report, somehow, which shows sold listings by title and their LOCATION user property. That also doesn’t seem reachable unless I can touch the User Property map… and maybe also create a Report?
  3. When I create a Smart Group that contains listings with matching User Property key/values, none of the stopped or deleted ones appear. Is that just normal Smart Group behavior?

Bad news!

  1. By moving inventory information into listing records this way, I am 100% abandoning the usefulness of the actual GarageSale Inventory table and interface, which I really want to be able to use. It’s only because I have unique items that I can do this at all; other people with “real” inventory would not be able to do this sort of thing.
  2. I could now possibly use the SKU to track re-listed items and fees over time, except that there is still no obvious way for me to create an inventory item for the listings I’m currently managing. It would also be much simpler (and safer!) if I could store the LOCATION info and other things in the Inventory record, and have those propagate to the listings automatically…
1 Like

There’s a lot of to digest in your post. I’m not sure I get 100% what your workflow would be, but here you go:

That’s shouldn’t be too hard to add. Naively speaking, most of the UI for editing user properties from the listing section should be easy to re-use in the inventory section.

Right now, user properties can neither be set from either of these. JavaScript support would be very easy to add, but getting your Location property data from whatever source you have into GarageSale might be tricky.

AppleScript support would be a little more work and perform a little slower, but since AppleScript already are processed by the AppleScript system outside of GarageSale, getting external data in their should be easier.

Sounds to me as if some kind of filter setting, that restricts Reports to a certain group of listings might be helpful here.

Deleted items are excluded from Smart Groups by default. But listing that match your ‘user property’ rule should definitely show up, regardless of wether they are running or not.

1 Like

This sounds promising.

Having the ability to add and search/filter on Inventory item User Properties would be a much better as a fix for me than using the existing behavior in Listings, since it would give me the ability to aggregate fees over several listings. Being able to script them in either place provides other, more subtle helpers. And being able to refer to them in Reports, by any mechanism, would be a direct help.

You would want to be careful not to make things redundant or confusing for other/future users, though. The easiest question to ask (and I don’t know the answer) is whether there should be one set of “User Properties” for an Inventory item, which is automatically copied (or joined) with its Listing records, or whether they are separate fields in the two tables that behave in the same way.

¯\_(ツ)_/¯

I’m leaning towards only having a single set of user properties within the Listing record. When you edit a property that was “inherited” from an inventory item, a warning pops up, asking you if you really want to change the property from the value in the inventory item.

Correspondingly, when you edit/add/remove a property in an inventory listing that has linked listings having the same value for that property, an alert shows up, if you want to update the linked listings as well.

1 Like

Sounds perfect. The “workaround” would be to diversify your keys if you really need “extra” information on one side or the other. But then there is also a backup of those, which is good.

Just read your other thread, and now I have questions. You wrote:

  1. Every few days I “cycle” all my fixed-price listings. I stop some of them (a random selection based on SKU) and possibly change the prices, replace their SKU numbers with random UUID values and re-launch them.

Why do you change the SKU while re-listing? If you kept the SKU the same for all listings of the same book, you wouldn’t need inventory items at all, would you?

A1: historically I change the SKU every cycle because my habit has been to (1) launch listings in a random or semi-random order, and (2) a superstition that certain changes in listings “freshen” them for the eBay server-side algorithms.

There is no other field in the viewer window to sort by, except SKU, and there is no extra space in my titles, so the first thing I thought of that would work for random subsetting was just sorting on random values. I have never liked doing this, and am trying to stop. I can, I think, select a bunch of things in a Group/folder, and then randomly de-select some of them. Or the other way around. Doesn’t matter.

I also don’t think the eBay “new listing” algorithms are as stupid as they used to be, and I doubt changing the SKU makes a difference anyway. To be honest I think the weather has a larger effect on my sales, since people shop for my stuff when it is cold or rainy.

Hey, while you’re planning, could you add that? Weather control?

I definitely, explicitly do not want to abuse the SKU field any more. It’s a bad solution to a problem I can solve many other ways.

A2: Almost.

I do need inventory items, because “location” is not the only thing I want to store. Ideally I would be able to store private info regarding financials, consignments, planning and so on in the User Properties of Inventory items, and have those move to the Listings.

I do definitely think the Inventory/Listing separation is important. The Inventory item should be the thing I have in my hand. The Listing should be the proposal I upload, for 3-30 days, on eBay. Historically you have been focusing on the Listing side, and that is correct as far as I can see. And you’ve added so much behavior to Listings that I can get very close to doing Inventory tracking indirectly.

But it smells bad, in the technical sense of business modeling. With just a few more fields in Inventory records, and the ability to read and write, report, and possibly script them, I can actually do things that make this a business-capable program, rather than a consumer program that I can sort of kind of get to work.

Also, if you do this and it works the way I think it might, I’ll be happy to make tutorials and/or videos…

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.