|
|
|
|
@ -1,3 +1,5 @@
|
|
|
|
|
import debounce from "lodash.debounce";
|
|
|
|
|
|
|
|
|
|
export const noop = () => {};
|
|
|
|
|
export const enterKeyPressed = (cb = noop) => ({ charCode }) =>
|
|
|
|
|
charCode === 13 && cb();
|
|
|
|
|
@ -60,7 +62,93 @@ const notesStore = {
|
|
|
|
|
}),
|
|
|
|
|
createNote({
|
|
|
|
|
title: "this is not an ass 5",
|
|
|
|
|
content: "this is an ass note",
|
|
|
|
|
content: `
|
|
|
|
|
# Secret info about database
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct_catalogs
|
|
|
|
|
- ncatalog_status
|
|
|
|
|
- null when the catalog isn’t published/proofed
|
|
|
|
|
- ‘online’ when the catalog is publically visible
|
|
|
|
|
- ‘live’ during live sales
|
|
|
|
|
- ncatalog_type
|
|
|
|
|
- 1 Timed Sales
|
|
|
|
|
- 10 White Label
|
|
|
|
|
- 1/11 Gold
|
|
|
|
|
- 2/12 Platinum
|
|
|
|
|
- 3/13 Platinum Plus
|
|
|
|
|
- 1 Timed
|
|
|
|
|
- 10+ White label
|
|
|
|
|
For ncatalog_type 1 and 11 were "Gold," 2 and 12 were "Platinum," 3 and 13 were "Platinum Plus," but now 1 will typically be timed sales and 3/13 will be traditional. 10 is white label _only_ which means that the auction is not displayed on our site, except by direct URL. 10 + the level (1,2,3) means the catalog can be accessed as white label _and_ is displayed as a normal catalog on our site. ncatalog_type = 10 is really the only important functionality of that variable now, but there are still some gotchas lingering.
|
|
|
|
|
|
|
|
|
|
- auction_type
|
|
|
|
|
- ‘j’ = jewelry only
|
|
|
|
|
- ‘c’ = ‘Business and Industrial’ or ‘Real Estate’ or Automotive categories
|
|
|
|
|
- ’t’ = ‘Dolls and Toys’ category
|
|
|
|
|
- ‘a’ = timed (?)
|
|
|
|
|
## auctioneers_auct2_lots_sold
|
|
|
|
|
- Lots sold; 1 = sold, 2 = not sold
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct2_np_bid_history
|
|
|
|
|
- The bidder_id in np_bid_history is 0 for competing/floor bids sourceid = 1 is also for floor bids.
|
|
|
|
|
- sourceid: 1=floor bids, 2=live, 3=absentee bid executed, 4=ios, 5=android, 6=automated bids to clear reserve price
|
|
|
|
|
- Competing/floor bids are entered by the clerk and are supposed to represent anyone bidding live outside of our system (at the auction house, over the phone, on another internet platform, etc), and those will always have a bidder_id of 0.
|
|
|
|
|
|
|
|
|
|
Sub catalogs; they don't exist in the system formally, they're just lots grouped by listing_agent_id
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct2_np_bid_history
|
|
|
|
|
|
|
|
|
|
absforcebidderid set to 20; 20 would be the SFS (smart fox server) internal userId for the live bidder that placed a bid, thus forcing the existing absentee bid (which preempts the live bid) to be sent to the clerk.
|
|
|
|
|
All you really need to know is that there was a live bid that forced the absentee bid to be placed.
|
|
|
|
|
Only one bid is sent
|
|
|
|
|
|
|
|
|
|
sourceid 1= floor, 2=internet, 3=absentee, 4=iPhone, 5=Android
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct2_npb
|
|
|
|
|
|
|
|
|
|
npb_type 1 = active dispute, 0 = resolved dispute
|
|
|
|
|
|
|
|
|
|
auctioneers_users
|
|
|
|
|
role known possible values: admin, auctioneer, bidder
|
|
|
|
|
admin_group possible values: exec, support, development, admin_group, <NULL>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct2_approval
|
|
|
|
|
|
|
|
|
|
\`SELECT distinct approval_approved FROM liveauct_liveauctioneers.auctioneers_auct2_approval;\`
|
|
|
|
|
|
|
|
|
|
approval_approved = 0 - not reviewed, 1 - approved, 2 - declined, 4 - blocked by auctioneer, 5 - suspended
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct_bids
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct_houses
|
|
|
|
|
|
|
|
|
|
## auctioneers_auct2_lots_sold
|
|
|
|
|
|
|
|
|
|
has ~29 million lots, we only index 21 million since some houses do high volume listings and we ignore any
|
|
|
|
|
|
|
|
|
|
plaintext passwords for many of our clients just hanging out in here
|
|
|
|
|
usernames and passwords are generally the same
|
|
|
|
|
|
|
|
|
|
FAQ
|
|
|
|
|
—————————————————————————————————————————
|
|
|
|
|
Q. Can someone tell me where we are keeping the stats that we are reporting on for auction houses? I think they have stats like number of views of their items and such.
|
|
|
|
|
|
|
|
|
|
A. They are stored in the statistics database, which is a separate machine from our main database; however, they are aggregated and stored in auctioneers_auct_catalogs_admin_data and auctioneers_auct2_lots_admin_data for catalog and lot-specific data respectively.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Q. What’s with all the ncatalog stuff?
|
|
|
|
|
|
|
|
|
|
A. In the mainhost codebase the letter "n" is often used to mean new (unfortunately) to distinguish from similarly named things from the eBay era.
|
|
|
|
|
|
|
|
|
|
ncatalog_status is the status of the catalog once it is proofed. It is null until the catalog is proofed (i.e. published/made public on our site), at which point it is "online". "Live" indicates that the auction is taking place right now (or soon), and "done" means done.
|
|
|
|
|
|
|
|
|
|
ncatalog_type is not as important as it used to be. We used to have tiered service levels that had access to different features. For ncatalog_type 1 and 11 were "Gold," 2 and 12 were "Platinum," 3 and 13 were "Platinum Plus," but now 1 will typically be timed sales and 3/13 will be traditional. 10 is white label _only_ which means that the auction is not displayed on our site, except by direct URL. 10 + the level (1,2,3) means the catalog can be accessed as white label _and_ is displayed as a normal catalog on our site. ncatalog_type = 10 is really the only important functionality of that variable now, but there are still some gotchas lingering.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`,
|
|
|
|
|
tags: ["not ass"]
|
|
|
|
|
})
|
|
|
|
|
]
|
|
|
|
|
|
Adam Veldhousen
4 years ago