Candy explained to me that, for technical reasons, it will not be possible for users to add new Hangout friends dynamically, so I will comment out all the subdialogues in enroll that ask for video call names. I assume that the installer will set up Hangout friends in advance for each user (or add them later on request, perhaps).
However, in order to make outgoing calls based on names like "Ed Smith" (or look up names for incoming calls), I assume you will want to store the gmail addresses of the Hangout friends in the user model? If so, then there is a question of how the installer will enter that information. You could do it by editing the.owl file, but that seems like a bad idea. I propose to leave the ability to edit the video call field for an already enrolled person in the UI, mostly for the use of the installer. The user could happen to do it also, but it would be harmless.
NB: However, this means that you need to be able to reject an email address that is not really registered. This should probably also just come under the catch for unsuccessful connections, but you should test it.
I don't think it pays to make a special mode for installers, and we have run out of development resources, anyways.
Candy explained to me that, for technical reasons, it will not be possible for users to add new Hangout friends dynamically, so I will comment out all the subdialogues in enroll that ask for video call names. I assume that the installer will set up Hangout friends in advance for each user (or add them later on request, perhaps).
However, in order to make outgoing calls based on names like "Ed Smith" (or look up names for incoming calls), I assume you will want to store the gmail addresses of the Hangout friends in the user model? If so, then there is a question of how the installer will enter that information. You could do it by editing the.owl file, but that seems like a bad idea. I propose to leave the ability to edit the video call field for an already enrolled person in the UI, mostly for the use of the installer. The user could happen to do it also, but it would be harmless.
NB: However, this means that you need to be able to reject an email address that is not really registered. This should probably also just come under the catch for unsuccessful connections, but you should test it.
I don't think it pays to make a special mode for installers, and we have run out of development resources, anyways.