Comment 2 for bug 730086

I'm still a bit concerned about this approach. I talked to Prageeth about it yesterday.

Firstly, I am concerned that these "info" classes will duplicate a lot of code. You will need to specify all of the fields again in the info class as you do in the model classes, and if you need to change any fields, update both versions. As you outline in the bug description, you might need two versions of each class as well -- that implies a lot of duplication. Please try to avoid this if possible! Prageeth suggested using null to hide the data rather than a separate class.

My second concern is that there would be a security issue if any data was placed in an info class that shouldn't be accessed by the person that is receiving that class, even if the client code doesn't make it available. It doesn't seem tractable to manually write different versions of each class for different stakeholders -- e.g., a dev team may need to be visible to admins, lecturers, the team themselves, and other non-team members. That's four different access groups who may have four distinct sets of fields they can see. Any mistakes would be security vulnerabilities. A general solution might be required, where on the server side, the access level is used to construct the correct set of fields to put into the info class.