P0: Intake 'Objective' Flag for Topcoder Users

[ajefts]

Objective: Add a data flag ("Customer Project Request" vs. "Demo/Test") for Topcoder user roles to indicate their purpose for submitting project intake. This flag will serve two purposes. First, it will aid ensuring that we have cleaner data for internal analytics purposes. Second, it will serve the routing of new projects alerts to BDRs/AEs.

Requirements:

• If a Topcoder user role (admin/manager/copilot) accesses a project intake form, when the intake form loads for these users they should see the following on the first screen of each intake form:

• Question Title: "Intake Purpose"

• Checkbox Answer Options:

  • "Submitting Client Request"

  • "Internal Project"

  • "Demo/Test/Other"

Note: This should be a required question and answer for all Topcoder users who are submitting an intake form.

[ajefts]

Link to feature: https://tcprod.productboard.com/feature-board/planning/features/2762550

[maxceem]

As I understand, this question should be stored in some filed like:

details.intakePurpose

With the possibles values:

• client-request
• internal-project
• demo-test-other

If project is being created by a customer user and we don't show this question, should we set the value of this field by default to details.intakePurpose = "client-request"?

[vikasrohit]

Yes, we are thinking of something similar, however, the problem is that we don't yet have support for hide/show of a question based on user role. Can you please create a separate task for that and get it done with the bug bash or may you directly.

[maxceem]

I was thinking to hardcode such a question into the create form, though supporting it as a general ability to hide question depend on the user role sounds better to me.

I'll migrate permission method from Project Service for checking permissions and will add the support for such questions myself or via bug bash.

[vikasrohit]

Cool. I didn't get where and why we need to migrate the permission method?

[maxceem]

I didn't get where and why we need to migrate the permission method?

In Project Service we created reusable method to check permissions described in the issue General permission methods

We also, have a similar method client-side but it's different so I was thinking to introduce new functionality which depends on the user permissions using new general method from server-side (copy it to client side and adapt if necessary).

[vikasrohit]

Okay. I think we should do it with logic we have right now without much refactoring. we would do refactoring later.