Difference between revisions of "User:Ryan52/todo"
Jump to navigation
Jump to search
(→queue: done) |
(bam bam bam) |
||
Line 24: | Line 24: | ||
the old shit release - April 23rd? | the old shit release - April 23rd? | ||
+ | * TODOs in the code, '''./script/ack-the-diff''' | ||
* [[FGRT: 17932 | #17932]] tricky to log 0 hours when the schedule expects hours | * [[FGRT: 17932 | #17932]] tricky to log 0 hours when the schedule expects hours | ||
* [[FGRT: 16656 | #16656]] make the store people happy with returns | * [[FGRT: 16656 | #16656]] make the store people happy with returns | ||
− | |||
* [[FGRT: 15885 | #15885]] fix up coveredness tracking | * [[FGRT: 15885 | #15885]] fix up coveredness tracking | ||
− | ** add covered and contract_id to spec_sheets, and put it there as well as on systems | + | ** MAYBE add covered and contract_id to spec_sheets, and put it there as well as on systems |
− | ** the sales/transactions/etc screens should preseed the covered value from the system id | + | ** trying to accomplish: |
− | ** [[FGRT: 15884| #15884]] make them choose covered or uncovered | + | *** the sales/transactions/etc screens should preseed the covered value from the system id |
− | ** [[FGRT: 15883| #15883]] figure out if the sales screen should have a covered widget too | + | *** [[FGRT: 15884| #15884]] make them choose covered or uncovered |
− | ** [[FGRT: 15846| #15846]] Make FG-PDX automatically uncovered | + | *** [[FGRT: 15883| #15883]] figure out if the sales screen should have a covered widget too |
+ | *** [[FGRT: 15846| #15846]] Make FG-PDX automatically uncovered | ||
+ | ** plan: | ||
+ | *** change the checkbox to a dropdown | ||
+ | *** code after entering a system that (synchronously, not async) connects to get the systems covered value if it exists, presets it in the widget, and disables the widget | ||
+ | *** add to the systems contract fixing page to fix the covered value too | ||
+ | *** show the covered widget everywhere (adding sales) | ||
== queue + 1 == | == queue + 1 == | ||
Line 47: | Line 53: | ||
the unimportantish release - May 21st? | the unimportantish release - May 21st? | ||
+ | * [[FGRT: 14861 | #14861]] swap computers (tech support) | ||
* '''I WANT A TEST SUITE''' | * '''I WANT A TEST SUITE''' | ||
* db cleanups | * db cleanups |
Revision as of 17:08, 17 April 2010
how I want to handle things
- handle all small tasks as they come in.
- aim for release every two weeks, with the queues outlined below
- try to stay on track with the expected release dates and catch up if get behind
- eliminate ASS/fgdiag/etc todo lists so can focus on fgdb.rb
not fgdb
- User:Ryan52/maintenance
- ASS
- hard drive tester
- keyboard tester
queue
the old shit release - April 23rd?
- TODOs in the code, ./script/ack-the-diff
- #17932 tricky to log 0 hours when the schedule expects hours
- #16656 make the store people happy with returns
- #15885 fix up coveredness tracking
- MAYBE add covered and contract_id to spec_sheets, and put it there as well as on systems
- trying to accomplish:
- plan:
- change the checkbox to a dropdown
- code after entering a system that (synchronously, not async) connects to get the systems covered value if it exists, presets it in the widget, and disables the widget
- add to the systems contract fixing page to fix the covered value too
- show the covered widget everywhere (adding sales)
queue + 1
the library release - May 7th?
- #14514 finish library stuff
queue + 2
the unimportantish release - May 21st?
- #14861 swap computers (tech support)
- I WANT A TEST SUITE
- db cleanups
- gizmo_types.effective_on has a silly default
- workers.contact_id needs to be unique
- users.contact_id needs to be unique
- flatten contact_method_types (add a category)
- created_at should be NOT NULL
- #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
- link to old system IDs on the systems page as well
- #17231 "current" system ids
- get fgdb.rb able to be set up by new freegeeks and new coders
queue + 3
the cool toy release - June 4th?
- #17255 overtime report
- #17031 integrate meeting-minder functionality into skedjulnator
- Replace SOAP usage with [1]
queue + 4
what's left release - June 18th?
- 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
- cashier code enhancements
junk
- #17796 database - Committed Hours & PTO
- 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
- the log rotate script breaks auto-update: tee: /var/www/fgdb.rb/log/auto-update.log: Permission denied
- get continuation to work with multiple branches
- get continuation running with test-migrate
- 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.