অভ্যন্তরীণ টুলের জন্য অনুমতি ম্যাট্রিক্স ডিজাইন: ভূমিকা ও স্কোপ

কোন সমস্যা সমাধান করে একটি অনুমতি ম্যাট্রিক্স

অভ্যন্তরীণ টুল আপনার টিমের দৈনন্দিন ব্যবসা চালানোর সফটওয়্যার—অ্যাডমিন প্যানেল, অপারেশন ড্যাশবোর্ড, সাপোর্ট কনসোল, ফাইন্যান্স রিভিউ স্ক্রীন কিংবা ছোট অ্যাপগুলো যেখানে মানুষ কাজ অনুমোদন করে, ডেটা ঠিক করে বা গ্রাহকদের সাড়া দেয়।

এই টুলগুলো সংবেদনশীল ডেটা এবং শক্তিশালী অ্যাকশন স্পর্শ করে। একজন সাপোর্ট এজেন্ট গ্রাহকের প্রোফাইল দেখতে পারে কিন্তু পুরো পেমেন্ট বিবরণ কখনই দেখতে পারবে না। একজন ফাইন্যান্স ব্যবহারকারী ইনভয়েস এক্সপোর্ট করতে পারে কিন্তু অ্যাকাউন্ট সেটিংস এডিট করতে পারবে না। একজন অপস লিড উভয়ই করতে পারে, কিন্তু শুধুমাত্র তাদের অঞ্চলের জন্য।

অনুমতিগুলো দ্রুত জটিল হয়ে যায় কারণ অভ্যন্তরীণ টুলগুলো স্তরে স্তরে বাড়ে। নতুন ভূমিকা আসে, পুরনো ভূমিকা ভাগ হয়ে যায়, এবং এক-অফ ব্যতিক্রম জমা হয়ে যায়: “মারিয়াকে রিফান্ড দেয়া হবে”, “কন্ট্রাকটরদের নোট থেকে ব্লক কর”, “টিম লিডরা শুধুমাত্র $500 পর্যন্ত অনুমোদন দিতে পারবে।” যখন নিয়মগুলো কেবল মানুষের মাথায় (বা ছড়িয়ে থাকা টিকিটে) থাকে, তখন স্ক্রীন এবং API এন্ডপয়েন্ট মিলভাঙে এবং নিরাপত্তার ফাঁক দেখা যায়।

একটি অনুমতি ম্যাট্রিক্স ডিজাইন এটি ফিক্স করে: কে কী করতে পারে, কোন ডেটার ওপর, এবং কোন সীমার মধ্যে — একক, শেয়ার করা মানচিত্র তৈরি করে। এটি UI (কোন স্ক্রিন, বোতাম, ফিল্ড দেখা উচিত) ও ব্যাকএন্ড (সার্ভার আসলেই কি অনুমতি দেয়, এমনকি কেউ UI বাইপাস করার চেষ্টাই করলে) উভয়ের জন্য ট্রুথ সোর্স হয়ে যায়।

এটি কেবল ডেভেলপারদের জন্য নয়। একটি ভালো ম্যাট্রিক্স হলো কাজ করা দলিল যা প্রোডাক্ট, অপারেশনস এবং নির্মাতারা একসঙ্গে সম্মত হতে পারে। আপনি যদি AppMaster-এর মতো কোনো নো-কোড প্ল্যাটফর্মে নির্মাণ করেন, তবুও ম্যাট্রিক্স অপরিহার্য: এটি নির্দেশ করে কিভাবে ভূমিকা সেট করবেন, রিসোর্স সংজ্ঞায়িত করবেন এবং ভিজ্যুয়াল স্ক্রীন ও জেনারেটেড এন্ডপয়েন্ট সঙ্গত রাখবেন।

একটি সাধারণ ম্যাট্রিক্স আপনাকে সাহায্য করে:

• নির্মাণের আগে নিয়মগুলো স্পষ্ট করা
• “বিশেষ কেস” বিশৃঙ্খলা কমানো
• UI এবং API অনুমতিগুলো সায় করে রাখা
• অনুমতি পরিবর্তন রিভিউ করা সহজ করা

কী শর্ত: ভূমিকা, রিসোর্স, অ্যাকশন, স্কোপ, ব্যতিক্রম

ভাল অনুমতি ম্যাট্রিক্স ডিজাইন শুরু হয় মতবাদগত শব্দ থেকে। যদি আপনার টিম এগুলো একই অর্থে ব্যবহার করে, আপনি পরে জটিল নিয়মগুলো এড়াতে পারবেন।

একটি ভূমিকা (role) হলো কাজ-ভিত্তিক মানুষের গ্রুপ যারা সাধারণত একই অ্যাক্সেস চায়। ভাবুন Support, Finance, Ops, বা Manager। ভূমিকা উচিত কারো প্রতিদিনের কাজ বর্ণনা করা — তাদের সিনিয়রিটি নয়। একজন ব্যক্তি একাধিক ভূমিকা পেতে পারে, কিন্তু সেটা বিরল রাখুন।

