Difference between revisions of "User:Ryan52/todo"
Jump to navigation
Jump to search
(→queue: organize) |
(move stuff) |
||
| Line 18: | Line 18: | ||
the next release | the next release | ||
| − | |||
| − | |||
| − | |||
| − | |||
* [[FGRT: 16932 | #16932]] Adjustments in gizmo counts | * [[FGRT: 16932 | #16932]] Adjustments in gizmo counts | ||
* [[FGRT: 17660 | #17660]] fix up the points trading interface | * [[FGRT: 17660 | #17660]] fix up the points trading interface | ||
| Line 50: | Line 46: | ||
the unimportantish release | the unimportantish release | ||
| + | * db cleanups | ||
| + | ** gizmo_types.effective_on has a silly default | ||
| + | ** workers.contact_id needs to be unique | ||
| + | ** users.contact_id needs to be unique | ||
* [[FGRT: 14985| #14985]] privilege to role mapping for database users | * [[FGRT: 14985| #14985]] privilege to role mapping for database users | ||
** [[User:Ryan52/roles]] | ** [[User:Ryan52/roles]] | ||
Revision as of 13:59, 27 March 2010
not fgdb
- User:Ryan52/maintenance
- ASS
- hard drive tester
- keyboard tester
- #15784 Newfangled keyboard tester addition request/issues
- #16161 additional function keys (F13 - F16) as well as the volume/eject keys to (volume up/down/mute keys)
- #16162 Macs: the equal (=) sign on the number pad never shows up as working
- #16163 larger title for the keyboard type
- #16164 screenshots of each layout and the settings screen
queue
the next release
- #16932 Adjustments in gizmo counts
- #17660 fix up the points trading interface
- #16835 make an interface for editing a worker's worker_type
queue + 1
the old shit release
- #16656 make the store people happy with returns
- OLD TODO: when editing a return it should link to the sale/disbursement and show a bit of info about that transaction
- #15738 mutate the returns too in data-mutate
- #14857 make the receipts that have store credit make it very obvious
- #16659 don't make the return associated with the sale
- #16660 change the fields for gizmo returns
- #15885 fix up coveredness tracking
queue + 2
the library release
queue + 3
the unimportantish release
- db cleanups
- gizmo_types.effective_on has a silly default
- workers.contact_id needs to be unique
- users.contact_id needs to be unique
- #14985 privilege to role mapping for database users
- User:Ryan52/roles
- ack "(requires_(role|staff)|is_staff|has_role)" app/
- #16933 privileges for tech support role
- #15050 people with TECH_SUPPORT role should imply the CONTACT_MANAGER
- #17210 store or at least store admin should imply contact manager
- should happen after library branch for sidebar stuff
- link to old system IDs on the systems page as well
- #17231 "current" system ids
- cashier code enhancements
- get fgdb.rb able to be set up by new freegeeks and new coders
queue + 4
the cool toy release
queue + 5
what's left release
- changes to the contact widget
- fix up form_has_not_been_edited
- #16108 gizmo_types with same name and different effective date ranges should act sanely in reports
junk
- go through remaining trac tickets:
- old TODO list
- my crazy ideas that will just make fgdb.rb that much more awesome
- #16514 create a plugin that will improve partial updates (by freezing attributes)
- #16513 create a plugin which will make records associated by has_many (optionally?) saved when the parent record is saved
- looks like it's already in rails itself... :autosave
- need to test though. and why did none of the sites that I found in the process of figuring this out show it?
- looks like it's already in rails itself... :autosave
- release utilities
- test if the auto-update script works
- test if test-migrate will work with other branches
- the auto-update script is connected to my home dir (because of the devel checkout), but it shouldn't be.
- use multiple working copies from the production checkout: http://kerneltrap.org/mailarchive/git/2007/10/11/335637
- or just create a dbadmin user on arik
- benefit of possibility of having a key connected to devo.
- update Committing to FGdb after that.
- I want all changes on a release_X.X.X branch (after the initial branch) to get their own tag. this would involve running ./script/mini-release (new script?) when making a direct change, and this would affect the output of ./script/version. mini-release would also close the ticket(s) (by pushing the tag, I guess). also, this would mean that pushes on release_X.X.X branches wouldn't close the tickets. this would also affect the changelog workflow probably.
- I wonder, could we have root mail go to an RT queue.