chmarr / artshow-jockey

Artshow Jockey

Artshow Jockey

Hello! Artshow Jockey is a application to assist in the management of a convention-style art show.

If your show has the following basic arrangement, then you'll find that Artshow Jockey does exactly, or possibly more, than what you need:

• A number of artists bring their works to a show for display and sale.
• A number of bidders that register to place bids, obtaining a "Bidder Number" to do so.
• Bidding is first in a "silent auction" process, where bidders mark on a bid sheet associated with each piece of art.
• Bidding may progress to a traditional voice auction if some condition is met.
• Bidders then pay and collect any pieces where they are the highest bidder, and possibly other unsold pieces.
• The artists receive the winnings, minus any commission that the show chooses to charge.

Artshow Jockey contains a number of other features to make management of larger shows easier:

• Pre-show reservation of different types of display spaces: panels, tables, and others can be added.
• Bid sheets can be pre-printed with information from the piece database.
• Bid information can be entered into the system through several means, including barcode scanning.
• Printed reports for various information, including a "winning bidders report", all in PDF format.
• Support for both "staff collects" and "user collects" processes.
• A cashier application to collect payment, and print invoices and pick-lists.
• Automatic cheque printing and account management for payment to artists.
• E-mail can be sent to artists "en-masse" through a template system, and include information about their contact information, pieces in the show, winning bids and bidder details, and full accounting information.

Artshow Jockey is written in Python using the Django application framework. It can be installed as a standalone application, or integrated into a larger Django project. Most screens use the Django "Admin" application, with a few customised screens. Customised screens are currently "ugly" but functional, just like this page.

Artshow Jockey is currently in development, and has been used and refined at Further Confusion every year since 2009. Other conventions are highly encouraged to use it too. A polished "1.0" release is expected in March 2012. You are invited to download an try the project now; any recommendations and requests will be happily considered. Use github to download the "master" development branch, or to download a zip file or tarball. Stable releases will be given distinct branch names.

Visit the Wiki to get documentation, or go straight to the Quickstart page.

Artshow Jockey is currently actively developed by Chris Cogdon [email protected].

Development assistance, especially for HTML/CSS/Javascript, is eagerly welcome.

artshow-jockey's Issues

Show warnings on admin screens if site not set up properly.

In particular, show errors if the initial fixtures are not added.

Ideally this would show up in a "workflow" page, in the "initial-set up" section.

Create printable "Pieces Going to Auction" report

Either use CSS to hide navigation of the HTML version, or create a PDF version similar to the winning bidder report.

Make "pending fees" part of visible accounting

We've had several artists overlook payment because the fee didn't come up in the accounting.

Plan A: Whenever accounting is shown, include "pending" fees either as a line item, or a special item with a special balance line, so that it's clear that something needs to be made

Plan B: Requesting a space automatically creates or updates a line item for those spaces. Perhaps a special category so that the software knows which item can be automatically adjusted, and which one it is not allowed to touch

Create "generic" bid sheets and control forms

Create generic versions of these forms and include those in the "artshow" application. Construct in such a way that if a show can create their own forms with the spaces in the same locations, the "pdf printing" module wont need to be updated.

Also include "piece identification", "file folder", "file folder with extra info" and "mailing label" PDFs, since these are already very generic.

Improve cheque printing.

Currently check printing is simply the plain-text output run through an internal text-to-pdf converter. Change this to direct-to-pdf and make a concerted effort to get the alignment to standard cheques, and the address window, perfect.

If possible, find out why printing pdfs from some browsers messes with the alignment.

Use Django comment framework for all "notes".

Use the django comment framework to attach comments to Artist, Piece, Bidder, Bid, Invoice objects.

Update project for Django 1.9

Project does not function under Django 1.9. Update the project so it does, including replacing any features that are on the deprecation track.

Use proper model field validators in Piece model

remove some of the validators from Piece.clean and use the validators attribute

Improve help for piece entry.

Some artists were including their artist ID into the piece ID, creating IDs such as "601". We need to improve this. Possibilities:

• Pre-fill piece IDs.
• Display a help screen the first time the piece screen is entered into, with a graphical version of the forms with callouts. This screen can be re-visited with a "help" link.
• Show the artist id next to the piece ID field, such as 6 - [ ], so it's clear the artist ID is already included.

Add descriptions to spaces