একটি রিসোর্স হলো আপনি যা রক্ষা করছেন। অভ্যন্তরীণ টুলে সাধারণ রিসোর্সগুলো হলো customers, tickets, invoices, reports, integrations, এবং settings। রিসোর্সগুলোকে নাম দিন নাউন দিয়ে — পরে এই নামগুলো স্ক্রিন ও API এন্ডপয়েন্টে রূপান্তর করা সহজ হয়।

একটি অ্যাকশন হলো কেউ রিসোর্সে কি করতে পারে। ক্রিয়াপদগুলোকে সঙ্গত রাখুন যাতে ম্যাট্রিক্স পড়তে সহজ থাকে। সাধারণ অ্যাকশনের উদাহরণ:

• view
• create
• edit
• delete
• approve
• export

একটি স্কোপ জবাব দেয় “কোন রেকর্ডগুলো?” — নতুন ভূমিকা তৈরি না করেই। স্কোপ প্রায়ই নিরাপদ ও অস্বস্তিকর অ্যাক্সেসের মধ্যে পার্থক্য করে। সাধারণ স্কোপগুলো:

• own (আপনি তৈরি বা অ্যাসাইন করা রেকর্ড)
• team (আপনার গ্রুপ)
• region (আপনার এলাকা)
• all (সবকিছু)

একটি ব্যতিক্রম হলো এমন ওভাররাইড যা সাধারণ ভূমিকা ও স্কোপ নিয়ম ভাঙে। ব্যতিক্রমগুলো হতে পারে অস্থায়ী (শিফট কভার করা), ব্যবহারকারী-নির্দিষ্ট (একজন বিশেষজ্ঞকে অতি প্রয়োজনীয় একশন দেওয়া), বা রেকর্ড-নির্দিষ্ট (একজন VIP গ্রাহকের রেকর্ড লক করা)। ব্যতিক্রমকে নিয়ন্ত্রিত দায় (controlled debt) হিসেবে বিবেচনা করুন: কে অনুমোদন করেছে, কেন দরকার, এবং কখন শেষ হবে তা ট্র্যাক করুন।

উদাহরণ: একটি Support এজেন্ট টিকিট “view” করতে পারে স্কোপ “team” দিয়ে, কিন্তু একটি ইন্টারভিউর জন্য অল্প সময়ের জন্য টিকিট “export” করার ব্যতিক্রম পেতে পারে। AppMaster-এ নির্মাণ করলে এই ধরনের নিয়ম রক্ষণাবেক্ষণ করা অনেক সহজ হয় যদি আপনি শুরুতেই ভূমিকা, রিসোর্স, অ্যাকশন ও স্কোপগুলো ধারাবাহিকভাবে নামকরণ করেন।

ম্যাট্রিক্স আঁকার আগে সিদ্ধান্ত নিতে হবে কি কি

শুরু করুন কি আপনি আসলেই রক্ষা করছেন তা নিয়ে একমত হওয়ায়। অভ্যন্তরীণ টুলের ক্ষেত্রগুলোকে রিসোর্স হিসেবে তালিকা করুন, না যে স্ক্রিনগুলো। একটি স্ক্রিন হতে পারে “Orders”, “Refunds” এবং “Customers” একসাথে দেখায়, কিন্তু এগুলো আলাদা রিসোর্স এবং আলাদা ঝুঁকি আছে।

একটি অনুমতি লেখার আগে আপনার অ্যাকশন ক্রিয়াপদগুলো মানক করুন। ছোট শব্দের পার্থক্য পরে ডুপ্লিকেট রুল তৈরি করে (edit বনাম update, remove বনাম delete, view বনাম read)। একটি সংক্ষিপ্ত, শেয়ার করা সেট বেছে নিন এবং প্রতিটি রিসোর্স জুড়ে এটিকে অনুসরণ করুন। অধিকাংশ অভ্যন্তরীণ টুলে view, create, update, delete, approve, export একটি সহজ পর্যাপ্ত সেট।

স্কোপ হলো পরবর্তী সিদ্ধান্ত, এবং এটি আপনার কোম্পানি যেভাবে ভাবছে তার সাথে মেলে। অনেক স্কোপ হলে ম্যাট্রিক্স পড়তে কঠিন হবে; খুব কম হলে বারবার ব্যতিক্রম তৈরি হবে। একটি ছোট সেট লক্ষ্য করুন যা আপনার সংস্থার কাঠামোর সাথে মিলবে, যেমন:

• own (আপনি তৈরি করা রেকর্ড)
• team (আপনার টিমের রেকর্ড)
• location (শাখা বা অঞ্চল)
• all (সবকিছু)
• none (অ্যাক্সেস নেই)

আপনি “no” এর জন্য পরিষ্কার নিয়মও দরকার। কি স্পষ্টভাবে নিষিদ্ধ আর কি প্রাত্যহিকভাবে অস্বীকৃত তা ঠিক করুন। implicit deny (যা তালিকাভুক্ত নেই তা অস্বীকার) নিরাপদ এবং সহজ। explicit forbid দরকার যখন আপনার বিস্তৃত অ্যাক্সেস আছে কিন্তু একটি নির্দিষ্ট অ্যাকশন ব্লক করতে চান, উদাহরণ “Finance সব ইনভয়েস অ্যাক্সেস করতে পারে কিন্তু delete করতে পারবে না”।

