fix: Add signup disabled flag check on signup route

[Souptik2001]

What does this PR do?

(Just to note that in the below video I am refreshing the server again and again is just to refresh the cache, so that I don't have to wait for 5 mins.)

https://www.loom.com/share/5246b4b7e13b4b759086f74d57fa19d5?sid=9eadf523-4c58-440b-bdc6-31a96cee0152

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have added a Docs issue here if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

• Create a POST request to signup API as demonstrated in the video. This should be successful.
• Then disable the signup from the admin settings.
• Wait for 5 mins. (cache expiration time)
• Then again make the above request. This should now say that signup is disabled.

[vercel]

@Souptik2001 is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[graphite-app]

Graphite Automations

"Add community label" took an action on this PR • (07/20/24)

1 label was added to this PR based on Keith Williams's automation.

"Add consumer team as reviewer" took an action on this PR • (07/20/24)

1 reviewer was added to this PR based on Keith Williams's automation.

"Add foundation team as reviewer" took an action on this PR • (07/23/24)

1 reviewer was added to this PR based on Keith Williams's automation.

[anikdhabal]

Hey @Souptik2001, as we check the admin feature flag, shouldn't we also update the other routes that have related flags present in the admin feature? For example: email verification, team, etc.

[Souptik2001]

@anikdhabal Yes you are correct!

Seems like the feature falgs are not respected at many places.

• For email-verification, it is properly implemented. ✅
• For emails, it is properly implemented. ✅
• For organizations it is partially implemented. ⚠️
• For teams, seems like it is not at all implemented? 🤔 As per I saw the teams feature was used nowhere (I may have missed also 🙏 )

For organizations -
I was not able to fully understand the purpose of this feature flag. I thought that it should disable the organizations feature completely. Is it meant for that only?
Because at some places (front-ends) (like creating a new organization), it redirects the page to 404 if this flag is disabled.
But majority front-ends are not handled, even the Organizations are visible in the left sidebar.
And the APIs are completely unprotected just like the signup one.
I have pushed a commit, which basically implements a middleware to check for the feature flag. Can you please check that.
I have implemented it in such a way that we can now protect any APIs (example - teams) using a feature flag.

If you can confirm the function of the organization feature flag, then I can go ahead and modify the front-end also to respect the flag.

And also if you can confirm that teams will need to be also respected.

[zomars]

Hey @Souptik2001, as we check the admin feature flag, shouldn't we also update the other routes that have related flags present in the admin feature? For example: email verification, team, etc.

This is out of scope for this PR. We should open up different issues for each one.

[zomars]

I think this is good enough for now. As extra points we could add some tests to verify the signup page/endpoint are disabled tho.

[Souptik2001]

As extra points we could add some tests to verify the signup page/endpoint are disabled tho.

Sure @zomars will do that in sometime.

[Souptik2001]

hey @zomars sorry, was working on another issue (#15828), therefore couldn't get this one done.

Will do this one sometime tomorrow. 👍

[keithwillcode]

Looks like there are consistently failing E2E tests we need to fix