মাল্টি-টেন্যান্ট SaaS অনুমতি: সংগঠন, টিম ও রোল স্পষ্ট করা
মাল্টি-টেন্যান্ট SaaS অনুমতি সহজভাবে ব্যাখ্যা: সংগঠন, টিম, রোল ও মালিকানা নীতিসহ নিরাপদভাবে স্কেল করা যায় এমন চেকলিস্ট ও উদাহরণ।
কেন SaaS অনুমতি দ্রুত জটিল হয়ে যায়
অনুমতির সমস্যা সাধারণত ছোট ছোট বিরক্তি হিসেবে শুরু করে। একটি টিকিট আসে: “আমি অ্যাডমিন, কিন্তু ইনভয়েস দেখতে পারছি না।” আরেকটা: “আমার teammate কেন সেটিংস এডিট করতে পারছে?” মানুষ ক্লিক করে, অনুমান করে, এবং অনেক সময় একাধিক লোক একই “owner” লগইন শেয়ার করে কারণ তা ঘন্টা কাটানোর চেয়ে দ্রুত মনে হয়।
তখন ওয়ার্কঅ্যারাউন্ড জমে যায়। টিমগুলো এমন রোল তৈরি করে যেমন “Admin 2” বা “Manager (no delete)”。 ইঞ্জিনিয়াররা এককালীন চেক যোগ করে যেমন “if user is in Sales, allow export” কারণ তা আজকের বাগ ফিক্স করে। এক মাস পরে, কেউই বলতে পারে না কোন নিয়মগুলো উদ্দেশ্যমূলক আর কোনগুলো দুর্ঘটনাজনিত।
আরো খারাপ হয় যখন আপনি আরও কাস্টমার যুক্ত করেন। একটি রুল যা এক কোম্পানির জন্য ঠিক ছিল (“admins can see all data”) তা ভেঙে পড়ে যখন আপনার হাতে শত শত ভিন্ন প্রত্যাশার org আসে। কেউ চাইতে পারেন ডিপার্টমেন্টগুলোর মধ্যে কঠোর পৃথকীকরণ। কেউ চাইতে পারেন শেয়ার করা ওয়ার্কস্পেস। কেউ চাইতে পারেন কন্ট্রাক্টরকে কেবল একটি প্রজেক্টে অ্যাক্সেস দিতে এবং অন্যকিছু নয়। যদি আপনার মডেল স্পষ্ট না হয়, প্রতিটি নতুন কাস্টমার একটি নতুন exception হয়ে ওঠে।
মাল্টি-টেন্যান্ট SaaS অনুমতি: সংগঠন, টিম ও রোল স্পষ্ট করা | Koder.ai
লক্ষ্যটা সহজ: পূর্বানুমেয় অ্যাক্সেস নিয়ম যা এক মিনিটে বোঝানো যায়। উদাহরণ: “আপনার org ডেটার মালিক। টিম লোককে গ্রুপ করে। রোল কাজগুলো নির্ধারণ করে। রিসোর্স একটি org-কে প্রকাশ্যভাবে হার্ডবাইন্ড করে, কখনও কখনও একটি টিমকেও। শেয়ারিং কয়েকটি ডিফল্ট অনুসরণ করে।” যদি আপনি এটা সরলভাবে বলতে না পারেন, তা বানানো, টেস্ট করা এবং বদলানো কঠিন হবে।
একটি রাখা প্রতিশ্রুতি: কম রোল, স্পষ্ট মালিকানা, নিরাপদ ডিফল্ট। বাস্তব কাজের সাথে সংযুক্ত একটি ছোট রোল সেট দিয়ে শুরু করুন, প্রতিটি রিসোর্সের মালিকানা স্পষ্ট রাখুন, এবং ডিফল্ট হিসেবে ন্যূনতম অ্যাক্সেস দিন। তারপর উদ্দেশ্যপ্রণোদিতভাবে শেয়ারিং অনুমতি দিন, দুর্ঘটনায় নয়।
সরল ভাষায় মানচিত্র: সংগঠন, টিম, ইউজার, এবং রিসোর্স
আপনার অ্যাপ যদি একাধিক কাস্টমার সার্ভ করে, নিয়ম লেখার আগে মানসিক মানচিত্র ঠিক করুন। মাল্টি-টেন্যান্ট SaaS অনুমতিতে অধিকাংশ বিভ্রান্তি আসে সংজ্ঞার ভিন্নতায়—একই শব্দ প্রোডাক্টের বিভিন্ন অংশে ভিন্ন অর্থে ব্যবহৃত হয়।
আপনার টেন্যান্ট বাউন্ডারি জন্য একটি অর্থ নির্ধারণ করুন এবং সেটায় আটকে থাকুন। অনেক প্রোডাক্ট “organization” ব্যবহার করে টেন্যান্ট হিসেবে: সমস্ত ডেটা একটি org-এর ভেতর থাকে, এবং স্পষ্টভাবে শেয়ারিং না বানালে কিছুই ওই লাইন পার হয় না।
একটি সহজ শব্দভাণ্ডার যা বড় হলে ও পরিষ্কার থাকবে:
Organization (tenant): কাস্টমার অ্যাকাউন্ট এবং কঠিন ডেটা সীমা।
User (identity): একটি লগইন থাকা ব্যক্তি।
Membership: একটি ইউজার কোন org-এ আছে ও তাদের রোল(গুলি) বলে দেওয়া লিঙ্ক।
Team (ঐচ্ছিক): অর্গের ভেতরে দ্বৈত কাজের গ্রুপিং।
Resource: যা আপনি রক্ষা করতে চান (প্রজেক্ট, ইনভয়েস, টিকিট, API কী)।
"এক ব্যক্তি, বহু org" স্বাভাবিক। একজন কনসালট্যান্ট তিনটি কাস্টমার org-এ থাকতে পারে, প্রতিটিতে ভিন্ন রোল। এজন্যই “user” এবং “membership” আলাদা থাকা উচিত। সাধারণত আপনার চেকগুলো membership-এ নির্ভর করে, user-এ নয়।
টিম তখনই কাজে আসে যখন তা বাস্তব গ্রুপিং প্রতিফলিত করে, যেমন “Support” বা “Finance।” যখন টিম দ্বিতীয় অনুমতি সিস্টেম হয়ে যায় তখন তা গোলযোগ বাড়ায়। একটি সহজ পরীক্ষা: আপনি কি এক বাক্যে টিমটি ব্যাখ্যা করতে পারবেন, কোন নির্দিষ্ট ফিচার রুল উল্লেখ না করে?
উদাহরণ: Maria একবার লগইন করে, তারপর Org A এবং Org B-এর মধ্যে সুইচ করে। Org A-তে তিনি Finance-এ আছেন এবং ইনভয়েস দেখতেও পারেন। Org B-তে তিনি Viewer এবং কেবল প্রজেক্ট পড়তে পারেন। একই ইউজার, ভিন্ন memberships, ধারাবাহিক রিসোর্স টাইপ, স্পষ্ট সীমা।
রোল, অনুমতি, এবং স্কোপ — জার্গন ছাড়া
মাল্টি-টেন্যান্ট SaaS অনুমতি তখনই বোঝার যোগ্য থাকে যখন আপনি তিনটি জিনিস আলাদা রাখেন:
Roles: দায়িত্ব বর্ণনা করা একটি লেবেল।
Permissions: যা কেউ করতে পারে।
Scope: কোথায় তারা তা করতে পারে।
সাধারণ ভাষায় RBAC
RBAC (role-based access control) মানে: আপনি একটি ইউজারকে একটি রোল দেন, এবং সেই রোল অনুমোদিত অ্যাকশনগুলো দেয়। রোলের নামগুলোর মধ্যে দায়িত্ব বর্ণনা থাকা উচিত, অবস্থা নয়। “Billing Admin” স্পষ্ট। “Power User” সাধারণত বিতর্ক তৈরি করে।
Permissions-গুলোকে ক্রিয়াপদের মতো আচরণ করুন এবং প্রোডাক্ট জুড়ে সঙ্গত রাখুন:
View (পড়া)
Create (তৈরি)
Edit (সম্পাদনা)
Delete (মুছা)
Manage (অ্যাস্টার, আমন্ত্রণ, সেটিংস, এক্সপোর্ট ও অন্যান্য বিশেষ কাজ)
তারপর একই ক্রিয়াকে বিভিন্ন জায়গায় প্রযোজ্য করার জন্য scope যোগ করুন। এভাবে আপনি ২০টি একটু ভিন্ন রোল তৈরির ঝামেলা এড়াবেন।
সাধারণ যে স্কোপগুলো পাঠযোগ্য থাকে:
Org-wide
Team-only
Own items
Assigned
কখন ownership আর একটি রোল যোগ করার চেয়ে ভালো
যদি আপনি দেখেন নিজেকে এমন রোল বানাতে — “Project Editor” এবং “Project Editor (Own)” — এটি সাধারণত রোল সমস্যা নয়, বরং স্কোপ সমস্যা।
উদাহরণ: ஒரு CRM-এ, “Sales Rep” কে ডিল তৈরি ও সম্পাদনা করার অনুমতি দিন, কিন্তু স্কোপ সীমাবদ্ধ রাখুন “own items” এ। “Sales Manager” কে একই ক্রিয়াগুলো দিন কিন্তু “team-only” বা “org-wide” স্কোপ সহ। এতে আপনি কম রোল পাবেন, নিয়মগুলো স্পষ্ট থাকবে, এবং কেউ টিম বদলালে অপ্রত্যাশিতা কম হবে।
একটি ভালো ডিফল্ট: রোলগুলো ক্রিয়া দেয়, এবং ownership (বা assignment) ঠিক করে কোথায় সেই ক্রিয়াগুলো কাজ করবে।
একটি সরল নিয়ম সেট যা শত শত org-এ স্কেল করে
যদি আপনার মডেল একটি কাস্টমারের জন্য কাজ করে কিন্তু দশে ভেঙে যায়, সম্ভবত আপনি “কারা দেখবে” ও “কারা করতে পারবে” এবং “কে মালিক” একত্র মিশিয়ে ফেলেছেন। এগুলো আলাদা রাখুন, সিস্টেমটা পূর্বানুমেয় থাকবে।
একটি নিয়ম সেট যা স্কেল করে:
প্রতিটি রেকর্ডের (প্রজেক্ট, ইনভয়েস, টিকিট, API কী) একটিমাত্র হোম organization থাকে।
একজন ব্যবহারকারী কেবল তাদের সক্রিয় সদস্যপদ থাকা org-এর ডেটাই দেখতে পাবে। তারা যদি সদস্য না হয়, UI ও API-তে সেই org যেনই নেই তেমন আচরণ করা উচিত।
রোলগুলো ক্রিয়াগুলো নিয়ন্ত্রণ করে (তৈরি, সম্পাদনা, মুছা, এক্সপোর্ট), কিন্তু শুধুমাত্র ঐ org-এর ভিতর যেখানে ব্যবহারকারী ইতিমধ্যেই দেখতে পারে।
মালিকানা একটি টাই-ব্রেকার হিসেবে কাজ করে। এটি অনুমতি সীমার ভিতরে অতিরিক্ত অধিকার দিতে পারে (আপনার ড্রাফট সম্পাদনা করা, আপনার নিজের API টোকেন ম্যানেজ করা) তবে অন্য ডেটায় অ্যাক্সেস বাড়াবে না।
অ্যাডমিন অ্যাক্সেস একটি সংকীর্ণ, স্পষ্ট ব্যতিক্রম। “অ্যাডমিন” কি করতে পারবে তা নির্ধারণ করুন এবং অ্যাডমিন-লেভেল রোলগুলো কম রাখুন।
উদাহরণ: Sam Org A এবং Org B-এ সদস্য। Org A-তে Sam একজন Member এবং নিজের রিপোর্ট তৈরি ও সম্পাদনা করতে পারে কিন্তু বিলিং পরিবর্তন করতে পারে না। Org B-তে Sam একজন Billing Manager এবং পেমেন্ট পদ্ধতি আপডেট ও ইনভয়েস ডাউনলোড করতে পারে, কিন্তু তখনও ব্যক্তিগত বা প্রাইভেট প্রজেক্ট দেখতে পারবে না যদি তাদের সদস্যপদ সেই ক্ষেত্র অন্তর্ভুক্ত না করে।
এতে বৃদ্ধি একধরনের ‘বোরিং’ হয়ে যায় — ভাল অর্থে। একটি নতুন org যোগ করা মানে কেবল membership ও রোল যোগ করা। মূল নিয়মগুলো একই থাকে।
ধাপে ধাপে: এক পাতায় আপনার পারমিশন মডেল ডিজাইন করুন
একটি পৃষ্ঠার নথি লিখুন যা একজন সহকর্মী দুই মিনিটে পড়ে বুঝতে পারে। যদি আপনি কোড না খুলেই পারমিশন ব্যাখ্যা করতে পারেন, আপনি ভালো পথে আছেন।
1) নিয়ম লেখার আগে ইনপুটগুলো লিখুন
এগুলোকে সীমিত রাখুন:
চারটি ইউজার টাইপ বেছে নিন যা আপনি সহজে ব্যাখ্যা করতে পারবেন: মালিক (Owner), অ্যাডমিন (Admin), সদস্য (Member), দর্শক (Viewer)।
প্রতিটি রিসোর্সের জন্য ২–৪টি অ্যাকশন তালিকা করুন (view, create, edit, delete, invite, export)।
সিদ্ধান্ত নিন নতুন সদস্য ডিফল্টে কী পায় (সাধারণত viewer বা member, অ্যাডমিন নয়)।
সিদ্ধান্ত নিন “টিম” কী পরিবর্তন করে। এটা visibility, assignment, reporting-এ সীমাবদ্ধ রাখুন — অবাক করা ক্ষমতায় নয়।
2) নিয়মগুলো একটি সরল টেবিলে রাখুন
স্কোপ ব্যবহার করে রোল বিস্তার এড়ান। অনেক প্রোডাক্টে মাত্র তিনটি স্কোপই লাগে: own, team, org।
Role
View
Edit
Invite users
Billing
Scope note
মালিক (Owner)
Yes
Yes
Yes
Yes
Org-wide, মালিকানা ট্রান্সফার করতে পারে
অ্যাডমিন (Admin)
Yes
Yes
Yes
No/Yes
Org-wide, মালিকানা পরিবর্তন নয়
সদস্য (Member)
Yes
Limited
No
No
Own + team (যেখানে অ্যাসাইন করা)
দর্শক (Viewer)
Yes
No
No
No
Read-only নির্দিষ্ট স্কোপে
স্যানিটি চেক: এই পেজটা একজন নন-টেক সহকর্মীর কাছে দেখান এবং জিজ্ঞেস করুন, “একজন Support সদস্য কি Sales রিপোর্ট এডিট করতে পারে?” যদি তারা হেজিটেট করে, আপনার স্কোপ বা টিম সংজ্ঞা স্পষ্ট নয়।
রিসোর্স মালিকানা ও শেয়ারিং নিয়ম যা সুস্থ থাকে
পারমিশন বোঝার যোগ্য রাখতে, প্রতিটি রিসোর্সের মালিক কে তা নির্ধারণ করুন, তারপর শেয়ারিং অপশনগুলো সীমিত রাখুন।
ডিফল্ট মালিকানা মডেল
অধিকাংশ রিসোর্সকে org-ওয়ান করা উচিত। কাস্টমাররা সাধারণত কোম্পানি হিসেবে চিন্তা করে: ইনভয়েস, প্রজেক্ট, কন্টাক্ট, টিকিট এবং অটোমেশনগুলো সংগঠনের মালিকানা — ব্যক্তির নয়।
টিম এখনও দরকারি হতে পারে, কিন্তু টিমকে একটি ওয়ার্কফ্লো লেবেল হিসেবে বিবেচনা করুন — রুটিং ও ভিজিবিলিটি ডিফল্ট ঠিক করতে, কঠিন নিরাপত্তা লজিক হিসেবে নয়। একটি টিম ট্যাগ ফিল্টার, ড্যাশবোর্ড, নোটিফিকেশন বা কিউ চালাতে পারে, এমনকি যখন অ্যাক্সেস রোল ও স্কোপ থেকে আসে।
ইউজার-ওয়ান রিসোর্সগুলো ব্যতিক্রম হওয়া উচিত: ড্রাফট, ব্যক্তিগত নোট, সেভড ভিউ, API টোকেন, বা ব্যক্তিগত সেটিংস — যেগুলো সত্যিই ব্যক্তিগত। কেউ বেরিয়ে গেলে কি হবে সেটাও নির্ধারণ করুন: মুছে ফেলা হবে, ট্রান্সফার করা হবে, না রেখে দেওয়া হবে?
শেয়ারিং নিয়মের একটি ছোট সেট যা পাঠযোগ্য থাকে:
ডিফল্টভাবে Org-owned: আইটেমগুলো একটি organization ID এর অধীনে সংরক্ষণ করুন।
ওয়ার্কফ্লো জন্য Team-tagged: একটি টিমের কাছে রুটিং করার জন্য ট্যাগ দিন, কঠোর অ্যাক্সেস কন্ট্রোল নয়।
ব্যক্তিগত আইটেম User-owned: স্বাভাবিকভাবে প্রাইভেট, যদি স্পষ্টভাবে শেয়ার করা না হয়।
শেয়ারিং মাত্রা শুধুমাত্র: Private (owner), Team, Org। প্রথম দিকে কাস্টম per-item ACL এড়িয়ে চলুন।
“Assigned to” আলাদা রাখুন “can access” থেকে: অ্যাসাইনমেন্ট দায়িত্ব দেখায়, অনুমতি নয়।
সহজ রাখা শেয়ারিং
যখন কেউ বলে “আমাকে অ্যাক্সেস দরকার,” জোর দিন যে কোন লেভেল: তাদের ব্যক্তিগত আইটেম, তাদের টিমের কাজ, না পুরো org। যদি তিনটোর মধ্যে না পড়ে, সাধারণত সেটা নির্দেশ করে আপনার স্কোপ অস্পষ্ট, নতুন শেয়ারিং মোড দরকার নয়।
উদাহরণ: একটি সাপোর্ট টিকিট org-owned হতে পারে (যাতে ম্যানেজাররা সব টিকিট রিপোর্ট করতে পারে), Support টিম-ট্যাগ থাকতে পারে (যাতে এটি সঠিক কিউতে দেখায়), এবং Jordan-কে অ্যাসাইন করা থাকতে পারে (প্রস্তুতিমূলকভাবে Jordan দায়িত্বশীল)। অ্যাসাইনমেন্ট অন্য অনুমোদিত রোলগুলোকে দেখার থেকে বাধা দেয় না।
আমন্ত্রণ, সদস্যপদ পরিবর্তন, এবং org সুইচ করা
অনুমতি প্রায়ই “মানুষ ইভেন্ট”-এ ভাঙ্গে: কাউকে আমন্ত্রণ করা, টিম বদলানো, বা অ্যাক্সেস সরিয়ে ফেলা। এই ফ্লোগুলোই নির্ধারণ করে আপনার মডেল পূর্বানুমেয় থাকে কি না।
আমন্ত্রণ
আমন্ত্রণকে একটি সদস্যপদ তৈরি করার অনুরোধ হিসেবে আচরণ করুন, নিজে থেকেই অ্যাক্সেস নয়। আমন্ত্রণে থাকা উচিত স্পষ্ট: org, টিম (ঐচ্ছিক), এবং রোল যা স্বীকার করলে দেওয়া হবে।
নিয়ম কঠোর রাখুন:
কেবল নির্দিষ্ট রোলই আমন্ত্রণ দিতে পারবে (উদাহরণ: Owner এবং Admin)। যদি আপনি টিম লিড সাপোর্ট করেন, তাদের সীমাবদ্ধ রাখুন শুধু তাদের নিজস্ব টিমে আমন্ত্রণ দেওয়ার জন্য।
আমন্ত্রণকারী কেবল তাদের নিজের লেভেল বা তার নীচের রোলই দিতে পারবে।
মেয়াদোত্তীর্ণ আমন্ত্রণ কিছুই করে না।
যদি ইমেইলটি ইতিমধ্যেই একটি অ্যাকাউন্টে যুক্ত থাকে, স্বীকৃতি সেই অ্যাকাউন্টটিকে org-এ লিঙ্ক করবে। না থাকলে, স্বীকার করলে অ্যাকাউন্ট তৈরি করে তারপর সংযুক্ত করবে।
অস্থায়ী অ্যাক্সেসও এখানে ফিট করে। “টেম্প ইউজার” রোল বানানোর বদলে, রোল গ্রান্টকে একটি শেষ দিনের তারিখ দেবার অপশন দিন। যখন তা আসে, অ্যাক্সেস аўটোমেটিক্যালি বাদ পড়বে এবং অডিট ট্রেইল পরিষ্কার থাকবে।
###Leaving/Join এবং মালিকানা না হারানো
যখন কেউ org ছেড়ে যায়, তাদের রিসোর্স নিয়ে অনুমান করবেন না। যদি আপনার নিয়ম “রিসোর্স org-owned” হয়, সেটাতেই লেগে থাকুন। ব্যক্তিটি ইতিহাসে কেবল ক্রিয়েটর হিসেবে থাকতে পারেন, কিন্তু org মালিক থাকা উচিত।
যদি আপনার কাছে ইউজার-ওয়ান রিসোর্স থাকে, সংবেদনশীল কিছুর জন্য অপসারণের আগে ট্রান্সফার বাধ্যতামূলক করুন (প্রজেক্ট, ডকুমেন্ট, API কী)।
নিরাপদে org সুইচ করা
একই লগইন বহু org-এ থাকতে পারে, কিন্তু অ্যাপে সবসময় একটি “কারেন্ট org” থাকতে হবে। UI-তে এটা স্পষ্ট করুন এবং প্রতিটি অ্যাকশনকে সেটির মধ্যে স্কোপ করুন।
ডিএক্টিভেশন সাধারণত ডিলিশনের চেয়ে ভালো। এটি এখনই অ্যাক্সেস বাদ দেয় এবং অতীত কার্যকলাপ অডিটেবল রাখে।
সাধারণ ভুল এবং ফাঁদ যা এড়াতে হবে
অধিকাংশ পারমিশন মডেল ব্যর্থ হয় কারণ তারা নিয়মের চেয়ে দ্রুত বেড়ে যায়। বুনিয়াদি রক্ষা করুন (tenant boundary, ownership, scope) এবং বাকিটা বিস্তারিত হিসেবে বিবেচনা করুন।
Role explosion ক্লাসিক ফাঁদ। একটি এজ কেস দেখলে আপনি নতুন রোল তৈরি করেন পরিবর্তে একটি স্পষ্ট পারমিশন বা স্কোপ রাখার। কয়েক মাস পর, কেউ জানে না “Manager Plus” মানে কি। যদি একটি বিশেষ কেস প্রায়ই লাগে, এটাকে প্রথম-শ্রেণীর পারমিশন বানান। যদি খুব ব্যতিক্রমী, অস্থায়ী গ্রান্ট দিয়ে হ্যান্ডেল করুন যা মেয়াদ শেষ হলে উঠে যায়।
Permission drift চুপচাপ কিন্তু খারাপ। কেউ “একটি ব্যতিক্রম” যোগ করে এবং একে ভুলে যায়। এক বছর পরে, লিখিত নীতি ও বাস্তব সিস্টেম ভিন্ন হয়ে পড়ে। নীতি প্রথমে আপডেট করুন, তারপর ইমপ্লেমেন্ট করুন।
Teams কে ভুয়া নিরাপত্তা সীমা বানানো নিয়মিত বিভ্রান্তি তৈরি করে। যদি রিসোর্সগুলো org-এর ভিতরে টিমগুলোর মধ্যে শেয়ার হতে পারে, সেটি স্পষ্টভাবে বলুন। না পারলে, কোডে জোর দিন, নামকরণে নয়।
শুরুতেই ধরা পড়বার সংকেত:
এমন একটি “super admin” আছে যা ডিফল্টভাবে সব কাস্টমার org-এর ডেটা দেখতে পারে
UI-এ শুধু বোতাম লুকানো (hidden buttons) কিন্তু সার্ভার-সাইড চেক নেই
API কী ও সার্ভিস অ্যাকাউন্ট যেগুলো সদস্যপদ নিয়ম বাইপাস করে
রোলগুলো চাকরীর শিরোনাম দ্বারা সংজ্ঞায়িত, কাজ নয়
এক বাক্যে ব্যাখ্যা করা যায় না এমন exceptions
সাপোর্টকে সাহায্য করতে গেলে “তাদেরকে গ্লোবাল অ্যাডমিন দিন এক মিনিটের জন্য” একটি tenant leak হওয়ার অপেক্ষায়। স্পষ্ট, লগ করা অ্যাক্সেস পছন্দ করুন যার কঠোর স্কোপ (এক org, নির্দিষ্ট সময়, নির্দিষ্ট অ্যাকশন)।
শিপ করার আগে দ্রুত চেকলিস্ট
প্রতি অনুরোধে প্রথমে সক্রিয় organization রেজল্ভ করুন (subdomain, header, session, বা route থেকে) এবং যা ম্যাচ করে না তা reject করুন।
org context-র পরে চেকগুলো একটি নির্দিষ্ট ক্রমে রাখুন: প্রথমে membership (তারা কি এই org-এর সদস্য?), তারপর role (এই org-এ তারা কি করতে পারে?), তারপর ownership বা sharing (এই রেকর্ডে তাদের কি অ্যাক্সেস আছে?)। যদি ownership চেক membership-এর আগে করেন, আপনি বিদ্যমান কী আছে তা সম্পর্কে তথ্য লিক করতে পারেন।
কিছু ইন্ড-টু-ইন্ড টেস্ট চালান বাস্তব অ্যাকাউন্ট ব্যবহার করে, শুধু ইউনিট টেস্ট নয়:
একদম নতুন সদস্য চেষ্টা করে দেখুক view, create, এবং export
টিম লিড চেষ্টা করে তাদের টিম মাত্রই ম্যানেজ করতে, পুরো org নয়
org admin রোল পরিবর্তন করে তারপর সংবেদনশীল অ্যাকশন চেষ্টা করে (delete, export)
অপসারিত ইউজার একটি পুরনো ট্যাব রেখে দিলে পুনরায় চেষ্টা করে
আমন্ত্রিত (না-স্বীকারকৃত) ইউজার পুরনো ইনভাইট লিংক ব্যবহার করে অ্যাক্সেস চেষ্টা করে
সেন্সিটিভ কাজগুলোর জন্য বেসিক অডিট ইভেন্ট যোগ করুন: রোল পরিবর্তন, সদস্যপদ অপসারণ, এক্সপোর্ট, ডিলেট, সেটিংস আপডেট। ডে-ওয়ান-এ পারফেক্ট থাকার দরকার নেই, কিন্তু “কে কী করলো, কখন” উত্তর দিতে পারবে।
ডিফল্টগুলো রিভিউ করুন। নতুন org ও নতুন সদস্যদের শুরুতেই ন্যূনতম অ্যাক্সেস দিন যা এখনও তাদের সফল হতে দেয়। সাপোর্ট ও সেলসের জন্য একটি ছোট ইনটার্নাল পারমিশন FAQ থাকাও সাহায্য করে, উদাহরণ: “একজন টিম লিড কি অন্য টিম দেখতে পারে?” এবং “কোনো ব্যবহারকারী অপসারণের পর কি হয়?”
উদাহরণ: এক org থেকে শত শত org পর্যন্ত পুনর্নির্মাণ ছাড়া
একটি ছোট, বাস্তব সেটআপ দিয়ে শুরু করুন: একটি কাস্টমার কোম্পানি (এক org) দুইটি টিম সহ, Sales এবং Ops। সবাই একবার সাইন-ইন করে এবং তারপর তারা কোন org-এ আছে সেটা বেছে নেয়। Sales কে কাস্টমার রেকর্ড ও কোটস দরকার। Ops-কে বিলিং ও ইন্টারনাল সেটিংস দরকার।
স্টেজ ১: এক org, দুই টিম
টিমগুলোকে গ্রুপিং ও ওয়ার্কফ্লো হিসেবে রাখুন, প্রধান অনুমতি সুইচ হিসেবে নয়। তারা ডিফল্ট ও রুটিং প্রভাব ফেলতে পারে, কিন্তু একমাত্র গেট হতে দেয়া উচিত নয়।
স্টেজ ২: স্থিতিশীল রোল, পূর্বানুমেয় স্কোপ
একটি ছোট রোল সেট বেছে নিন এবং ফিচার আসলেও সেগুলো স্থির রাখুন: Admin, Member, Viewer। রোলের উত্তরটি: “এই org-এ তুমি কি করতে পারো?” স্কোপ উত্তরটি: “কোথায় তুমি তা করতে পারো?”
স্টেজ ৩: মালিকানা এডিটিং সিদ্ধান্ত সহজ করে
একটি মালিকানা নিয়ম যোগ করুন: প্রতিটি রিসোর্সের একটি org এবং একটি owner (প্রায়ই ক্রিয়েটর) থাকে। এডিট করা যাবে যদি তুমি Admin হও বা যদি তুমি owner হও এবং তোমার রোলে “edit own” থাকে। দেখা যাবে যদি তোমার রোলে “view” থাকে সেই রিসোর্স টাইপের জন্য।
উদাহরণ: একজন Sales Member একটি কোট তৈরি করে। অন্য একজন Sales Member সেটা দেখতে পারে, কিন্তু তখনই এডিট করতে পারবে যদি সেটা টিমের সাথে শেয়ার করা হয় বা reassigned করা হয়। একটি Ops Viewer কেবল তখনই দেখতে পারবে যদি আপনার নিয়ম Ops-কে Sales রিসোর্স দেখার অনুমতি দেয়।
স্টেজ ৪: ২০০ org, একই নিয়ম
আপনি যখন ২০০ কাস্টমার org অনবোর্ড করবেন, আপনি একই রোল ও একই মালিকানা নিয়ম পুনরায় ব্যবহার করবেন। আপনি membership পরিবর্তন করবেন, মডেল নয়।
সাপোর্ট রিকুয়েস্টগুলোর উত্তর এখন একটি চেকলিস্ট হয়ে যাবে: org ও রিসোর্স নিশ্চিত করুন, ব্যবহারকারীর রোল সেই org-এ চেক করুন, মালিকানা ও শেয়ারিং চেক করুন, তারপর রোল বদলান বা রিসোর্স শেয়ার করুন। এক-অফ exception এড়িয়ে চলুন এবং অডিট নোট রাখুন।
পরবর্তী ধাপ: নিরাপদে ইমপ্লিমেন্ট, টেস্ট, এবং ইটারেট করুন
আপনার এক-পেজ মডেলকে একটি কন্ট্র্যাক্ট হিসেবে দেখুন। কেবল সেই নিয়মগুলো ইমপ্লিমেন্ট করুন যেগুলো আপনি প্রতিটি API কল ও প্রতিটি UI স্ক্রিনে পূরণ করতে পারবেন, নচেৎ পারমিশন “it depends” হয়ে যাবে।
ছোটে শুরু করুন: কয়েকটি রোল, স্পষ্ট স্কোপ, এবং সরল মালিকানা। যখন একটি নতুন অনুরোধ আসে (“Can we add an Editor-Manager role?”), প্রথমে ownership বা scope কঠোর করুন। নতুন রোল বিরল হওয়া উচিত।
প্রতিটি নতুন রিসোর্সের জন্য মূলগুলো সঙ্গত রাখুন:
org_id সংরক্ষণ করে (এবং প্রয়োজনে team_id)
একটি ভিজিবিলিটি রুল আছে (private, team, org)
সংবেদনশীল অ্যাকশনের জন্য অডিট ইভেন্ট রেকর্ড করে (invite, role change, export)
প্রতিটি কুয়েরিতে স্কোপ দ্বারা ফিল্টার করা হয় (শুধু UI-তে নয়)
প্রত্যাশিত ডিফল্ট আছে (তৈরির পর কে এটা দেখতে পারবে)
প্রান্তিক কেসগুলোতে পলিশ করার আগে বাস্তব ফ্লো গুলো টেস্ট করুন: আমন্ত্রণ, org সুইচ, অ্যাডমিন পেজ, এবং কেউ মাঝখানে অ্যাক্সেস হারালে কি হয় তা পরীক্ষা করুন।
যদি আপনি একটি চ্যাট-ভিত্তিক অ্যাপ বিল্ডার দিয়ে তৈরি করছেন, প্রথমে পারমিশন মডেলটি সহজ ভাষায় লিখে প্রোডাক্ট স্পেসের পাশে রাখলে সাহায্য করে। Koder.ai (koder.ai)-এ Planning Mode প্লাস স্ন্যাপশট ও রোলব্যাক এগুলো ট্রায়াল করার এবং নিশ্চিত করার ব্যবহারিক উপায় হতে পারে যে নিয়মগুলো ওয়েব, ব্যাকএন্ড এবং মোবাইলে একইভাবে কাজ করছে।
