מהדורות ופרופילי ממשק

Nodaro מגיע בשלוש מהדורות — Community, Business ו-Cloud — שנבנות מאותו קוד, ובוחרים ביניהן עם המשתנה EDITION. במהדורת Business, פרופיל ממשק מצמצם אחר כך את מה שההתקנה מציגה, בלי בנייה מחדש. הפרופיל יכול להסתיר חלקים מהממשק, להסיר רכיבים ומודלים, לשנות את שם המוצר ולהגביל את ההתחברות. הדף הזה עוסק בשניהם.

שלוש המהדורות

• מהדורת Community (EDITION=community, ברירת המחדל) היא המהדורה החינמית לאירוח עצמי. כל מי שנרשם הופך למשתמש רגיל.
• מהדורת Business (EDITION=business) מוסיפה את ממשק הניהול וניהול משתמשים. גם היא מיועדת לאירוח עצמי, וגם בה אין חיוב.
• מהדורת Cloud (EDITION=cloud) מוסיפה קרדיטים וחיוב. עליה רץ app.nodaro.ai, והיא לא מיועדת לאירוח עצמי.

ממשק הניהול וניהול המשתמשים של מהדורת Business הם יכולות Enterprise. מותר להריץ אותם לפיתוח ולבדיקות, אבל שימוש בהם בסביבת ייצור דורש מנוי Nodaro Enterprise. ראו את הדף רישיון.

העברת התקנה באירוח עצמי למהדורת Business

ה-API קורא את EDITION כשהוא עולה. העורך בדפדפן קורא את המהדורה שלו מ-VITE_EDITION בזמן בניית האימג׳. האימג׳ שפורסם בנוי כמהדורת Community, ולכן בונים התקנת Business מקוד המקור.

המעבר ממהדורת Community למהדורת Business לא דורש שום שינוי במסד הנתונים: הסכמה זהה.

  nodaro:
    build:
      args:
        VITE_EDITION: business      # was: community
    environment:
      EDITION: business             # was: community

docker compose -f docker-compose.community.yml build --no-cache nodaro
docker compose -f docker-compose.community.yml up -d

התקנה שנבנתה מקוד המקור מעדכנים עם git pull ו-build. הפקודה docker compose pull הייתה מורידה שוב את אימג׳ ה-Community שפורסם.

הבנייה דוחה ערך ריק או לא מוכר ב-VITE_EDITION. בלי הבדיקה הזו, בנייה עם ערך שלא הוגדר הייתה מצליחה בלי שגיאות וחוזרת לברירת המחדל community, ואימג׳ Business היה יוצא בלי ממשק הניהול שלו. קובץ ה-Compose מעביר את הערך בשבילכם. פקודת docker build שכותבים ידנית צריכה --build-arg VITE_EDITION=community, business או cloud.

מה נקבע בזמן הבנייה ומה לא

שלוש הגדרות של הדפדפן לא נקבעות בזמן הבנייה: כתובת ה-API, כתובת ההתחברות של הדפדפן ומפתח ה-anon. באתחול, הקונטיינר כותב אותן לקובץ /config.js מתוך PUBLIC_URL, FRONTEND_SUPABASE_URL ו-SUPABASE_ANON_KEY, והדפדפן קורא את הקובץ הזה לפני שהאפליקציה עולה. כך האימג׳ שפורסם מגיש את האפליקציה בכל פורט או דומיין אחרי הפעלה מחדש. ארגומנטי הבנייה VITE_* הם רק חלופה לערכי זמן ריצה שלא הוגדרו.

הגדרות דפדפן נוספות שנקבעות בזמן הבנייה:

פרופילי ממשק

המשתנה NODARO_SURFACE_PROFILE מצמצם את הממשק של התקנת Business או Cloud בלי בנייה מחדש. מהדורת Community מתעלמת ממנו ותמיד מציגה את הממשק המלא.