শেষে, কপাল-সংবেদনশীল অ্যাকশনগুলো আগে ফ্ল্যাগ করুন, যখনও তারা গ্রিডে ডুবিয়ে না যায়। এক্সপোর্ট, ডিলিট, পেআউট, ভূমিকা বদলানো, ব্যক্তিগত ডেটা অ্যাক্সেস—এসব অতিরিক্ত নজর, লগিং এবং প্রায়ই অনুমোদন ধাপ দাবী করে। উদাহরণ: Support lead কাস্টমার প্রোফাইল আপডেট করতে পারে, কিন্তু পেআউট তৈরি বা এক্সপোর্টের আগে ফাইন্যান্স অনুমোদন লাগতে পারে।

আপনি যদি AppMaster-এ নির্মাণ করেন, এই সিদ্ধান্তগুলো পরে ব্যাকএন্ড এন্ডপয়েন্ট ও Business Process লজিকে সোজাভাবে ম্যাপ হয়, কিন্তু ম্যাট্রিক্সটা স্পষ্ট হতে হবে আগে।

ধাপে ধাপে: শূন্য থেকে অনুমতি ম্যাট্রিক্স বানানো

কাজের শুরুতেই মানুষ কী কাজ করে সেটা নিয়ে শুরু করুন, না যে স্ক্রিন আপনি বানাবেন তা নিয়ে। স্ক্রিন থেকে শুরু করলে আপনি আজকের UI কপি করে ফেলবেন এবং যে আসল নিয়মগুলো আছে (কোনো রিফান্ড কে অনুমোদন করতে পারে, বা কখন গ্রাহক রেকর্ড লক হয়ে গেলে কারা এডিট করতে পারে) তা মিস করবেন।

একটি সহজ উপায় হলো অনুমতি ম্যাট্রিক্স ডিজাইনকে কাজ থেকে অ্যাক্সেসে মানচিত্র হিসেবে দেখা, এবং পরে তা আপনার অ্যাপে রূপান্তর করা।

একটা ব্যবহারিক বিল্ড অর্ডার

1. ব্যবসায়িক কাজগুলো সাধারণ ভাষায় তালিকা করুন। উদাহরণ: “Issue a refund”, “Change a customer’s email”, “Export invoices for last month”. সংক্ষিপ্ত ও বাস্তব রাখুন।

2. কাজগুলোকে রিসোর্স ও অ্যাকশনে পরিনত করুন। রিসোর্সগুলো নাউন (Invoice, Ticket, Customer), অ্যাকশনগুলো ভেবস (view, create, edit, approve, export)। প্রতিটি রিসোর্সের জন্য একটি ম্যালিক নির্ধারণ করুন: একজন ব্যক্তি যিনি এজ কেসগুলো ব্যাখ্যা করতে পারেন এবং বলেন “হ্যাঁ, এটা সঠিক”।

3. স্থিতিশীল টিমের ভিত্তিতে ভূমিকা সংজ্ঞায়িত করুন। Support, Finance, Operations, Team Lead-এর মত গ্রুপ ব্যবহার করুন। যেসব টাইটেল ঘনঘন বদলে যায় (Senior, Junior) সেগুলো ব্যবহার না করাই ভালো যদি না সত্যিই অ্যাক্সেস পরিবর্তিত হয়।

4. ম্যাট্রিক্সটি পূরণ করুন প্রতিটি ভূমিকার জন্য তাদের কাজ সম্পাদনের ন্যূনতম অ্যাক্সেস দিয়ে। যদি Support শুধুমাত্র ইনভয়েস দেখতে লাগে প্রশ্নের উত্তর দিতে, তাহলে ডিফল্টভাবে “export” দেবেন না। আপনার পরে অ্যাক্সেস বাড়ানো সবসময় করা যাবে, কিন্তু পরে তা কমানো অভ্যাস ভাঙ্গে।

5. যেখানে প্রয়োজন সেখানে স্কোপ যোগ করুন। একটি একক “edit” অনুমতির পরিবর্তে লক্ষ করুন “edit own”, “edit assigned”, বা “edit all” মত স্কোপ। এতে স্পষ্টতা থাকে বেছারি ভূমিকা তৈরি না করে।

ব্যতিক্রমগুলোই একটি আলাদা টেবিলে ধরুন, ম্যাট্রিক্সের ভিতরে নো্ট হিসেবে না। প্রতিটি ব্যতিক্রমে স্পষ্ট কারণ দিন (compliance, fraud risk, separation of duties) এবং একটি একক মালিক যিনি অনুমোদন করে।

এটা শেষ হলে, AppMaster-এর মতো টুলগুলো ম্যাট্রিক্সকে প্রোটেক্টেড এন্ডপয়েন্ট ও অ্যাডমিন স্ক্রিনে রূপান্তর করা সহজ করে, কারণ নির্মাণের সময় অনুমতিগুলি স্পষ্ট থাকে।

ম্যাট্রিক্সকে ব্যবহারযোগ্য রাখার স্ট্রাকচার কেমন হওয়া উচিত

