User:Ryan52/todo
< User:Ryan52
Jump to navigation
Jump to search
Revision as of 17:42, 14 November 2009 by Ryan52 (talk | contribs) (→What's left for staff hours: no more TODOs for staff hours, really..)
Tickets
- #15753 install security update
- #15784 Newfangled keyboard tester addition request/issues
- get fgdb.rb able to be set up by new freegeeks and new coders
- #15885 fix up coveredness tracking
- fix up form_has_not_been_edited
- #15702 drive testing broken on lenny
- #15924 find new generics
- Staff_hours_tracking_application
- see below for individual TODOs
Timeline
Releases
- 11-14-09 release:
- changes already in master (destroy link, unimportant stuff)
- coveredness improvements, #15885
- shouldn't wait until next release, this will break stuff
- 11-21-09 release: staff hours rollout/testing?
- has to be, FG is closed on the 28th, and it's needed before December...
- pretty much ready now
TODOs
- on Saturday the 14th:
- #15885, coveredness improvements (if not done already)
- minor improvements to staff hours
- on Saturday the 21st (won't all happen on this day):
- #15784, keyboard tester
- #15523/#14227, install instructions/testing
- form_has_not_been_edited improvements, see Tickets section
- drive tester on lenny
- go through remaining trac tickets:
- http://dev.freegeek.org/projects/fgdb.rb/report/1
- http://dev.freegeek.org/projects/skedjulnator/report/1
- they can probably be forgotten or moved to my old wiki page (aka the graveyard of todos)
- find new fgss generics, #15924
What's left for staff hours
nothing really is left that has to be done before release, afaik...
- make strings on interface make more sense
- should make some metadata (the income_streams, wc_categories, and programs) effective/ineffective (FGRT: 15817)
- this should be able to wait, since we aren't using this info in the frontend at all...
- why do we need to make the jobs <-> (income_streams, wc_categories, and programs) many-to-many? for effective dates or for percentages?
- we will need effective/ineffective logic on all of these (actually we might or might not use it on income streams). we might want to do the percentages thing, but i have a feeling it would be difficult to maintain and therefore not get used, so I want to put off implementing that until we've got the basic system online and in use. but either way, we need the many-to-many stuff.
- need foreign keys
- make an interface for editing a worker's worker_type
- you can set it on create, but not on edit
- if you edit it manually, run ./script/validate_workers afterwards to check your work