I am aware that the current Group API (V1, as I've seen it called) is lacking functionality that will be added in the future. However, we aim to have a Group-Based beta guild implementation in Q1/Q2 and we'd like to make the most out of the system as it is right now.
We have solved the fact that Groups are not searchable by storing their IDs/names somewhere else on creation.
I have a number of questions:
1. How can I map TitleIDs to PlayFabIDs (to retrieve DisplayName)?
Group applications need to be approved by an Admin - How can I get that player's DisplayName and UserData? (There has to be at least SOME information regarding that player in the application itself, of course, admins would have a hard time approving or denying applications otherwise).
The Group Application ID is an Entity ID, but I have been reading the documentation and I found no way to map Entity ID (Player Title ID) to a PlayFabID, that I would need in CloudScript to retrieve more info about that player.
Of course, once I have the PlayFabID, I can use GetUserData or GetAccountInfo for all I need.
This would also solve our player index (we use outside storage to store a mapping between Player Title IDs and their display names). The plan is to store the user's name in the outside storage and only update it when a user joins or leaves the Group.
2. Are Group SetObjects/GetObjects CloudScript calls vulnerable to concurrency issues?
We plan to use Group Objects to store guild-specific data (for example, a treasury where all players can contribute with their gold).
The code would be on CloudScript. Would concurrent writes be an issue? If I have a function that reads a value (GetObjects) and then writes it back (SetObjects) on the Group entity, would that be a problem for a small-sized guild system? (10-15 members per guild).
3. I was reading some other posts and in one of the comments, Brendan mentioned that the V2 extended feature set for Groups may be available early summer. Any updates on that?