Add a description field to spaces. Eg: "General Panel" could have a description of "4ft by 4ft pegboard panel in general audience area. Half panels available".

Show these descriptions on the Space Reservation/Edit screen

Add "generated invoices" to cashier app when viewing a bidder

When viewing a bidder, add the ability to view previous invoices.

Consider restricting printing to printing just the customer copy ?

File-folder printing

Include option to print per-artist file-folder stickers. Several options:

• To specific file-folder labels, with information including artist ID, Display Name and Real Name. 3.43" x 0.6"
• To large address labels, with Artist ID, Display Name, Real Name, Allocated Spaces, A space to record actual spaces used and a checkbox for "changes recorded". Support both 2.625x1 and 4x2 labels. (note that 4" wide is too wide for manila folders, so might not be useable.
• To plain paper, with printed boxes, that can be cut out and inserted into folder tabs. Have insert double-height so it can be folded over or slightly bent, just like the dedicated blanks that come with those tabs. ID and Display Name only here.
• Other options.. would be nice to be able to specify custom label dimensions and have it "figure something useful out.

Convert various settings to database-based switches

Change the following settings over to something that can be modified through the admin screens (or something).

• SHOW_ALLOCATED_SPACES
• Various PayPal settings.

Create by-bid/by-invoice distinction in email template.

The current "all inclusive" template shows sales statistics purely by the top bid. This is appropriate for when the show is in progress, but it is inaccurate all the sales; it is possible for a piece to be sold to the person that does not have the top bid, such as when errors are being corrected for, etc.

Modify the all inclusive template to have two versions. By-top-bid without bidder names, and by-invoice with bidder names.

Wrap up the "peeps" "artshow_shims" and "tinyreg" apps into "artshow"

Yes, it is nice to split these out to show just how flexible the artshow app can be, but this makes it difficult to distribute this component on PyPI, since that generally expects single downloadable components.

It would be "nearly as good" to simply show a working example of a replacement

"Person", "ArtistAccess" and "agents" reorganisation.

Currently: No relation between admin.User and Person. All "non Staff" access to Artist is done through ArtistAccess which maps a User to an Artist with a "can_edit" attribute. The User corresponding to the Artist has to have such an entry to make edits, which seems redundant.

Proposal:

"Person" is handled one of the following ways

1. One to One relationship between User and Person
2. Support Person being a subclass of User
3. Django 1.5 User replacement that provides all of the artshows requirements (address, email, phone, reg-id)

Whatever method is chosen, the artshow points to either the model directly, or a proxy, that will provide the necessary interface. We'll call this Person for the rest of the proposal here.

Every artist points to a Person (many to one relationship), Since a Person has a one-to-one relationship with a User (possibly being the same object), this User always has full permission on the Artist details.

"ArtistAccess" becomes additional Person(s) that have full or restricted rights to that artist. This could be rolled into "Agents", since the concepts are highly similar.

Considerations for possible rights:

• Change artist details (except email address, which is part of the authentication system)
• Change disbursement details
• Add agents, or rights to existing agents (cannot grant more rights than currently have)
• Remove agents, or rights to existing agents
• Change space reservations
• Change pieces in show
• Can hang artwork in show
• Can remove uncollected artwork
• Can make executive decisions about artwork during the show.
• Can make payments into your account. (Who would ever refuse this?)

Have "bidder registration" enabled or disabled with a switch

For "Allocate Spaces" admin function, prompt for max number of each space

give the "allocate spaces" admin function the ability to specify, for each space, the maximum number of spaces to allocate, and also the option to "distribute fairly" if there are insufficient spaces.

Paypal Payment Reconciliation.

1. Make "Payment ID" visible in the payment listing.
2. "Artist" is clickable, and goes through to the artist.
3. Make a screen where the payment ID (including possible hash) can be entered, the payment appears and is confirmed. Clicking "confirm" switches payment to "Payment Received" and the amount adjusted if necessary.

Make "reservation units" programmable

Add a field to Spaces to say in what units that space can be reserved. Eg: "1", "0.5", etc.

• Is integers the best, here? "1" "0.5" "0.25"... can get awkward. Supporting thirds is awkward

Have the popup from the "edit" button on "ajax-select" close the window

Fix invoice number generation

The hack change was to create a "empty invoice" once the payer was selected, so that the invoice number can be displayed while credit cards are being processed. If the invoice is cancelled, this will leave the blank invoice in the system.

Change this so that sequential invoice numbers can be assigned without creating Invoice objects.

Provide easy way to give extra panels at show-time.

At show-time it is common to give artists additional panels to "spread out". Since this is the staff's decision the artist should not be charged for the panels.

However, this either not accounting for the panels in the "allocation", and remembering this fact if allocations are being reconciled against the artist-to-panel report, or allocating the panel and remembering to not charge for them when doing the "apply space fees", or creating a new category of space that has no cost, and then moving the panels from one category to another. MESSY!

Suggested solution: add additional attribute to a SpaceAllocation that indicates how many gratis spaces are being allocated. TBD: does the value add to the allocation, or is part of the allocation.

Bonus: This will nicely cover "GOH complimentary panels", removing the need to have a separate class for this, and possibly removing the need to have a "secret, un-reservable" category.

Extra: Possibly add another category for a space that is no longer allocated, but still being charged for. This will simplify "unused space penalty".

Allow non-artist registrations

Currently, registration process assumes only artists register, and thus always ask for full personal details. These are not necessary for agents.

Change as follows:

• Registration on the website asks for Name and e-mail address. This creates the "User" and "Person" objects, but with a unusable password
• emails confirmation, including the ability to set a password.
• On login, an option to register as an artist is displayed. Clicking this goes through the process of completing the personal details, selecting an artist name and agreeing to the art show rules, selecting panels and then making a payment. At the end (or if the process is stopped), a sample page with arrows indicating all the points.
• The "Top level" page contains links to edit personal details, register as an artist (if not done already), register an additional artist name, as well as a list of the artists currently linked, or linked as agents.

It may be desirable if the "register additional artist name" should be enabled per-artist, and initially showing a "If you wish to register an alternate artist name, please contact the art show manager."

Under the "Agenting For" section, say "If you intend to act as an agent for an artist, please have them add your login name to the "Agents" section of their artist page.

Under "register an artist", there should be "I am creating this account on behalf of the artist", which will prompt to create additional User and Person details. Workflow to be determined.

Create specifically designed pick-list page.

Instead of using an invoice simply marked as "pick list"

Designed to make it easy to pick pieces, and check off details

Use either text or PDF (perhaps create both?)

Artist ID customisation

Have "Artist ID" be a standard string field, which is "unique if not null". The PK is a simple integer again.

Part of the "local customisation" is how these visible IDs are created:

1. Always manually
2. Copied from PK
3. Customisation module.

Specific example: Anthrocon uses XXX-NN where XXX is the first three letters of the artist name.

Prompt for which artists to print for.

When printing bidsheets or control forms from the workflow page, display a list of all the artists for which printing is available with checkboxes, all-preselected, and allow the user to de-select before the actual printing.

This will improve the workflow when printing and data-entry is occurring simultaneously at show-time.

On-Line Winning Bidders

Create page that allows bidders to see what they've won.

Accessible by entering con registration number, and a PIN.

PIN is entered at time of registration.

Requires a reliable method of pushing the database to the public site soon after bids are tallied, and soon after the results from the auction comes back.

Simplify the "payment for spaces" logic

The logic as stands is a little weird. Instead, when spaces are adjusted, a new accounting item is created or adjusted to reflect adjustments. Use a distinct accounting type for automatic adjustments. The existing "space fee" is never adjusted, but is taken into account for the automatic adjustments.

The intent is to have the top-level accounting show as a negative amount until paid.

Calculate commission based on invoice price, not top-bid price.

Doing things by invoice price appears safer, but we'll need to determine what the correct process is if the invoice and top-bid prices disagree. At the very least we should not base commission on the top-bid price if the invoice price is higher. I.e., choose either "invoice" or "max(top-bid, invoice)"

Display option to mark piece as "printed"

When printing control forms or bid sheets from the admin screens, show an intermediate screen allowing the administrator to set the pieces as "printed" and "not in show, locked" if they're not already locked.

This will allow the bidsheet and control-form printing workflow to be made through the admin screens with the same functionality.

Workaround for re-delete of a form in a form set

Referencing django trac ticket: https://code.djangoproject.com/ticket/19408

Let's see if we can get a workaround in place, or actually fix the bug.

Report top-bid/invoice-item discrepancies

Every piece has a top_bid (bidder, and price) but also a invoice item (bidder, price), but there's no enforcement that the two are the same. While this is somewhat intentional, any discrepancies should be easily reported.

Reports to artists currently always use top_bid. While the policy may be to pay the artist the top_bid, even if the item was eventually sold to a different person at a lower price, the report on who actually has the piece should be the one included in the report.

Modify report code to use invoiceitem in preference to topbid, but if only topbid is available, use that but put an asterisk marking that this is preliminary.

Show policy can decide if the artist is compensated in the case of a descrepancy (where the item is sold for less than the topbid indicates)

Note that "apply winnings and commission" will need to use one or the other. The function should flag a warning if not all pieces are invoiced yet, and determine if the top_bids should be used instead.

Also, change "apply winnings and commission" so that if re-run, another entry will be created only with the differences, which may be negative, and are marked as "differences" so that we don't need to play games with the "number of pieces" thing.

Create "locked" status on pieces that prevents artist editing

Create a new status, for the moment called "Locked", that behaves like "Not in Show" but additionally prevents the artist from making further edits to that pieces.

The intention is that once a bid sheet is printed, a piece moves to the locked state, forcing the artist to create a new Piece (and thus a new piece id) if further edits are to be made.

Print queue settings and printing management.

Add a model to define various print queues, including a specific printer and print settings such as paper type, duplexing, print tray, etc. If this can be easily provided by the server's print queue system (CUPS) and the application can query cups for the pertinent information, then just use that.

Need to ensure the system or our application has a method to manage print jobs with different requirements (typically different paper types) going to the same printer can be managed. I.e., if a paper type swap is required, the relevant jobs are held. Some printers have the ability to manage this themselves, while others require the queue to do this.

Then, for every type of print (bid sheet, control form, invoice, pick-list, various reports, stickers, etc), specify the default queue to use for that type. On each print, the user is requested to supply the queue to use (with the appropriate default). For both the default setting and the on-printing setting, "PDF to browser" is always an option.

artshow_settings context_processor doesnt work.

References to, for example {{ artshow_settings.ARTSHOW_SHOW_NAME }} come up as blank.

Support "sale after show"

Support "after show sales" in the software (a la Anthrocon)

Requires:

• Add "after show price" to each piece
• Cashier app needs ability to add pieces on the fly (Search by artist, title, barcode)
• In the case that bidders cannot peruse the show after close (a la FC) need ability to quickly make such pieces marked unavailable when the artist removes their work from the show.

Additional features

• Generate a report of what pieces are still available for sale.
• Generate a webpage that bidders can peruse
• Allow artists to upload thumbnails to the software to use in the above webpage, or a direct link to their gallery page and the software auto thumbnails.
• Buy pieces online? (needs high synching between at-show and in-public databases)

Design and pre-create access classes.

Determine what kinds of access roles are required and pre-create these as fixtures. It may be that "artshow staff" is all that's required at this time.

Create function that will print all forms for pieces that have not already been printed.

Example: One or more artists enter new pieces at the show. Useful to be able to print all the necessary paperwork for any unprinted pieces.

Make form printing code easier to replace

The code to print bid sheets and control forms is FurCon specific. This can easily be edited in-situ, of course, but better to allow administrator to drop in python code meeting the specification into another app, and have a setting pointing to it.

Support for bidder-collects sales process.

Support for Anthrocon's sale's process.

Constraints:

• bidder IDs hand-written onto bid sheets. (future might add printed stickers, or barcode stickers)
• no "after close" data collection. All "bid data" is collected during the sales process
• pieces (with bids, and those sold with 'after show' option) are collected by bidders and brought to sales desk.
• bidder IDs are non-numeric. (Already supported)
• artist IDs are non-numeric. (Covered in other issue - I think)

Ideas:

• Barcodes on bid-sheets can still be of use, but there's still significant hand data-entry for each piece that might make barcodes more trouble than its worth
• At sales time, bidder ID is entered, ID confirmed, then per sheet: Piece ID entered, bidder ID confirmed (if not a 'after show'), price entered, type of bid (standard, after-sale, voice auction) entered. Then normal cashier process.
• Possibly add support for recording number of bids, for analytics purposes.
• Add support for quick "no sale" reporting of a stack of bid sheets, either during artist check-out, or post show.
• Add support for quick "uncollected" data entry, either before or after pieces are grouped by bidder.

This is similar to the standard "support after show sales" idea, except that we'll want to enter the bid type at sales time.