• פורמט. JSON בתוך המשתנה, או @/path/to/profile.json כדי לקרוא קובץ. כדי להשתמש בקובץ במערך השירותים של Compose, מפו אותו לתוך הקונטיינר, וציינו את הנתיב שלו בתוך הקונטיינר.
• רק צמצום. פרופיל יכול להסתיר ולהסיר. הוא אף פעם לא מפעיל משהו שהמהדורה משביתה.
• כל השדות אופציונליים. רשימה ריקה פירושה ״להשאיר את ברירת המחדל״. כשהמשתנה לא מוגדר, ההתקנה מציגה את הממשק המלא.
• שגיאות. שדה פגום מקבל את ברירת המחדל של אותו שדה, עם אזהרה ביומן. פרופיל שלא נטען בכלל מונע מהתקנת Business או Cloud לעלות, עם ההודעה [surface-profile] FATAL … Refusing to boot a narrowing deployment mainline-open (שגיאה קריטית: מסרב לאתחל פריסה מצמצמת כשהיא פתוחה לגמרי). זה קורה עם קובץ שאי אפשר לקרוא, עם JSON לא תקין, או עם ערך שנכשל בבדיקת התקינות כולו. אסור שהתקנה מצמצמת תעלה ותציג הכול.
• החלה. הפעילו מחדש את האפליקציה. הפרופיל מגיע לדפדפן דרך /config.js.

דוגמה

NODARO_SURFACE_PROFILE={"nav":{"hide":["gallery"]},"brand":{"productName":"Studio"},"outputs":{"allowPublic":false},"voice":{"allowedGenders":["male"]}}

הפרופיל הזה מסתיר את הגלריה, משנה את שם המוצר ל-Studio, שומר את כל הפלטים פרטיים ומציע רק קולות גבריים.

שדות

הלוגואים וה-favicon לא חלק מהפרופיל. החליפו אותם בשכבה של קבצים סטטיים באימג׳ ה-Docker שלכם.

אזורים בדף הבית

השדה dashboard.tabs הוא רשימת היתרים סדורה אחת. כל המפתחות האפשריים הם workflows, projects, apps, miniapps, templates, tutorials, statistics, gallery, studio ו-mcp.

• workflows, projects, studio — הרשימות של מסנן סביבות העבודה בלשונית המשך, לפי הסדר ברשימה שלכם. אם הרשימה שלכם לא כוללת אף אחד משלושתם, שלושתם מוצגים, כך שהרשימה הראשית אף פעם לא ריקה.
• apps — רצועת האפליקציות של Nodaro בלשונית המשך.
• templates — השורה התחלה מתבנית בלשונית גילוי, והפריט תבניות בסרגל הצדדי.
• tutorials — המדריכים בחלק לעלות רמה בלשונית גילוי, והפריט מדריכים בסרגל הצדדי. בלי templates ו-tutorials, הלשונית גילוי לא מוצגת.
• miniapps — הפריט מיני־אפליקציות בסרגל הצדדי.
• statistics — סקירת הסטטיסטיקות בדף הרצות.
• mcp — הרשימה הרביעית תחת חזרה לעבודה: התהליכים שלקוח MCP יצר בפרויקט mcp האוטומטי שלו.

כללו ברשימה כל אזור שאתם רוצים להשאיר. למשל, הרשימה ["workflows","projects","statistics","tutorials"] משאירה את רשימות התהליכים והפרויקטים, את המדריכים ואת הסטטיסטיקות. היא משמיטה את רשימת Studio, את רצועת האפליקציות, את שורת התבניות ואת הפריטים תבניות ומיני־אפליקציות בסרגל הצדדי. השדה nav.hide עדיין חל בנוסף לכך.

רשימות היתרים

רשימת היתרים היא הצורה הבטוחה יותר להתקנה שבה התוכן נבחר בקפידה. כך רכיב או מודל חדשים נשארים לא זמינים עד שמוסיפים אותם לרשימה, במקום להופיע רק כי לא חסמתם אותם.

