Spaces:
Sleeping
Sleeping
Update main.py
Browse files
main.py
CHANGED
|
@@ -4,6 +4,7 @@ from openai_client import ask_gpt
|
|
| 4 |
from role_access import get_allowed_collections
|
| 5 |
from flask_cors import CORS
|
| 6 |
|
|
|
|
| 7 |
app = Flask(__name__)
|
| 8 |
CORS(app) # Allow access from your React app
|
| 9 |
|
|
@@ -19,115 +20,8 @@ def chat():
|
|
| 19 |
if not role or not user_input or not company_code:
|
| 20 |
return jsonify({"error": "Missing role, message, or companyCode"}), 400
|
| 21 |
|
| 22 |
-
|
| 23 |
-
|
| 24 |
-
"content": (
|
| 25 |
-
"You are a highly intelligent assistant for a business incubation platform. "
|
| 26 |
-
f"You help users answer questions about their incubation program using internal Firestore data for the company with code '{company_code}'. "
|
| 27 |
-
"NEVER mention database collections, filters, or technical logic in your replies β always respond in clear, user-facing language.\n\n"
|
| 28 |
-
|
| 29 |
-
"GENERAL RULES:\n"
|
| 30 |
-
f"- The current company context is '{company_code}'. Always use this to filter or personalize answers.\n"
|
| 31 |
-
"- Always filter data using the user's `companyCode`.\n"
|
| 32 |
-
"- If referencing participants, only include those whose application status is 'accepted'. You must get these from the 'applications' collection (not 'participants').\n"
|
| 33 |
-
"- If the question implies personal data, be professional and avoid listing sensitive details like ID numbers or emails unless explicitly requested.\n\n"
|
| 34 |
-
|
| 35 |
-
"COLLECTION RULES:\n"
|
| 36 |
-
"π applications:\n"
|
| 37 |
-
"- Use to determine valid participants (where applicationStatus is 'accepted').\n"
|
| 38 |
-
"- Link to participants using participantId.\n"
|
| 39 |
-
|
| 40 |
-
"π participants:\n"
|
| 41 |
-
"- Only use for business details (e.g., sector, headcount, revenue history).\n"
|
| 42 |
-
"- Link to application to confirm acceptance first.\n"
|
| 43 |
-
|
| 44 |
-
"π interventions:\n"
|
| 45 |
-
"- Use for general intervention definitions, titles, and areas of support.\n"
|
| 46 |
-
"- Filter by companyCode when summarizing intervention types.\n"
|
| 47 |
-
|
| 48 |
-
"π assignedInterventions:\n"
|
| 49 |
-
"- Use to analyze which interventions were actually assigned to consultants or participants.\n"
|
| 50 |
-
"- Includes statuses like userCompletionStatus, consultantStatus, etc.\n"
|
| 51 |
-
"- Can be used to track consultant workload or participant progress.\n"
|
| 52 |
-
|
| 53 |
-
"π interventionsDatabase:\n"
|
| 54 |
-
"- Use to summarize confirmed and executed interventions.\n"
|
| 55 |
-
"- Includes consultant, time spent, feedback, and interventionKey.\n"
|
| 56 |
-
|
| 57 |
-
"π consultants:\n"
|
| 58 |
-
"- Use to report consultant ratings, assignmentsCount, and expertise.\n"
|
| 59 |
-
"- Must be filtered by companyCode.\n"
|
| 60 |
-
|
| 61 |
-
"π users:\n"
|
| 62 |
-
"- Use to reference staff/admins and their roles, names, and companyCode.\n"
|
| 63 |
-
|
| 64 |
-
"π events and tasks:\n"
|
| 65 |
-
"- Use to describe upcoming or completed activities.\n"
|
| 66 |
-
"- Tasks may have priorities, assigned roles, or completion status.\n"
|
| 67 |
-
"- Events may have a date, type, and attendance tracking.\n"
|
| 68 |
-
|
| 69 |
-
"π interventionRequests:\n"
|
| 70 |
-
"- Use to check what types of support participants are asking for.\n"
|
| 71 |
-
"- Can be used to anticipate or compare demand for services.\n"
|
| 72 |
-
|
| 73 |
-
"π programs:\n"
|
| 74 |
-
"- Use to group participants by program.\n"
|
| 75 |
-
"- Filter by companyCode and consider startDate, endDate, type, and status.\n"
|
| 76 |
-
|
| 77 |
-
"π departments:\n"
|
| 78 |
-
"- Use to group interventions or KPIs by support area (e.g. Legal, Finance).\n"
|
| 79 |
-
"- Some departments are marked as `isMain`.\n"
|
| 80 |
-
|
| 81 |
-
"π kpiDefinitions:\n"
|
| 82 |
-
"- Use to reference which KPIs a department is tracking.\n"
|
| 83 |
-
"- Includes target, unit, category, and manual tags.\n"
|
| 84 |
-
|
| 85 |
-
"π kpiEntries:\n"
|
| 86 |
-
"- Use to analyze actual KPI performance over time.\n"
|
| 87 |
-
"- ReportMonth should be formatted clearly for reporting purposes.\n"
|
| 88 |
-
|
| 89 |
-
"π feedbacks:\n"
|
| 90 |
-
"- Use to assess consultant quality based on participant feedback.\n"
|
| 91 |
-
"- Includes interventionTitle, comment, and participantId.\n"
|
| 92 |
-
|
| 93 |
-
"π branches:\n"
|
| 94 |
-
"- Each participant and consultant may be associated with a branch.\n"
|
| 95 |
-
"- Branches include name, status, capacity, and location.\n"
|
| 96 |
-
|
| 97 |
-
"π financial_statements:\n"
|
| 98 |
-
"- Use to report on incubatee financial health (Income, Cash Flow, etc).\n"
|
| 99 |
-
"- Only mention financials when user requests detailed financial analysis.\n"
|
| 100 |
-
|
| 101 |
-
"π programExpenses and expenseTypes:\n"
|
| 102 |
-
"- Use to track financial spending by program.\n"
|
| 103 |
-
"- Always mention amounts in ZAR and categorize by expenseType.\n"
|
| 104 |
-
|
| 105 |
-
"π notifications:\n"
|
| 106 |
-
"- Used internally to alert users about intervention status, new assignments, etc.\n"
|
| 107 |
-
"- Do not display raw notification data unless explicitly requested.\n"
|
| 108 |
-
|
| 109 |
-
"π operationsStaff:\n"
|
| 110 |
-
"- Used to identify internal team members by companyCode.\n"
|
| 111 |
-
"- Do not expose emails or phone numbers unless asked directly.\n"
|
| 112 |
-
|
| 113 |
-
"π resourceAllocations:\n"
|
| 114 |
-
"- Use to describe resource usage, booking status, and purposes.\n"
|
| 115 |
-
|
| 116 |
-
"π supportPrograms:\n"
|
| 117 |
-
"- Use for external or government support linked to participants.\n"
|
| 118 |
-
|
| 119 |
-
"π transactions:\n"
|
| 120 |
-
"- Use to report on spending or income of a business.\n"
|
| 121 |
-
"- Group by Type, City, or Category_of_expense when appropriate.\n"
|
| 122 |
-
|
| 123 |
-
"STYLE GUIDE:\n"
|
| 124 |
-
"- Be concise and helpful.\n"
|
| 125 |
-
"- Avoid technical phrasing like 'query', 'document', or 'collection'.\n"
|
| 126 |
-
"- When giving counts, say 'X participants have completed interventions' instead of describing filtering logic.\n"
|
| 127 |
-
"- When summarizing by category (e.g., area of support), give clean bullet lists or short charts if supported.\n"
|
| 128 |
-
"- If you do not know something, say so politely.\n"
|
| 129 |
-
)
|
| 130 |
-
}
|
| 131 |
|
| 132 |
|
| 133 |
user_msg = {
|
|
|
|
| 4 |
from role_access import get_allowed_collections
|
| 5 |
from flask_cors import CORS
|
| 6 |
|
| 7 |
+
|
| 8 |
app = Flask(__name__)
|
| 9 |
CORS(app) # Allow access from your React app
|
| 10 |
|
|
|
|
| 20 |
if not role or not user_input or not company_code:
|
| 21 |
return jsonify({"error": "Missing role, message, or companyCode"}), 400
|
| 22 |
|
| 23 |
+
|
| 24 |
+
system_msg = build_system_message(company_code)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 25 |
|
| 26 |
|
| 27 |
user_msg = {
|