FGdb brainstorm

Just because something is on this list doesn't mean it will get fixed, is broken, or even pertains to the FGdb application. But this is the place to put suggestions and beug reports for FGdb. We will organize what we find here and try to match up bugs and feature requests with existing tickets and use this as a factor in setting priorities.

Lantz and Martin added numbers which they think are priorities, 1-5 going from least to most important.

Basic list

After interviewing staff and core volunteers on January 17, 2008.

there aren't enough categories for what people bring in (e.g. All in one printers)
the categories don't match the tally form
Can't search for receipts by payment type (e.g. invoice) -- you get an error
4 it's too slow
- transactions: dynamic interface generation
- reports
- hours entry: the process can be streamlined
- receipt popup is slow
when in a receipt (or hours?) can't find people's info (you have to go to contacts to find it)
4 statistics for gizmo statuses report -- you can't specify a whole year. you need to limit it to a few months or less or it times out
1 volunteer scheduling should be online, not on paper. this would eliminate double booking, etc.
4 need easier report generation of things like gizmos given out, gizmos received, hours worked
5 some receipts from the store seemed to disappear last week. i couldn't find the numbers even though i'm sure i didn't delete them
4 we need support for logging in who you are when you work as a cashier and support for which till you're using (authentication and tracking of users)
1 when making a receipt, we should be able to add items that are services and don't therefore have an estimated value. these should be grouped together on the receipt/invoice. for example a fee for picking up donations that might be on a receipt or invoice can't have an estimated tax deductible value associated with it
2 other startups can't use the sales receipts, since there's no sales tax module
3 there's no debian package -- it's hard to install for startups
3 gizmo reports should break out disbursements between granted out and adopted out
4 not every terminal should have access to the database and contact information. users should have to sign in (like we used to have to) for certain parts of the database
5 when there are too many items in a sale, it stops displaying the correct total amount and you have to manually calculate the correct amount in order to finish the transaction
3 stuff that gets sold should be organized by where in the building / which department did the work to get it to us, so we can measure how profitable each department is and where our time is well spent. macs, printers, receiving, laptops, build, monitors, basic testing, advanced testing, etc.
5 tabbing between fields does not go smoothly when creating donation receipts. sometimes you end up on the wrong field and have to reach for the rodent to get where you want. other times it works fine.
4 sometimes the cursor isn't blinking and you don't know where you are and have to click on everything
build tasks can't apply towards adoption -- when did that change?
5 how do you find out if a volunteer adopted a computer and when that happened?
3 front desk should be able to merge contact info between duplicates
3 there should be a UI for searching for likely duplicate contacts
4 create a disbursement (i.e. a grant with some miscellaneous items that have been described). you can't see what was disbursed without editing the record to see the descriptions.
3 in the disbursements list, when you click on edit it asks if you want to cancel the current disbursement, but i wasn't entering a disbursement in the first place (same for receipts in store or for donations)
5 in the disbursements list, when you click on edit it asks if you want to cancel the current disbursement. it says "Do you want to Cancel?" and your options are "OK" or "Cancel". They should be "Yes" or "No".
4 when a volunteer signs up for build or adoption, it should automatically check the volunteer box so you can find them when you're looking for volunteers.
4 thing move around unexpectedly, making it hard to enter data
there should be a search screen separate from the data entry screen, maybe a tab for each
2 can't access it from the command line (what do they need? can we add it to the main interface instead?)
4 entering items in a donation need a block of items created so it flows more smoothly.
3 maybe checkboxes for common items donated
we have outgrown this database (?)
4 does not update suggested donation until you set payment type
5 defaults to dumped. should not do that
4 round up suggested donations to the nearest (or higher) $5 increment
3 staff hours are not reported the same way as everything else
you can't get good reports
1 searching through web forms is inadequate (move to brain implants?)
you have to search for someone before adding them even if you know they've never been added
- 3 search could happen "behind the scenes" during contact creation and only pop up if a likely duplicate was found
3 Back end database is confusingly set up for retrieving arbitrary data needed. It doesn't map well to how Free Geek operates and seems as if the design of the code forced it to be organized in a way that is less useful than Free Geek needs.
- this is especially true around receipts (looking for money associated with types of gizmos for a date range for example is not as easy as it was in the old db)
4 multiple criteria for searches: search by (date range AND type of payment), not just (date range OR type of payment), etc.
5 Error message on save a contact with a blank contact method (hard to reproduce)
4 update contact info box after editing them
This problem is best explained by a story:
Front Desk worker: "Have you been here before Ms. Jane Smith?"

