seejay

Members
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    1

seejay last won the day on April 12

seejay had the most liked content!

About seejay

  • Rank
    Level 2 Stud

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. That was it! Thanks Nathan.
  2. This is probably not specifically an issue with the RB API and more about something I don't understand in python requests, but I've researched the latter and tried a lot of different things, so I thought I'd ask here for help. I'm trying to use a python requests to generate a PUT request to update a part in a partslist (changing the quantity, all else remaining the same). Based on the curl command in the API docs, I've tried: url = 'https://rebrickable.com/api/v3/users/token_goes_here/partlists/part_list_id_goes_here/parts/3001/0' headers = {'Authorization': 'key key_goes_here', 'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json'} data = {'quantity':17} #I think the problem is here r = requests.put(url,headers=headers,data=data) This structure is working for other http requests (delete, get), but those don't have a the data element, so I think the problem is there. I've also tried a few variations on formulating the data element: data = {'quantity':'17'} data = '{"quantity":"17"}' data = '{"quantity":17}' #and in desperation data = 'quantity=17' No matter what I try, I get status code 400, bad request. What am I missing? Thanks in advance.
  3. Hi Nathan. The original bug I started this thread with is back. Perhaps you just had to revert something and are aware, if so please ignore. But as of today, I have 60 parts without images the list, where as a couple of days ago, it was 0. I checked a few of them and all them had photos. You can see the first few in the screen cap.
  4. Thanks Nathan. I've never used that button and had become so used to ignoring it that I simply didn't even think of it. Would it make sense to have that button be checked by default? It seems like if a user is searching for a part, whether or not it has been included in an inventory wouldn't matter most of the time. And perhaps add a little hover text explaining what "unused" means. I think when I first started using the site I thought maybe it was parts that weren't "real" (colors that had never been produced or something), so I just didn't use it and eventually stopped seeing it.
  5. These two minifig heads are identical prints, one with a hollow stud and one with blocked open stud. https://rebrickable.com/parts/3626bpr0760/minifig-head-imperial-pilot-face-mask-and-silver-goggles-print-blocked-open-stud/ https://rebrickable.com/parts/3626cpr0760/minifig-head-imperial-pilot-face-mask-and-silver-goggles-print-hollow-stud/ Only the first is returned by searching for "silver goggles" (+ minifig heads + black), even though both use this phrase in the part name. I assume this is because the second one has year = "0 to 0". Even searching with the specific part number "3626cpr0760" still returns only the entry for 3626bpr0760. I don't think this is an error in the database; the years when the "hollow stud" version were produced seems to be unknown (both of these parts have only ever been used in a single set). However it means the part is not findable using the current search interface. Even tweaking the search URL to specify min_year=0 and max_year=0 (or 0000 for that matter) doesn't return any parts. I'm not sure how many parts there are with ambiguous years, but it would be great to make them more searchable. Perhaps consider adding, in the parts search panel, an "any year" checkbox to disable the time slider filter? I've attached a mockup to show what I mean, but I'm sure you'll have better ideas how to handle it. Thanks again for all your hard work on a site that I use and appreciate a lot!
  6. That makes sense. Thanks for looking into it.
  7. Thanks Nathan. Now I seem to have the opposite problem: I've gone from having several dozen parts in my "parts missing photographs" list to having only 2! I'll attach a screen cap. Looking back at the screen cap from my original post, the second item is part 11203 in tan, which is still in my inventory and doesn't have a photo. Maybe something will reindex overnight? I'll check it again tomorrow. --cj
  8. Hi Nathan, I just checked again (this time from a different computer to avoid any cache issues), and it is still happening. Thanks for looking into it.
  9. Thanks Jared. That's useful to know. I was planning to break out the light box and take some photos as I've done in the past. But I've also been recently submitting change requests to improve the generic descriptions on some printed minifig parts, and those were taken largely from BL (and noted as such in the change request). So your comments here are helpful. You may want to consider adding some text about that to the change request dialog.
  10. I just discovered your very handy page for listing parts missing photographs that I can contribute (https://rebrickable.com/parts/photos/missing/). I clicked through on a few and noticed one that actually has an image in the color that is shown as missing in the list. Part 11090 shows as missing an image for color = black (see screencap). But clicking through shows that there is an image for that color.
  11. Hi Simon. Your workaround works perfectly,. Thanks for that. I'm happy to document the differences. I spent a bit of time comparing the two to find them myself earlier today. I'll do that as a change request.
  12. Using Win10, Chrome 73.0.3683.103 I'm not sure if this is a bug or a feature request or somewhere in between. It appears that switching from the "default" version of a set's inventory to another version does not impact the inventory that is used when clicking "build this set". This behavior is sort of indicated by the interface, because switching inventory versions does not affect the version shown at the top right on the page with the part count, and the "build this set" button is in that panel. Still, a user might expect changing the inventory version would impact the inventory used for the build calculation, especially since the build button is just next to the inventory display (see screen cap) To replicate: From https://rebrickable.com/sets/8880-1/super-car/#parts, switch from the "default" version 2 to version 1. Click "build this set" Change my default build settings to NOT ignore mold variations See that 6540b is reported as a missing part. This part is from v2 of the inventory. v1 uses 6540a. If, as I suspect, this is not a bug but rather a feature that is not yet built, please consider this as a feature request, but admittedly an edge-case. The only reason it came up for me is that I bought a bunch of used parts in bulk and it contained this super car set (v1 inventory), but with a few missing parts. In trying to figure out what to buy, I ran into the unexpected result above. Thanks, cj
  13. Hi Ian. It's in python 3. I'll send it by DM. For uploads into your parts lists, Rebrickable has great import functionality from almost any source you care to work with via the interface. For my initial inventory (for which I spent a long time counting a lot of parts), I entered the inventory into a csv and imported that. There's nice error reporting in the interface to help catch mistakes. I've also imported directly from Bricklink and Brickowl orders using the Rebrickable interface. All of those work reliably for me, so I haven't felt the need to build anything for uploads (or even set up a local db beyond the CSVs the script generates), but of course everyone's workflow is a bit different. It's awesome that Rebrickable makes that flexibility possible via the API.
  14. Thanks Nathan. I looked at this again before sending to you just to make sure I wasn't confused. Looks like I was confused. 4265c should map to 32123a (not b as I stated above). So, the import is behaving correctly. What I also noticed, and I think this was the source of my confusion, is that Bricklink (and Studio) don't make a distinction between 32123a and b. The mold change is noted on the catalog page: https://www.bricklink.com/v2/catalog/catalogitem.page?P=4265c#T=P So, I think the short (or is this long?) answer is that I need to edit all the 32123b in my inventory to 32123a so that future imports from Bricklink sources will work. Please close this one.
  15. Hi Ian, I have an ugly little workflow that I knocked together in Python (mainly using Pandas), with Dropbox to move the result around, and Google Sheets to view it. It runs nightly from my local machine and pulls out all my parts list into a single CSV (with a column indicating which Rebrickable part list the part is from). It creates a date-stamped version of the CSV (for backup) and a "always the latest" version. The latter is synced to Dropbox and I have a Google Sheet that reads it live (using the IMPORTDATA function). This workflow gives me a backup of my parts lists and and a quick way to search for parts in Google Sheets if I don't want to go through the Rebrickable interface. I find that I use both Rebrickable and the Google Sheet depending on what I'm doing. Also, as an intended benefit, I can go back through the date-stamped versions to see how my parts total has changed over time, which is probably about the nerdiest thing I've ever done for fun. If that sounds like it might be helpful to you, send me a DM, and I can send you the script. You'd need to be comfortable in python to make any sense of it, but it sounds like you probably are. --cj