একটি অনুমতি ম্যাট্রিক্স তখনই সহায়ক যখন মানুষ তা দ্রুত পড়তে পারে। যদি এটা সেলগুলোয় পরিপূর্ণ বিশাল না হয়ে যায়, দলগুলো ব্যবহার বন্ধ করে দেয় এবং অনুমতিগুলো মনচাইলামত বিচ্যুত হয়।

প্রতিটি ব্যবসায়িক ডোমেইনে ম্যাট্রিক্স ভাগ করে শুরু করুন। সমস্ত কিছু জন্য এক শিটের বদলে ব্যবসায়ের একেকটি এলাকায় আলাদা ট্যাব রাখুন: Customers, Billing, Content ইত্যাদি। অধিকাংশ ভূমিকা কেবল কয়েকটি ডোমেইনে কাজ করে, তাই রিভিউ দ্রুত হয় এবং ভুল পরিবর্তন কম হয়।

ট্যাব জুড়ে একটি নামকরণ প্যাটার্ন ব্যবহার করুন যা ধারাবাহিক থাকে। একটি সহজ ফরম্যাট Resource.Action.Scope করে রাখলে প্রতিটি অনুমতি কী বোঝায় তা সহজে পড়া যায় এবং একেইরকম দেখানো হলেও ভিন্ন ভিন্ন নামে ডুপ্লিকেট রোধ হয়। উদাহরণ: Invoice.Approve.Department এবং Customer.Edit.Own একই প্যাটার্নে পড়ে।

কোনো এজ কেসে গেলে নতুন ভূমিকা তৈরি করার লোভে পড়বেন না। সেলটির পাশে সংক্ষিপ্ত নোট যোগ করুন যাতে ব্যতিক্রম কখন প্রযোজ্য তা বোঝায়। উদাহরণ: Support ইনভয়েস দেখতে পারে, কিন্তু কেবল গ্রাহক পরিচয় যাচাইয়ের পরে। নোটটি অতিরিক্ত UI ধাপও নির্দেশ করতে পারে, ভূমিকা মডেল বদলানো ছাড়া।

উচ্চ-ঝুঁকিপূর্ণ অনুমতিগুলো ফ্ল্যাগ করুন যেন সেগুলো রিভিউয়ের সময় চোখে পড়ে। এগুলো হলো refunds, approvals, exports, এবং delete মত অ্যাকশন। সেলগুলোতে মার্ক করুন এবং কী অতিরিক্ত চেক দরকার তা লিখে রাখুন—যেমন two-person approval বা manager-only confirmation।

টেকসই রাখার জন্য ম্যাট্রিক্সকে সংস্করণ করুন:

• v1, v2 ইত্যাদি + তারিখ
• মালিক (একজন দায়িত্বশীল ব্যক্তি)
• সংক্ষিপ্ত পরিবর্তন সারসংক্ষেপ
• পরিবর্তন ট্রিগার করা কী (নতুন ওয়ার্কফ্লো, অডিট ফাইন্ডিং)

ম্যাট্রিক্স স্থিতিশীল হলে, AppMaster-এ স্ক্রিন ও এন্ডপয়েন্ট তৈরি করা অনেক সহজ হয়, কারণ প্রতিটি বোতাম ও API অ্যাকশন একটি পরিষ্কার অনুমতি নামের সাথে মিলবে।

ম্যাট্রিক্সকে স্ক্রিন ও এন্ডপয়েন্টে রূপান্তর করা

একটি অনুমতি ম্যাট্রিক্স তখনই কার্যকর যখন এটি দু'জায়গায় বাস্তবে রূপ পায়: আপনার API এবং আপনার UI। প্রতিটি রিসোর্সকে (Tickets, Invoices, Users ইত্যাদি) একটি এন্ডপয়েন্ট গ্রুপ হিসেবে বিবেচনা করে শুরু করুন। আপনার অ্যাকশনগুলোকে ম্যাট্রিক্সের ক্রিয়াপদগুলোর সাথে সঙ্গত রাখুন: view, create, edit, approve, export, delete।

API পাশে, প্রতিটি অনুরোধে অনুমতি প্রয়োগ করুন। UI চেকগুলো পরিষ্কারতার জন্য দরকারী, কিন্তু সেগুলো নিরাপত্তা নয়। একটি লুকানো বোতাম সরাসরি API কল থামাবে না।

ম্যাট্রিক্সকে API অনুমতিতে অনুবাদ করার সহজ উপায় হলো অনুমতিগুলোর নাম ধারাবাহিক রাখা এবং যে বাউন্ডারিতে অ্যাকশন ঘটে সেখানে লাগানো:

• tickets:view, tickets:edit, tickets:export
• invoices:view, invoices:approve, invoices:delete
• users:view, users:invite

তারপর একই অনুমতি নামগুলো UI-তেও গেট চালাতে ব্যবহার করুন: মেনু আইটেম, পেজ অ্যাক্সেস, বোতাম, এমনকি ফিল্ড। উদাহরণস্বরূপ, একজন Support এজেন্ট টিকিট তালিকা দেখতে পেতে পারে এবং একটি টিকিট খুলতে পারে, কিন্তু “Refund” ফিল্ডটি readonly হবে যদি তার কাছে invoices:approve না থাকে।

