Feedback needed on breaking change - v1/users/extended

Sounds reasonable.


One thing; ID elements, eg record IDs, vary across APIs as string or integer/numeric. If the ID is truly a record/table ID then it should not be a string, it should be numeric. The FE NXT APIs get this right, the others tend not to.


One  way to avoid an immediate breaking change would be to add the new field and retain the existing one for a deprecation period, say, 6 months. That's what I'd do, anyway.


Also, thanks for the heads up and consultative approach. Much appreciated.

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

 

Has there been any update to this? The string value in `grade_level` on the student is not always sufficient to uniquely identify grade level. Having an additional id field would help solve the problem.

I know it is old, but there was not any follow up on it and it doesn't seem to have been updated in the API. Is there a plan to reopen this issue? Adding grade_level_id as an additional field without removing grade_level_description would mean that it is not a breaking change, so it shouldn't affect compatibility.

The grade_level_description value is not unique for all of our clients, which means it is currently not possible for us to determine which grade level they are in without inferring it by going through their section list. E.g.:

grade_levels: { id: 1, …, name: “9”}, { id: 2, …, name: “9” }

student.student_info: { grade_level: 10, grade_level_description: “9” }, { grade_level: 20, grade_level_description: “9” }

We have two grade levels, and the students are in different ones based on their student_info.grade_level value, but there's no way to tell which one they're in. Adding the grade_level_id object would let us identify them without any problems.

Steven Cinquegrana:

The two links to endpoints provided by @Bryna Gleich still show grade_level.

Would someone please advise if this change has been abandoned, or if not when it might happen?

I have no additional information at this time. A developer or product manager would need to answer that. I will let you know if I learn more.

@Angie Addison I don't think that was the original change. The proposed change was to replace grade_level with grade_level_id which would break any existing implementations. But adding the ID field would not break anything, obviously.

Hey there, I think there may be a mix of things in this trail. What we just addressed was adding a unique identifier since what was previously available didn't guarantee uniqueness. We didn't change anything about what was originally available that I know of so the recent release should not have caused issues with any existing integrations (that didn't already exist). I did not see posts here about extra digits or space in what was already out there, I can have the team take a look thanks!

got it thanks, thought you meant a response in the current thread. The best bet for things like that are to report through support as then they'll figure out if something we just introduced that's a bug, an enhancement request and they'll float it up to product development and dev since we monitor these threads frequently but it's not a direct instant channel to us.

@Angie Addison are there any updates on this thread? the grade level ids coming back in `student_info` still don't match the ones from `/gradelevels`