Jane Smith: "Yes"

Front Desk worker: (looks in database) "Are you still living on NE Tillamook?"

Jane Smith: "No, I've moved to SW Curry"

Front Desk worker: (clicks 'edit' and revises address and clicks 'update'... various error messages and editing contact info dialogue still up... but if you click 'cancel' and search for the person by name again, it will come up with updated info) = TOO MANY STEPS, why an error message?
4 look at sales receipts and select a date range or some other criteria, leave your browser open for a week or two and then come back. the old criteria is still selected, rather than the default of today's date
4 search for a transaction by contact name.
- pick a name that will give you >1 result.
- select the first result and click on refine
- 3 there is now a drop down control with that name alone in it. if you wish to go back and select the second name, you need to re-enter the search criteria.
- the drop down should either not be there, or it should have the full list it had before you hit refine, and refine on the fly
4 a way to use the database to create ALL invoices, this would include invoices for recycling

More stuff

Some of these are duplicates of those above:

BUGS in the database

4 Rails error when searching for a tally of gizmos from a range greater than 3 months
When using the tab button in recording donations the next gizmo box is slow to appear. if entering an anonymous donation it does not tab from the zip code area.
When updating a contact in “donations” an error message appears “Couldn't find ContactMethod with ID=57138” and yet it does update the contact when you click cancel. The update will not show on the screen, it will print out on the new receipt.
5 When entering a new volunteer you have to click “volunteer” and “adoptor/build” if you do not they don't show up when entering in hours.

WOULD LIKE TO SEE AVAILABLE

4 I'd like to be able to see all the volunteers I signed up on a particular day. (is who signed them up important to the report?)
- I first looked for this when a volunteer hurt herself and we had just signed her up, but could not find her name.
A greater search range in the gizmos report.
I'd like to be able to look up how many gizmos came in during a certain time frame so that I could make volunteer reward posters.
5 A way to see if a company has outstanding invoices before accepting a donation from them.
The default donor is a “dumped”, it would make more sense to have the default as “named” or I'd like to be able to select a check box with the tab key to pick one of the 3 options.
1 penguins, real live ones.
The whole building could be hooked up to the intercom system so people don't have to run around and find others in the warehouse when super busy.
4 Could the “create” and “”cancel” buttons in donations be farther apart. I have been known to click the wrong one and have to start all over again,

whew!

shawn's request

It would be very, very, incredibly useful if the database could more easily produce monthly and (most importantly) yearly for the following:

- # systems, monitors, printers granted
- # systems, monitors, printers adopted
- # systems, monitors, printers sold
- # systems, monitors, printers recycled
- % of systems, monitors, and printers granted, adopted, sold, and recycled
* extra swanky: these numbers (or at least the non-recycle numbers) for laptops, macs

- # new volunteers in build, adoption, other
- # volunteers who logged hours in build, adoption, other
- # hours logged in build, adoption,

- # donations
- # unique donors
- avg. amount of money given per donation

- # sales
- # unique store customers
- avg. amount spent per store transaction

- recycling tonnage: monitors, steel, circuit boards, total (including categories not mentioned) (this might have to come out of bookkeeping??)

what to prioritize

Three general categories jump out as high priorities:

bugs that prevent work from being done (e.g. sales receipts with large numbers of items not displaying correct totals)
user interface issues where most users believe the software should behave differently (e.g. "cancel current transaction? with an OK and Cancel option)
features that would allow auditability (e.g. logging in to handle money, tracking and reporting which till, logging edits and deletes for receipts)

Lower priorities:

other new features (not included above)
back end issues
user interface "bugs" that users don't agree on