লিস্ট বনাম ডিটেইল অ্যাক্সেস নিয়ে সতর্ক থাকুন। দলগুলো প্রায়ই “কিছু আছে তা দেখতে” দরকার কিন্তু রেকর্ড নিজে দেখা দরকার হয় না। এর মানে আপনি তালিকা রেজাল্টে সীমিত কলাম দেখাতে পারেন, কিন্তু ডিটেইল ভিউ ব্লক করা উচিত যদি না ইউজারের কাছে ডিটেইল পারমিশন থাকে (বা স্কোপ চেক যেমন “আমার কাছে অ্যাসাইন করা”)। এটা আগে ঠিক করে নিন যাতে তালিকা স্ক্রীন সংবেদনশীল ডেটা লিক না করে।

সবশেষে, যেসব অ্যাকশন গুরুত্বপূর্ণ তাদের জন্য অডিট লগ ম্যাপ করুন। Export, delete, approve, role changes, এবং ডাউনলোডগুলোকে যে কেউ, কী, কখন, এবং কোন টার্গেট রেকর্ড—এসব তথ্যসহ অডিট ইভেন্ট তৈরি করা উচিত। যদি আপনি AppMaster-এ নির্মাণ করে থাকেন, আপনি এন্ডপয়েন্ট লজিক ও ব্যবসায়িক প্রক্রিয়াতে এটিকে প্রতিফলিত করতে পারবেন যাতে একই নিয়ম অ্যাকশন ও তার অডিট এন্ট্রো দুটোকেই ট্রিগার করে।

সাধারণ ভুল ও ফাঁদগুলো

সবচেয়ে দ্রুত অনুমতি ম্যাট্রিক্স নষ্ট হয় যখন UI মডেল করে ব্যবসায়িক মডেল না করা হয়। একটি স্ক্রিনে অনেক কিছু দেখানো হতে পারে, এবং একই জিনিস একাধিক স্ক্রিনে দেখা যায়। যদি আপনি প্রতিটি স্ক্রিনকে আলাদা রিসোর্স হিসেবে মডেল করেন, আপনি নিয়ম পুনরাবৃত্তি করবেন, এজ কেসগুলো মিস করবেন, এবং নামকরণ নিয়ে ঝগড়া করবেন পরিবর্তে অ্যাক্সেস নিয়ে।

অন্য একটি সাধারণ ফাঁদ হলো role sprawl। দলগুলো ক্রমশ ভূমিকা বাড়াতে থাকে (Support Level 1, Support Level 2, Support Manager ইত্যাদি) যেখানে একটি ছোট ভূমিকা সেট এবং স্পষ্ট স্কোপ যথেষ্ট হতে পারে। “own team”, “assigned region”, বা “accounts you manage” মত স্কোপগুলো নতুন ভূমিকার চেয়ে পার্থক্য ভালোভাবে বোঝায়।

কিছু ভুল যা প্রকৃত টুলগুলোতে দেখা যায়:

• শুধুমাত্র “view” ও “edit” নির্ধারণ করা, তারপর export, bulk edit, refund, impersonate, বা “change owner” মত অ্যাকশন ভুলে যাওয়া।
• ব্যতিক্রমগুলোকে দীর্ঘমেয়াদী প্যাচ হিসেবে ব্যবহার করা। এক-অফ গ্রান্টগুলো (“Sam-কে এক সপ্তাহের জন্য Finance অ্যাক্সেস দাও”) দ্রুত স্থায়ী হয়ে যায় এবং একটি ভাঙা ভূমিকা মডেল লুকায়।
• UI-তে বোতাম লুকিয়ে রেখে ধরে নেওয়া যে সিস্টেম নিরাপদ। API তবুও অনুরোধ প্রত্যাখ্যান করতে হবে, এমনকি কেউ এন্ডপয়েন্টটি পেয়ে গেলে।
• কেউ যখন টিম ট্রান্সফার বা অঞ্চল পরিবর্তন করে তখন কী হবে তা ঠিক না করা। অনুমতিগুলোটি ভবিষ্যতে আপডেট হওয়া উচিত, নয়ত ঝুলে থাকবে।
• “admin”-কে সীমাহীন ধরা; এমনকি অ্যাডমিনদেরও গার্ডরেইল দরকার—উদাহরণ: “ব্যবহারকারী পরিচালনা করতে পারে কিন্তু payouts অনুমোদন করতে পারবেন না”।

ব্যতিক্রমগুলো বিশেষ সতর্কতা দাবি করে। অস্থায়ী পরিস্থিতির জন্য এগুলো ব্যবহার উপকারী, কিন্তু এগুলো এক্সপায়ার বা রিভিউ করা উচিত। ব্যতিক্রম বাড়তে থাকলে সেটা সংকেত যে আপনার ভূমিকা বা স্কোপ পরিষ্কারভাবে ম্যাপ করা নেই।

