Closed fozcode closed 5 years ago
This change of course might break existing API consumers, but tough luck, it's a bug in the implementation that needs fixing
I've changed my mind on removing user
from tasks. It's been there a long time, it is correctly guarded by user permissions, and it is useful if you're querying tasks as the super user. I'll just remove it from portfolios.
The Portfolios API "helpfully" includes serialized user objects in its output for the
owner
and historyuser
fields. Unfortunately portfolios can be public facing, and therefore this can leak the username and email address of anyone that has created or interacted with a portfolio. We need to remove these objects, just leaving theowner_id
and historyuser_id
fields in place. Anyone that needs to look up the user information will have to do so with a separate call to ensure they have user admin permission.The Tasks API also does this but is technically not affected because it should only return the user object of the current user or else only to super users. I think it's best if we delete it from here too though. The current user already knows who they are after all, so it doesn't add much in the common case.
owner
objectuser
objectuser
object