mugle-dev team mailing list archive

[Matt Giuca <eatmyshortz@xxxxxxxxx>]

On Fri, Apr 29, 2011 at 5:39 PM, Scott Ritchie <s.ritchie73@xxxxxxxxx>wrote:

> Hey guys,
>
> Ive just gone through the data classes now and marked the fields with their
> permissions, but i think some of them need discussion.
> Unless i specify otherwise All fields are viewable if the object you're
> looking up belongs to you (set to Role.GUEST)
> Let me know if you disagree with any of the reasoning ive given.
>

Thanks for making this list. Good to have a discussion, and we can flag
certain items here for further discussion and possibly escalate them up to
Shanika.


> Also i think it would be a good idea to discuss the role of Admins and what
> they should/shouldnt be able to see in general.
>

Admins should be able to see everything. They are trusted people, and likely
to be the same people who are administrators on the Google App Engine
control panel anyway (so they can see everything if they wanted to).

- I've left it so if you can see the object and it doesnt belong to you, you
> can see the primary key (to make lookups faster)
>
> Achievements:
> - No-one can see which UserAchievements relate to it as i felt its not
> necessary to know client side
>

Hmm, I'm not bothered by this; if all achievements are fully public for all
users, that isn't a problem. Achievements are supposed to be public badges
of honour, after all.

- You can't see the unique name of the Achievement unless you're an ADMIN
> (you can see the displayName)
>

I don't see why. The unique name is just a short name for programmers to
use. It isn't a security problem if you can see it, it's just a user
experience problem if it is exposed to users.

DevTeams:
>  - If you're not part of the DevTeam you can't see its members unless
> you're an ADMIN (to prevent spamming the DevTeam members)
>

Good.

Games:
>  - You can't see the gameToken of a game that doesnt belong to you unless
> you're an ADMIN
>

Good.


>  - You can't see the total number of ratings a game has been given unless
> you're an ADMIN (felt it was not necessary)
>

I feel like at least the devteam of the game should be able to see this.

 - You can't see the gameVersions belonging to a Game that doesnt belong to
> you unless youre an ADMIN (you can however access the gameVersion itself if
> you know it)
>

Why can't the devteam see this?

 - No-one can see the UserGameProfiles related to a Game (felt it was not
> necessary to see)
>

I think we could discuss further whether the devteam of the game should be
able to see the UGPs. On one hand, they should be able to act as
administrators of their own game, and have full power over all the users for
the purpose of the game. But on the other hand, there is user privacy to
consider. It could go either way.


> GameFiles:
>  - Not sure about who can see the blobKey and GameVersion until the
> GameFile upload and serving is implemented so have left so anyone can see
> them
>

Only the devteam should be able to see the blobKey and GameVersions.

GameVersion:
>  - You can't see the gameFiles of a GameVersion that doesnt belong to you
> unless you're an ADMIN (you can of course access the GameFiles directly)
>

Good.


> KeyValuePairs:
>  - No-one can see any of these fields - KeyValuePairs should only be viewed
> through the API calls
>

Fair enough. Admins could possibly see them, but if it means extra
implementation effort then it doesn't matter.

I think admin users should be able to make API calls without a gametoken.

UserGameProfiles:
>  - No-one can see the KeyValuePairs
>
> Users:
>  - only ADMIN can see the "active" field. The active field indicates
> whether a player is banned on not (Prageeth)
>

Good.

 - IF you are looking at another user you can see:
>     - the ID (primary Key)
>     - urlName
>     - Role
>     - UserGameProfiles
>

But what can you see inside the UGPs? I think you should be able to see
another users' achievements and high scores, but not their key value store.


>  - IF Youre an ADMIN looking at another user you can additionally see:
>     - the unique ID provided by Google
>     - the devTeams they are part of
>

OK.


> We need to decide if people can see which devTeams other users are part of,
> and maybe a method for user's to allow other user's to see their emails?
>

I think you should not be able to see which dev team another user is in,
unless you are also in that devteam.

I think you should not be able to see another users' email, unless you're an
admin.

NOTE: I am going out so I won't be working on this any more tonight.