একটি দ্রুত উদাহরণ: একটি সাপোর্ট ও ফাইন্যান্স টুলে Support গ্রাহক প্রোফাইল দেখতে পারে এবং টিকিট তৈরি করতে পারে, কিন্তু Finance ইনভয়েস এক্সপোর্ট এবং রিফান্ড ইস্যু করে। যদি আপনি কেবল পেজগুলো সুরক্ষিত করেন, একটি Support এজেন্ট সরাসরি এক্সপোর্ট এন্ডপয়েন্ট কল করে ফাইল লঙ্ঘন করতে পারে। কাস্টম কোডই বানাচ্ছেন বা AppMaster-এর মতো প্ল্যাটফর্ম ব্যবহার করছেন, নিয়মটি সার্ভার সাইডেই থাকা উচিত, কেবল UI-তেই নয়।

নির্মাণ শুরুর আগে দ্রুত চেকলিস্ট

একটি অনুমতি ম্যাট্রিক্স তখনই কার্যকর যখন এটি স্পষ্ট, প্রয়োগযোগ্য নিয়মে রূপান্তরিত হয়। আপনার প্রথম স্ক্রিন বা এন্ডপয়েন্ট তৈরির আগে এই চেকলিস্টটি রাখুন। এটি আপনাকে “প্রায় সুরক্ষিত” কনফিগারেশন এড়াতে সাহায্য করবে যেগুলো নতুন ভূমিকা বা এজ কেস আসলে ভেঙে পড়ে।

নিয়ম তৈরি করুন, তারপর UI তৈরি করুন

ডিফল্টরূপে প্রত্যাখ্যান (default deny) মাইন্ডসেট রাখুন: যা স্পষ্টভাবে অনুমোদিত নয় তা ব্লক। এটি সবচেয়ে নিরাপদ বেসলাইন এবং নতুন ফিচার যোগ করলে আচমকা অ্যাক্সেস প্রতিরোধ করে।

প্রতিটি অনুমতির জন্য একটি একক ট্রুথ সোর্স রাখুন। সেটা স্প্রেডশীট, ডাটাবেসের টেবিল, বা আপনার নো-কোড কনফিগারেশন—টিমের সবাইকে জানাতে হবে কোথায় বর্তমান নিয়ম আছে। যদি স্প্রেডশীট এক কথা বলে এবং অ্যাপ অন্য কিছু করে, আপনি বাগ শিপ করবেন।

নিচে একটি সংক্ষিপ্ত আগে-বিল্ড চেকলিস্ট:

• UI বোতাম, API এন্ডপয়েন্ট, এক্সপোর্ট, ব্যাকগ্রাউন্ড জব—সব জায়গায় default deny প্রয়োগ আছে।
• প্রতিটি অ্যাকশনের জন্য স্পষ্ট স্কোপ সংজ্ঞা আছে (own record, team, region, all, বা নামকৃত সাবসেট)।
• অ্যাডমিন ক্ষমতাগুলো ব্যবসায়িক অ্যাকশনের থেকে আলাদা (ভূমিকা পরিচালনা ‘approve refund’ নয়)।
• স্পর্শকাতর অ্যাকশনগুলো শক্ত নিয়ন্ত্রণ দাবি করে (অনুমোদন ধাপ, লগিং, এবং অস্বাভাবিক কার্যকলাপের জন্য সতর্কতা)।
• ব্যতিক্রমগুলোতে মালিক ও মেয়াদ আছে, যাতে “অস্থায়ী অ্যাক্সেস” স্থায়ী না হয়।

এর পরে, একটি বাস্তবসম্মত পরিস্থিতি দিয়ে নিয়মগুলো স্যানিটি-চেক করুন। উদাহরণ: “একজন Support এজেন্ট একটি অর্ডার দেখতে পারে এবং তাদের অঞ্চলের জন্য নোট যোগ করতে পারে, কিন্তু মূল্য পরিবর্তন বা রিফান্ড দিতে পারবে না। Finance রিফান্ড দিতে পারে, কিন্তু ম্যানেজার অনুমোদনের পর, এবং প্রত্যেক রিফান্ড লগ হবে।” যদি আপনি এটি এক বা দুই বাক্যে বলতে না পারেন, আপনার স্কোপ এবং ব্যতিক্রমগুলো এখনও পরিষ্কার নয়।

আপনি যদি AppMaster-এ নির্মাণ করেন, এই আইটেমগুলোকে আপনার স্ক্রীন ও ব্যবসায়িক লজিকের জন্য_requirement_ হিসেবে বিবেচনা করুন, কেবল UI-এর জন্য নয়। বোতামগুলো একশন লুকায়, কিন্তু প্রকৃত নিয়ন্ত্রণ ব্যাকএন্ডেই হয়।

উদাহরণ পরিমণ্ডল: একটি সাপোর্ট ও ফাইন্যান্স অভ্যন্তরীণ টুল

কল্পনা করুন একটি মাঝারি আকারের কোম্পানি যার একটি অভ্যন্তরীণ টুল আছে যা Support ও Finance ব্যবহার করে। একই ডাটাবেসে Customers, Tickets, Refunds, Payouts, এবং Settings আছে (টেমপ্লেট ও ইন্টিগ্রেশনসমূহ)। এখানে সাধারণ লগইন চেকই যথেষ্ট নয়।

তারা শুরু করতে যে ভূমিকা নির্ধারণ করে:

• Support Agent: একটি কিউ-তে টিকিট নিয়ে কাজ করে
• Support Lead: বিভিন্ন কিউ জুড়ে সহায়তা ও কিছু অ্যাকশন অনুমোদন করে
• Finance: টাকা-সংক্রান্ত কাজ করে
• Ops Admin: অ্যাক্সেস কন্ট্রোল ও সিস্টেম সেটিংসের মালিক

একটি ব্যবহারিক অনুমতি ম্যাট্রিক্স শুরু হয় প্রতিটি রিসোর্সের অ্যাকশন লিখে, তারপর স্কোপ দিয়ে শান্ট করা।

টিকিটগুলোর জন্য, Support Agents তাদের অ্যাসাইন করা কিউ-র টিকিটগুলোর জন্য দেখতে এবং স্ট্যাটাস আপডেট করতে পারে। তারা নোট যোগ করতে পারে, কিন্তু টিকিটের মালিক পরিবর্তন করতে পারবে না। Support Leads Support Agent-এর সব কাজই করতে পারে, প্লাস তাদের অঞ্চলের মধ্যে টিকিট পুনঃঅ্যাসাইন করতে পারে।

রিফান্ডের জন্য, Finance রিফান্ড তৈরি ও অনুমোদন করতে পারে, কিন্তু একটি নির্ধারিত সীমার মধ্যে। Support রিফান্ড রিকোয়ারেস্ট তৈরি করতে পারে, কিন্তু অনুমোদন করতে পারবে না। রিফান্ড অনুমোদন আলাদা অ্যাকশন হিসেবে রাখা হয়েছে যাতে অ্যাকসিডেন্টালি অনুমোদন দেওয়া না যায়।

Payouts এবং Settings-এ টুল কঠোর: কেবল Finance পেআউট দেখতে পারে, এবং কেবল Ops Admin Settings বদলাতে পারে। Support এই স্ক্রিনগুলো দেখতে পাবে না—এতে লোভ কমে এবং ভুল কম হয়।

এখন একটি ব্যতিক্রম যোগ করুন: একজন Support Lead দুই সপ্তাহের জন্য অন্য অঞ্চল কভার করছে। ওনারকে Ops Admin মতো বিস্তৃত ভূমিকা না দিয়ে, ম্যাট্রিক্সে একটি অস্থায়ী স্কোপ সম্প্রসারণ যোগ করা যায় (Support Lead + Region B, মেয়াদ শেষ হওয়ার তারিখ সহ)। সেই একক ব্যতিক্রমটি অনেকটা নিরাপদ কপি করে অনুমতি ছড়ানো থেকে।

আপনি যদি এটি AppMaster-এ নির্মাণ করেন, একই ম্যাট্রিক্স UI-তে কোন পেজ দেখা যাবে এবং ব্যাকএন্ড কোন অনুরোধ অনুমোদন করবে তা নির্দেশ করবে, যাতে কেউ অনুমিত না থাকলে Payouts বা Settings-এ পৌঁছাতে না পারে।

সময়ের সাথে অনুমতিগুলো কিভাবে পরীক্ষা ও রক্ষণ করবেন

অনুমতিগুলো সাধারণত ছোট, বিরক্তিকর ভুলে ব্যর্থ হয়: একটি স্ক্রীন একটি বোতাম লুকায়া দেয়নি, একটি এন্ডপয়েন্ট চেক ছাড়াই রয়ে গেছে, একটি স্কোপ নিয়ম খুব বিস্তৃত। একটি ভাল অনুমতি ম্যাট্রিক্স তখনই বেশি মূল্যবান হয় যখন আপনি এটিকে পুনরাবৃত্তি টেস্ট ও সহজ রক্ষণশীল রুটিনে রূপান্তর করেন।

ছোট একটি টেস্ট ইউজার সেট দিয়ে শুরু করুন। বাড়তি একাধিক অ্যাকাউন্ট দরকার নেই। প্রতিটি ভূমিকার জন্য একজন ইউজার, প্লাস প্রতিটি সাধারণ ব্যতিকেসের জন্য একজন “এজ” ইউজার (যেমন “রিফান্ড অনুমোদন সহ Support এজেন্ট”) রাখুন। এই অ্যাকাউন্টগুলো স্থির রাখুন যাতে আপনার টিম এগুলো পুনরায় ব্যবহার করতে পারে সপ্রতিদিন।

তারপর ম্যাট্রিক্সকে টেস্ট কেসে লিখুন। প্রতিটি নিয়মের জন্য একটি “অনুমোদিত” পথ এবং একটি “প্রত্যাখ্যাত” পথ লিখুন। প্রত্যাখ্যাত পথটি স্পষ্ট রাখুন (কি হওয়া উচিত) যাতে মানুষ এটাকে বাতিলে না করে।

• Role: Support Agent. Action: Refund. Expected: denied with clear message, no data changed.
• Role: Finance. Action: Refund. Expected: allowed, creates refund record, logs actor and reason.
• Role: Manager. Action: View tickets. Scope: team only. Expected: can view team tickets, cannot open other teams’ tickets.

একই নিয়মটি ডাবল-টেস্ট করুন: UI এবং API — যদি UI ব্লক করে কিন্তু API অনুমতি দেয়, কেউ স্ক্রীন বাইপাস করে এন্ডপয়েন্ট কল করে চলতে পারে। AppMaster ব্যবহার করলে UI লজিক এবং ব্যাকএন্ড এন্ডপয়েন্ট দুই-ই চেক করে পরীক্ষা করুন।

স্কোপগুলো পরীক্ষার জন্য বাস্তব ডেটা লাগবে। মালকানাধীন, টিম, ও অঞ্চলভিত্তিক ভিন্ন টেস্ট রেকর্ড তৈরি করুন। নিশ্চিত করুন আপনি অন্য স্কোপের আইডি অনুমান করে অ্যাক্সেস করতে পারবেন না।

শেষে, স্পর্শকাতর অ্যাকশনের জন্য কি লগ হবে তা ঠিক করুন (রিফান্ড, এক্সপোর্ট, ভূমিকা পরিবর্তন)। কে করল, কী বদলল, কখন, এবং কোথা থেকে—এসব লগ করুন। লগগুলো নির্দিষ্ট মেয়াদে রিভিউ করুন, এবং বিরল হওয়া উচিত এমন অ্যাকশনের (যেমন অনুমতি সম্পাদনা বা বড় এক্সপোর্ট) জন্য সতর্কতা যোগ করুন।

পরবর্তী ধাপ: ম্যাট্রিক্সকে কাজ করা অভ্যন্তরীণ টুলে রূপান্তর

আপনার অনুমতি ম্যাট্রিক্সকে বিল্ড প্ল্যান হিসেবে বিবেচনা করুন, এমন নয় যে কেবল একটি নথি হিসেবে ফাইলবক্সে রাখা হবে। দ্রুত মূল্য পেতে চান? ডেটা-মালিক ও প্রসেস মালিকদের সাথে মৌলিক বিষয়গুলো নির্দিষ্ট করে নিন।

একটি ছোট ওয়র্কশপ দিয়ে শুরু করুন (30 মিনিটেই যথেষ্ট) — প্রতিটি ভূমিকার একজন প্রতিনিধি এবং প্রতিটি রিসোর্সের মালিকদের নিয়ে। ভূমিকা, রিসোর্স, অ্যাকশন, স্কোপগুলো দিয়ে সামনে থেকে এগিয়ে যান, এবং যে কোনো বিশেষ কেসগুলো চিহ্নিত করুন। যদি কোনো ব্যতিক্রম সাধারণ মনে হয়, সেটি সম্ভবত একটি অনুপস্থিত স্কোপ।

তারপর v1 ম্যাট্রিক্স খসড়া করে রিসোর্স মালিকদের সাথে পর্যালোচনা করুন। বাস্তবধর্মী রাখুন: “Support ইনভয়েস দেখতে পারবে?” “Finance কাস্টমার ডিটেইল এডিট করতে পারবে?” কেউ হেঁচকি দিলে নিয়মটাকে সরাসরি ভাষায় ক্যাপচার করুন—পরে ফরমালাইজ করা যায়।

v1 অনুমোদিত হলে, এক ডোমেইন end-to-end করে দেখুন। একটি পাতলা স্লাইস নিন যা ডেটা, লজিক, এবং UI স্পর্শ করে (উদাহরণ: টিকিটিং বা ইনভয়েস অনুমোদন)। আপনাকে উত্তর দিতে হবে: কে তা দেখতে পারবে, কে পরিবর্তন করবে, এবং তারা চেষ্টা করলে কি ঘটবে।

আপনি যদি AppMaster ব্যবহার করেন, ম্যাট্রিক্সকে প্রোডাক্ট অংশগুলোর সাথে ম্যাপ করুন:

• Data Designer: রিসোর্সগুলোকে entity (টেবিল) এবং কী ফিল্ডগুলো স্কোপকে প্রভাবিত করে (যেমন team_id, region_id) সেগুলোর সাথে মিলান
• Business Processes: যেখানে পরিবর্তন ঘটে সেখানে নিয়ম প্রয়োগ করুন (create, update, approve, export)
• UI visibility rules: ব্যবহারকারীরা যা করতে পারবে না তা লুকিয়ে রাখুন, এবং access denied হলে স্পষ্ট “কেন” মেসেজ দেখান
• Endpoints: প্রতিটি ভূমিকার প্রয়োজন অনুযায়ী এক্সপোজ করুন, এবং অ্যাডমিন-ওনলি অপারেশনগুলো আলাদা রাখুন

একটি সাধারণ উদাহরণ: “Refund request” ফ্লো তৈরির সময় Support তৈরি করে ও Finance অনুমোদন করে—এই দুটি ভূমিকা নিয়ে যদি সবকিছু সুশৃঙ্খলভাবে কাজ করে, তখন আপনি এজ কেস যোগ করতে পারবেন যেমন “Support কেবল 30 মিনিটের মধ্যে ক্যানসেল করতে পারে।”

একটি ছোট অভ্যন্তরীণ টুল AppMaster-এ_try_ করে দেখুন যাতে_roles_ ও ফ্লোগুলো আগে_validate_ করা যায়, তারপর ম্যাট্রিক্স থেকে ইটারেট করুন। লক্ষ্য হল 20টি স্ক্রিন ও অনেক অনুমতি ফিক্স হওয়ার আগেই ভুলগুলো ধরা।