Skip to content

Fixing bug grading report#64

Open
diegosanchez wants to merge 4 commits intodevelopfrom
fixing_bug_grading_report
Open

Fixing bug grading report#64
diegosanchez wants to merge 4 commits intodevelopfrom
fixing_bug_grading_report

Conversation

@diegosanchez
Copy link
Copy Markdown
Member

Comment thread models/report/grading_report.rb Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Me parece que valdría la pena investigar un poco a ver si esto mismo se puede resolver directamente en la query que DataMapper le tira a la BD en vez de traerse los datos y hacerlo en la aplicación.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Refactorizo

@nicopaez
Copy link
Copy Markdown
Contributor

nicopaez commented Sep 5, 2013

Hay algo que no me cierra: hay lógica del negocio (determinar la nota del alumno) que se calcula en la clase reporte.
Adicionalmente eso tiene el problema de que incluye un costo adicional.
Yo encararia este cuestión dentro de student.status_for_assignment(assignment), de manera que el assignment_status tenga la nota y el corrector.
Por otro lado hay método correction_teacher que no es necesario pues el assigment_status ya tiene el nombre del corrector.

@diegosanchez
Copy link
Copy Markdown
Member Author

Todos los comentarios me parecen válidos. Creo que la manera de seleccionar la corrección asociada a AssignmentStatus necesitaría una vuelta de tuerca. Agregué un comentario a una tarjeta de trello cuyo tema afecta también a esta story Trello#101 - Como docente en la página de soluciones a corregir para un alumno el boton editar está habilitado cuando no debería ya que la solución no es la última

@anero
Copy link
Copy Markdown
Contributor

anero commented Sep 5, 2013

Estoy de acuerdo que tenemos que pensarlo un poco más esto, habíamos
hablado de no prohibir a los docentes corregir una solución aunque no sea
la última, por eso el edit está habilitado para todas las soluciones (salvo
para las que existe una corrección que tiene otro docente). De todas formas
en estos casos probablemente falle el calculo del estado de la solución en
el AssignmentStatus... Si nos juntamos hoy lo charlamos.

2013/9/5 DiegoS notifications@github.com

Todos los comentarios me parecen válidos. Creo que la manera de
seleccionar la corrección asociada a AssignmentStatus necesitaría una
vuelta de tuerca. Agregué un comentario a una tarjeta de trello cuyo tema
afecta también a esta story Trello#101 - Como docente en la página de
soluciones a corregir para un alumno el boton editar está habilitado cuando
no debería ya que la solución no es la últimahttps://trello.com/c/HSGYWWPr


Reply to this email directly or view it on GitHubhttps://github.com//pull/64#issuecomment-23866899
.

@nicopaez
Copy link
Copy Markdown
Contributor

nicopaez commented Sep 5, 2013

ok, pero yo veo dos cosas distintas.
Por un lado la lógica deberia quedar oculta entro del método que calcula
el estado del asigment (actualmente está en la clase Account) y el reporte
simplemente invocar a eso.

Luego por otro lado, podemos reveer la forma en que se calcula el estado,
que es justamente lo que dice la tarjeta 101.

@anero
Copy link
Copy Markdown
Contributor

anero commented Sep 5, 2013

Lo que entiendo de la tarjeta 101 es que más allá del estado del
assignment, se deja crear correcciones para todas las soluciones, no solo
para la última. Esto es intencional, lo discutimos en algún momento y
decidimos dejar que los docentes corrigieran cualquier solución, sea o no
la última (o por lo menos así lo entendí yo y así fue como lo implementé).
De mantener este comportamiento el cálculo del AssignmentStatus debería
actualizarse. Es un tema complejo así que diría que lo hablemos tranqui a
la tarde en la facu.

Saludos,
Diego.

2013/9/5 Nicolas Paez notifications@github.com

ok, pero yo veo dos cosas distintas.
Por un lado la lógica deberia quedar oculta entro del método que calcula
el estado del asigment (actualmente está en la clase Account) y el reporte
simplemente invocar a eso.

Luego por otro lado, podemos reveer la forma en que se calcula el estado,
que es justamente lo que dice la tarjeta 101.


Reply to this email directly or view it on GitHubhttps://github.com//pull/64#issuecomment-23869534
.

@anero
Copy link
Copy Markdown
Contributor

anero commented Sep 5, 2013

👍 está para mergear para mi!

@anero
Copy link
Copy Markdown
Contributor

anero commented Aug 2, 2014

No se si al final esto lo íbamos a mergear o no, pero por las dudas le hice un rebase sobre develop para que no haya conflictos (también metí un par de refactorings chiquitos en los specs)

@nicopaez
Copy link
Copy Markdown
Contributor

Che, ¿como es la situación de esto? Entiendo que no fue mergeado pero me queda la duda si ¿este fix siguen aplicando? o sea ¿sigue siendo necesario?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants