User:Ryan52/todo
< User:Ryan52
Jump to navigation
Jump to search
Revision as of 15:02, 14 November 2009 by Ryan52 (talk | contribs) (→What's left for staff hours: don't need that.)
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
- make strings on interface make more sense
- should make some metadata (the income_streams, wc_categories, and programs) effective/ineffective
- 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.
- should make workers to worker_types effective/ineffective
- if a worker changes types halfway through a pay period, does the first half of their hours need to go into one category and the second half go into the other? (on the payroll report). or can we get away with just using what their type was at the beginning or end of the pay period?
- it's safe to assume we won't change worker statuses between pay periods. (even if we needed to, we could do two partial pay periods for a worker and manually add the numbers together when reporting.)
- 16:20 < RiFraS> go by the end date
- 16:20 < RiFraS> mention that the worker type has changed so we can manually catch errors, I suppose
- ummm no I'll just make it calculate the worker type totals correctly. it might take a performance hit, but eh.
- it's safe to assume we won't change worker statuses between pay periods. (even if we needed to, we could do two partial pay periods for a worker and manually add the numbers together when reporting.)
- edited through interface, hm. I guess this should be line item? eww. need an interface for editing effective/ineffective things when it's originally a one-to-many.
- also need a validation. like this:
- if a worker changes types halfway through a pay period, does the first half of their hours need to go into one category and the second half go into the other? (on the payroll report). or can we get away with just using what their type was at the beginning or end of the pay period?
worker.workers_worker_types.sort_by(&:effective_on).each_with_siblings{|a,b,c| raise if (a && (a.ineffective_on.nil? or a.ineffective_on > b.effective_on)) || (c && (c.effective_on.nil? or c.effective_on < b.ineffective_on))} def Enumerable.each_with_siblings self.each_with_index{|b, i| a = self[i - 1] if i > 0 # -1 does not mean what we want it to c = self[i + 1] yield(a, b, c) } end
- find a way to determine current worker type.
- in Worker:
- find a way to determine current worker type.
def worker_type_on_day(date) self.workers_worker_types.effective_on(date).first end def worker_type_today self.worker_type_on_day(Date.today) end
- in WorkerWorkerType:
steal named scope from VolunteerTaskType