🐛 Bug Report: Server SDK Create Recovery functionality does not mirror similar functions

[Swinkid]

👟 Reproduction steps

        client
            .setEndpoint(env['APPWRITE_FUNCTION_ENDPOINT'])
            .setProject(env['APPWRITE_FUNCTION_PROJECT_ID'])
            .setKey(env['APPWRITE_FUNCTION_API_KEY']);
...
         let recovery = await account.createRecovery('...', '...');

or

        client
            .setEndpoint(env['APPWRITE_FUNCTION_ENDPOINT'])
            .setProject(env['APPWRITE_FUNCTION_PROJECT_ID']);
...
         let recovery = await account.createRecovery('...', '...');

👍 Expected behavior

If calling the createRecovery endpoint from the server SDK, it should allow an API Key and NOT send an email to the user. This is to match similar functionality provided by the teams endpoints. If an membership is created from the server SDK, the server does NOT send an email and automatically adds the user to the team.

This proves useful if the developer is trying to develop a custom recovery flow, for example texting a recovery code to a phone number registered to the account or if the developer is trying to send a custom email.

👎 Actual Behavior

If called with an API key you get the following error and no email:

response: {

17:27:35 0|server  |     message: '[email protected] (role: application) missing scope (public)',

17:27:35 0|server  |     code: 401,

17:27:35 0|server  |     type: 'general_unauthorized_scope',

17:27:35 0|server  |     version: '0.13.3'

17:27:35 0|server  |   }

If called without a API Key, you'll get an email.

🎲 Appwrite version

Version 0.13.x

💻 Operating system

Windows

🧱 Your Environment

No response

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

I could see how generating that secret and not sending the email can be useful. I don't think it should be in account api though because the account api is for doing stuff on behalf of a user. So perhaps a new endpoint in users api would make most sense.

[Swinkid]

After discussion with

I could see how generating that secret and not sending the email can be useful. I don't think it should be in account api though because the account api is for doing stuff on behalf of a user. So perhaps a new endpoint in users api would make most sense.

Actually I agree with that, probably more of a feature improvement than a bug. Looking the API in accounts.php, probably fairly easy to do this for users.. don't mind picking this up if no objections?