pythondave / th-admin Goto Github PK

Affects: Job Overview screen.

Can we please change the post url to save notes on this screen from /admin/service/process-application' to /admin/service/process-teacher'.

The request parameters will also need to be changed i.e. {teacherId: 123, adminNote:'bla bla bla'}

Originally I thought that score and notes given to candidates in this screen - were related to the job application. However on further discussions with AT - it was agreed that for admins the score and note are defined at the candidate level and not at the application level.

This effectively means that every time we open the score and/or comments box for a candidate - regardless the job application we are on - we will always see(and edit) a common score and note for the candidate.

This approach changes for school users where both fields are defined for candidates but at the job application level.

Please check with AT

Api method: http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/school-names

Please deprecate this method and include the school names data as a new property of: /admin/service/basic-lists.

School names records can be kept pretty much as they are now - but would be good to add the id attribute as well.

See proposed format for the school names property below:

"schoolNames": [
{
"id": 1,
"name": "School of Manuel"
},
{
"id": 2,
"name": "Ecole de Marissa"
}]

http://localhost/th-admin/2/0.4/scaffolding/api/default.html#/teachers/2 (also applies to 1 and 3, which are almost identical to 2)

Current: { search: 'te', statusId: 4, limit: 5 }
Proposal: { search: 'te', statusId: 1, limit: 5, exclude: { jobId: 123 } }

The statusId change relates to #3 (i.e. we're changing the id which represents 'Approved' from 4 to 1)

The "exclude: { jobId: 123 }" addition is so that teachers attached to jobId 123 can be excluded. I'm suggesting this rather than simply "jobId: 123" to keep things more flexible for the future - e.g. we might want to include only teachers attached to jobId 123, or we might want to exclude in other ways.

This is to help prevent missing something in the API viewer.

Also relates to testing - basically need to research what we can get out of something like http://gruntjs.com/

Hi Otto,

I met with Alex today and this issue cropped up.

We've got a user story which is something along the lines of "As a non-logged-in user I need to be able to view information about a school...".

The relevant part of the user story for this discussion is the "As a non-logged-in user" bit.

In general, the question is what our approach for developing new public access web pages should/could now be - and in particular when there's an SEO element to the requirements.

I guess we knew this question was coming.

In case you're wondering about possibilities with angularjs, this is worth looking at: http://www.yearofmoo.com/2012/11/angularjs-and-seo.html

In any case, it'd be good to come up with our options.

What are your thoughts?

Cheers!
Ryan :)

Update working processes 'docs' to include an API cycle - i.e. create and agree rough API requests before creating any UI.

'Doc' are on the main page: http://pythondave.github.io/th-admin/default.html

Would be good to change the default message when no applications are returned on this screen.
Ideally change from "No applications found for this job" to something like "No applications has been put forward for this job".
Please check with AT/AR

Applies to all API calls.

Most of the backend services we use in this area require user authentication - and this means that a 401 status is being returned when any of the pages in this project are requested.

Ideally we should intercept calls to the API methods and verify the response status.

If the response status is 401 - we should then redirect the user to the login page or something like:

if (response.status == 401){
document.location.href = config.loginUrl;
return;
}

http://localhost/th-admin/2/0.4/scaffolding/api/default.html#/process-application/1

Change the status of an application and send a message

Proposal: Remove/hide this for now (to keep things tidy and current). Add it back later when sending a message is possible.

Note: http://localhost/th-admin/2/0.4/scaffolding/api/default.html#/process-application/0 will be kept

You can currently see the whole response and a short summary. It'd be useful to be able to see the structure of that whole response (kind of like a derived schema).

When I hover over some application records - The cover note does not display.

Noticed a java script error -"Unterminated quote at column xyz" - seems to happen when single quotes are used in the coverMessage text.

See test case data sample below:

{"id":102,"teacher":{"id":8096,"fullName":"Heather Mortimer","profileUrl":"/teachers/129353","score":0},"job":{"id":966,"subject":"Not applicable","role":"Other Position","schoolName":"Park Lane International School","country":"Czech Republic"},"dateApplied":1369892357000,"coverMessage":"I would like to apply for this job because a small, personable school is the ideal situation in which to teach. My broad range of teaching and learning strategies fits well with the school's philosophy: using interactive, engaging lessons to help children think critically, work collaboratively and prepare them for an exciting future. "}

Inputs for requests to the api method below does not seem to be encoded. This is causing failure to retrieve teacher listings data from the backend.

API Method: http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/teachers/0

The problem seems to be on the teacherService class - where the post parameters submitted should be serialized before hand. i.e. $.param({statusId: 3}) vs {statusId:3}.

Wasn't an issue in 2.3, but is an issue in the current 2.4.

Steps to replicate:

1. Go to http://pythondave.github.io/th-admin/2/0.4/default.html#/jobs
2. Select Subject: "Accounting"
3. View Subject filter (you'll see Refine - undefined(x))

API method: http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/job/0

The jobId parameter is not been sent to the api method - an array of arrays is been sent instead i.e jobid[jobid].

http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/teachers/0

Get an array of teachers who are pending approval - i.e. the teachers which need to be displayed on the 'candidates to review' page.

Current: { statusId: 3 }
Proposal: ? - need OV to suggest

Note that we could potentially do this vice-versa too.

There is a bug in jobControllers.js - on function $scope.teachers - not passing the right content type.
Please replace "config.postConfig" with "config.requests.postConfig" in the controller actions affected.

I suspect this may be related to some recent refactoring of the config class.

A suggestion based on some very productive discussions which were started in some other threads - namely #17 and #18.

In general, I think it makes sense to have some agreed rules / guidelines we can all refer to when designing (or reflecting on) the API.

This should help us: a) agree API additions/changes faster, and b) create a relatively consistent API.

http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/process-teacher/0

Change the status of a teacher to "Approved"

Current: { teacherId: 123, statusId: 4 }
Proposal: { teacherId: 123, statusId: 1 }

AND

http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/process-teacher/1

Change the status of a teacher to "Declined"

Current: { teacherId: 123, statusId: 5 }
Proposal: { teacherId: 123, statusId: -1 }

Api call: http://pythondave.github.io/th-admin/2/0.4/scaffolding/api/default.html#/applications

This api method is currently used in two screens - applications and job overview screens.

The json output required varies in both cases - which causes the backend code to be more complex and harder to maintain.

So please dedicate a separate method for the application data requirement in the job overview page.

The statuses sent in the post submission for Approved/Declined actions are incorrect.
Please ammend as follows:
Approved: 1
Declined: -1