Update the existing model to GSP structure/ labeling/ language

[ehmatthes]

This issue is a step in #49. This is a major step, so it gets its own issue.

• The basic changes:
  • Subject Area, Subdiscipline Area stay the same
  • Competency Area -> Graduation Standard
  • Essential Understanding -> Performance Indicator
  • Learning Target -> Learning Objective

[ehmatthes]

Question: Do I really need to rewrite all this? I wonder if I could just add an alias to each element?

• It might be good to allow users to set their own aliases. Then again, being assertive about a structure is needed in educational infrastructure.
• I could use the alias approach while developing what is still an MVP. If GSP people are supportive and collaborative, simplify the code to match what's visible. If not, I'd want to switch back to our original taxonomy anyways.

Maybe this issue is pretty simple after all!

[ehmatthes]

Try:

• [x] Make an alias for CompetencyArea, with default set to "Graduation Standard".
  • [x] Modify models.py, makemigrations, migrate
• [ ] Modify entire_system view to replace the Competency Area label with its alias.
  • Not using entire_system, so ignore this.
  • Added a subject area "Science" through edit subject areas.
  • School page (/schools/3/) shows school as "School object", subject as "SubjectArea object".
  • manage.py shell -> django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.
  • but schools page shows correct school names
  • {{ school }} is no longer showing the default returned from unicode()?
  • unicode() is for Python 2; str() is for Python 3.
  • That was inefficient. I can probably make a setting somewhere that stores these aliases. Maybe a model called Taxonomy or something?
  • "Competency Area" with a space in it is always user-facing. "CompetencyArea" is always code. Maybe I can sed replace "Competency Area" -> "Graduation Standard", and only ever touch user-facing elements?
  • Work in /templates:
  • find . -type f | xargs sed -i 's/Competency\ Area/Graduation\ Standard/'
    • rolled this back as well, with focus on creating a new view aligning with GSP model
  • Sometimes I just used 'Competency', so follow this by:
  • find . -type f | xargs sed -i 's/Competency/Graduation\ Standard/'
    • this may actually cause problems, because 'competency' is used in code. (I haven't committed this yet, could undo these sed steps.)
    • undoing this step, go with first step and fix other labels by hand
• [ ] Remove alias, and just modify hard-coded labels on site for now.
  • Moved to next milestone.
  • It will get confusing to have {{ ca }} that shows a graduation standard. Changing the code will be worthwhile if we stay with this taxonomy. Do this work once there's more than just me, or if we're clearly going with GSP taxonomy. This exercise really shows how closely our two systems are structured, and this phase is really presenting our taxonomy in the way GSP has started to present theirs.
• [x] Add enough sample data to verify that the labels are being changed appropriately.
  • This is really following the taxonomy down to its deepest level to one learning objective.
  • [x] replace essential understanding -> performance indicator
  • [x] replace learning target -> learning objective
  • [x] replace CA -> GS
  • [x] replace EU -> PI?
  • [ ] replace LT -> LO
  • Not dealing with this taxonomy level for now; there's much useful work to be done establishing a system through the performance indicator taxonomy level.

[ehmatthes]

Create a new view, sa_summary, which looks like GSP model.

• [x] Add a phrase field to CompetencyArea. This is a phrase summarizing the graduation standard.
• [x] Add enough sample data to fill in the sa_summary page. 1 subject area, 1 grad standard, 3 performance indicators.
• [x] Create view.
• [x] Create template.
• [x] Link to view.
  • Holding off on this for now. Will focus on an edit_sa_summary screen first, then build out the links/ ui.

[ehmatthes]

Create an edit_sa_summary page. Mirrors sa_summary, except every element is editable. Update sa_summary as appropriate.

• [x] url, view, template set up
• [x] behavior correct
  • [x] display current subject area in a form element
  • [x] display grad standards in form elements
  • [x] display performance indicators in form elements
  • [x] process data for saving
  • [x] validation
  • [x] saving to db
• [x] styling appropriate for other staff
• [x] resolve issue with sa/ sda
• [x] incorporate sdas into sa_summary and edit_sa_summary
• [x] add links to create new sa, sda, grad std, and perf indicator

[ehmatthes]

• [ ] Change subdiscipline_area to subject.
  • Subdiscipline area behaves just like a subject, except that it can have a subjectarea as a parent. Things would probably be a lot simpler if subject area could have a parent subject area.

On reflection, it's good to have a distinction between a subject area and a subdiscipline area. I think I can simplify the code, though.

[ehmatthes]

resolve issue with sa/ sda

• [ ] try: sda simply inherits from SubjectArea, with fk to a SubjectArea required.
  • The project could work with sda as is. But changing it later might be an uglier data migration. Try now, while there's no sdas in the system.
  • problem: can't call fk to SubjectArea subject_area, because SubjectArea has a subject_area field?
  • Ignoring this for now; it's a backend issue that gets into other questions, ie should SubjectArea have a field called subject_area, or is that more properly called text or something?

[ehmatthes]

incorporate sdas into sa_summary and edit_sa_summary

• [x] Incorporate sdas into sa_summary.
  • [x] Add two relevant sdas.
  • [x] Show in view.
• [x] Revise edit_sa_summary.
  • [x] Display and save sdas in form.
  • [x] Display and save sda cas in form.
  • [x] Display and save sda eus in form.

[ehmatthes]

Create new elements

• [x] add links to create new sa, sda, grad std, and perf indicator
  • as a separate page for each element
  • easier as separate page; already exists, and includes information not currently shown such as description and student_friendly
  • An established system will need editing much more often than creating new elements. Embedded elements will just make clutter, and may encourage making too many elements.
• [x] new subject area (new_sa/school_id/)
  • should link, or redirect to summary page for the new sa
• [x] modify /school/ so that subject areas link to sa_summary page
• [x] new_sda
• [x] new_gs
  • [x] new grad standard for a general subject area
  • [x] new grad standard for a subdiscipline area
• [x] new_pi

[ehmatthes]

address ordering of elements

• [ ] Make elements appear in a consistent order
  • Moving to separate issue. #55
• [ ] Allow editing of order?
  • moved to next milestone

[ehmatthes]

Delete unused pages

The old system was really clunky; with most viewing functionality included in sa_summary and most editing functionality included in edit_sa_summary, can probably get rid of many pages.

• [x] Remove links on site to unused pages.
• ~~[ ] Remove from urls.py, views.py, templates?
  • Are there any that might be used again? Probably better to pull from history than keep cluttering project.~~
  • Could choose to finish this milestone by focusing on correct behavior, then open a separate milestone for cleaning codebase and refactoring. This.