• רכיבי עזר, כגון sticky-note ו-preview, אף פעם לא מוסרים רק כי הם חסרים ברשימת היתרים. רק הסרה מפורשת ב-deny מסירה אותם.
• מנהלים יכולים לשנות בממשק הניהול את הזמינות של רכיבים ומודלים בזמן ריצה. הגדרת זמן ריצה שנשמרה מחליפה את הרשימות של הפרופיל, עד שמאפסים אותה למצב ההתחלתי.
• רכיב שמנהל משבית בממשק הניהול נשאר זמין למנהלים. רכיב שהפרופיל הסיר מוסר גם למנהלים. אבל מנהל שמפעיל שוב בממשק הניהול רכיב שהפרופיל הסיר משחרר אותו לכולם, ולכן תנו את תפקיד המנהל רק לאנשים שאתם סומכים עליהם בעניין הזה.
• מודל מושבת מושבת גם למנהלים.
• הרצה נבדקת לפי המשתמש שבשמו היא רצה. הרצה של אפליקציה או של מצגת רצה בשם מי שמריץ אותה. הרצה מתוזמנת או הרצה שמתחילה מ-Webhook רצה בשם הבעלים של התהליך, ואסימון API או אפליקציה מחוברת פועלים בשם הבעלים שלהם. כשהבעלים הזה הוא מנהל, ההרצה יכולה להשתמש ברכיב שמוסתר ממשתמשים, ולכן התייחסו בזהירות לכתובת ה-Webhook של תהליך כזה.
• אי אפשר לפרסם אפליקציה, רכיב שמור או תבנית שיש בהם רכיב מוסתר: הבקשה נכשלת עם node_not_available.
• שינוי תפקיד מגיע לבדיקות האלה תוך כ-5 דקות.

שיטות התחברות

השדה auth.methods מצמצם את שיטות ההתחברות בדף ההתחברות, מתוך email, google ו-sso. השאירו את sso ברשימה רק יחד עם auth.ssoLabel, הטקסט של כפתור ה-SSO.

רשימה שכוללת רק את sso מפעילה גם כלל בצד השרת: כל חשבון מחובר צריך להיות חשבון שנוצר או קושר דרך SSO. כל סשן אחר נדחה בקריאה הראשונה שלו ל-API עם 403 sso_required, כך שחשבון שנרשם ישירות בשירות ההתחברות לא יכול להשתמש בהתקנה. הוספת email לרשימה משביתה את הכלל. ראו את הדף כניסה מאוחדת (SSO).

מגדרי קולות

השרת אוכף את voice.allowedGenders:

• רשימת הקולות וספריית הקולות המשותפת מציגות רק קולות מהמגדרים המותרים.
• בקשה עם קול מובנה ממגדר אחר נדחית עם voice_not_available.
• כל קול ברירת מחדל וכל קול חלופי הופכים לקול הראשון ממגדר מותר.
• העורך מסתיר ברכיבי Suno את תגיות מגדר הקול של המגדרים האחרים.

אי אפשר לדעת מראש את המגדר של הקול שרכיבי יצירת הקולות יפיקו. כדי להסיר את הרכיבים האלה, הוסיפו "nodes":{"deny":["voice-design","voice-remix"]}.

קטלוגי בוררים

בהתקנות שחייבות להציע רק תוכן בוררים שנבדק, הגדירו "catalogs":{"required":true,"factoryPresets":false}.

• עם required: true, העורך מציע אפשרויות בבוררים רק אחרי שהוא מקבל מהשרת את הקטלוג המלא שנבחר בקפידה, ולא מציע אף אפשרות אם הבקשה הזו נכשלת. רכיבים חדשים ואיפוס לברירות המחדל משתמשים רק בערכים שמוצעים.
• עם factoryPresets: false, הערכות המובנות מוסתרות בעורך וב-API. הערכות שהמשתמשים שמרו בעצמם נשארות.
• השרת גם דוחה אפשרויות שהוצאו מהקטלוג בתהליכים מיובאים או בתהליכים שנשמרו קודם.