Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added components for performing search filtering #76

Merged
merged 1 commit into from
Dec 17, 2018

Conversation

sjrumsby
Copy link
Owner

Filtering adds very basic support for kwarg parameter passing from the front end. Can perform search filtering on a limited set of columns, and does not support deep search across relationships or complex search types (e.g., LIKE, OR, GTE, Dates, etc).

Does conditionally render the office for LIASON / GA roles in the table.

@@ -38,6 +38,7 @@ class Exam(Base):
booking = db.relationship("Booking")
exam_type = db.relationship("ExamType")
invigilator = db.relationship("Invigilator")
office = db.relationship("Office")

Choose a reason for hiding this comment

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

I thought we referenced offices from exams through their bookings?

Copy link
Owner Author

Choose a reason for hiding this comment

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

Exams belong to an office as well. The exams have to, so when they are added by the liason the GA can get a list of the exams in just their office, prior to being booked.

context.commit('setExams', resp.data.exams)
})
.catch(error => {
console.log('error @ store.actions.getCsrs')

Choose a reason for hiding this comment

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

should we be displaying errors in another way? shouldn't errors only be conveyed to users through html responses?

if (index >= 0) {
state.examFilters.splice(index, 1);
} else {
console.log("error finding index for filter in state")

Choose a reason for hiding this comment

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

should we be displaying errors in another way? shouldn't errors only be conveyed to users through html responses?

Copy link
Owner Author

Choose a reason for hiding this comment

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

These are mostly just for debugging purposes (same for you other comment). They could probably be removed entirely.

@sjrumsby sjrumsby force-pushed the search-filtering branch 3 times, most recently from 9962589 to 22e3e3a Compare December 14, 2018 00:13
Filtering adds very basic support for kwarg parameter passing from the front end. Can perform search filtering on a limited set of columns, and does not support deep search across relationships or complex search types (e.g., LIKE, OR, GTE, Dates, etc).

Does conditionally render the office for LIASON / GA roles in the table.
@sjrumsby sjrumsby merged commit 66a4004 into sprint-2 Dec 17, 2018
@sjrumsby sjrumsby deleted the search-filtering branch February 6, 2019 17:13
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.

2 participants