`Testing Supervisor Permissions and Training Records in an Arabic LMS for Palestinian Teams`

A team supervisor at a small company in Nablus opens the progress page for her four employees in the new Arabic LMS and finds six names, not four. Two belong to the finance team next door. A week later, the training officer notices that an employee who failed a product assessment now shows as ‘completed’: his supervisor had found an edit button and used it to meet a deadline.

Neither problem was intended, and neither is dramatic on its own. Both come from permissions in the Arabic LMS that were set up but never tested. In small teams, where people know each other and one supervisor may cover two teams, a single wrong setting exposes identifiable colleagues and quietly weakens the training record.

This article gives HR, IT, and procurement teams working with Palestinian teams a hands-on test script for an Arabic LMS: a set of representative accounts and a sequence of steps that check whether each supervisor sees only their own team, and whether training records stay accurate and protected. It assumes you already have a role matrix and shows how to prove that the Arabic LMS follows it.

`Why Small Teams Need a Permission Test, Not Just a Setting`

In a large organization, a permission error may expose a list of strangers. In a team of five, it exposes named colleagues. Small organizations also bend roles more often: a supervisor covers a colleague’s team during leave, a team leader is also a learner on a leadership course, and one training officer handles HR, scheduling, and reporting. Each of these situations is a place where an Arabic LMS can show more than it should.

Start from a written role matrix that states, for each role, its scope, the data it may see, and the actions it may take. If you have not built one yet, our guide to managing LMS permissions across Saudi company branches explains how to design it; the principles apply to small teams as well. The script below turns that matrix into tests you can run in an afternoon and repeat after every change to the Arabic LMS.

`Set Up Representative Accounts in the Arabic LMS`

Run the script in a test environment of the Arabic LMS, or with test accounts that use fictional people, never real employees’ records. Build two or three small fictional teams with Arabic names, then create one account for each situation you need to prove:

Supervisor A, responsible for Team 1 (four employees).

Supervisor B, responsible for Team 2 (three employees).

An acting supervisor who covers Team 2 for two weeks.

A supervisor who is also enrolled as a learner in a leadership course with peers from other teams.

An employee who belongs to Team 1 but also works on a project with Team 2.

The training officer, who sees all teams in the Arabic LMS but should not change results without a trace.

An administrator, used only for setup and for checking the audit trail.

Give each fictional employee a few records in the Arabic LMS: a completed course, a failed assessment, an attendance entry for a classroom session, and one course in progress. These are the records the script will try to see, change, or protect.

`Write the Arabic LMS Test Script Before Anyone Signs In`

A test script is a numbered list of steps. For each step, write the account, the action, the expected result, the actual result, the evidence (a screenshot or exported file), and pass or fail. Writing the expected result first matters: without it, testers tend to accept whatever the Arabic LMS shows as normal.

Security testers use two ideas that fit this work well. The OWASP Web Security Testing Guide’s test for bypassing the authorization schema distinguishes horizontal access, where a user reaches data belonging to someone else with the same role, from vertical access, where a user obtains a role higher than their own. In an Arabic LMS, the first is Supervisor A seeing Team 2; the second is a supervisor editing results that only the training officer should touch.

Agree on one rule before the session: any step in which an account sees or changes data outside its scope is a blocking failure, to be fixed and retested before the Arabic LMS goes live for supervisors.

`Script Part 1: Does Each Supervisor See Only Their Own Team?`

Open the team progress page: Supervisor A sees exactly the four members of Team 1, and nobody else.

Paste a link to a Team 2 employee’s record, copied from Supervisor B’s session: access is refused, and no name appears.

Change the employee number or record identifier in the browser address: access is still refused.

Open the leadership course as the supervisor-learner: their own progress is visible, but not the scores of peers from other teams.

Sign in as the acting supervisor before, during, and after the cover period: access to Team 2 starts and ends on the agreed dates.

Check the shared employee: Supervisor B sees only the project course, if that is your rule, not the employee’s full history.

The second and third steps come from the OWASP test for insecure direct object references, which recommends using at least two test users with their own records and changing the value that points to a record to see whether another user’s data can be reached. No security specialist is needed: it means copying a link from one Arabic LMS session and opening it in another.

Repeat the steps on a phone, because supervisors often check progress between tasks, and mobile views of an Arabic LMS can list people differently. If supervisors need more than final completion, for example, stage-by-stage progress when practice is split around shifts, as in designing flexible eLearning practice around work schedules for Palestinian teams, add those views to the script too.

Script Part 2: Are Training Records in the Arabic LMS Accurate and Protected?

Visibility is half the test. The other half is whether the records a supervisor sees are correct, and whether anyone can change them in the Arabic LMS without leaving a trace. Continue the script:

As Supervisor A, try to edit the failed assessment or mark the course in progress as completed: the action is unavailable or refused.

As Supervisor A, record attendance for a Team 1 classroom session: it works, and the record shows who entered it and when. Try the same for a Team 2 employee: it is refused.

As the training officer, correct one attendance entry: the change is saved with the previous value, the person, the date, and a reason.

Move the shared employee fully to Team 2: completed courses, the failed attempt, and attendance stay in their history, unchanged.

Compare five records in the Arabic LMS with the original evidence, such as the signed attendance sheet or the assessment attempt: dates, results, and Arabic names match.

Deactivate a test account: the person’s history remains available to authorized roles and is not deleted.

If records do not match the evidence, check how each status is defined before blaming the permissions; our guide to testing LMS completion reports sets out the definitions to confirm. Then decide, in line with your organization’s HR and data protection policies, how long training records of former staff stay in the Arabic LMS and who may see them.

`A Hypothetical Example: A Software Company in Ramallah`

The following example is hypothetical and is included only to illustrate the method.

A software services company in Ramallah with about forty staff in six small teams is moving its onboarding, information security, and product courses into an Arabic LMS. Before giving supervisors access, the HR officer and an IT colleague build three fictional teams, create eight test accounts and run a 24-step script over one afternoon.

Three steps fail. Supervisor A can open a Team 2 record from a copied link, although Team 2 does not appear in her list. The supervisor-learner can see the assessment scores of every participant in the leadership course. And the training officer’s correction to an attendance entry is saved without any record of the previous value.

The company asks the Arabic LMS provider to enforce team scope on direct links, hide peer scores in the leadership course, and agrees that every correction must carry a reason and keep the old value. Two weeks later, the same script runs again with fresh test records, all 24 steps pass, and supervisors receive access to the Arabic LMS. The script is kept and rerun after each platform update and whenever a supervisor changes.

`Summary`

In small Palestinian teams, a permission error exposes named colleagues, and an unchecked edit weakens the training record. A role matrix states what should happen; only a test script with representative accounts shows what the Arabic LMS actually does.

Write the expected result for every step, test horizontal and vertical access, try direct links, check that records match the evidence and that every correction leaves a trace, then rerun the script after each change to the Arabic LMS. It takes an afternoon, and it protects both the people and the record.

Click here. If you are preparing supervisor access in an Arabic LMS and would like a second view on your test script, the SkillUp MENA team can discuss your requirements with you.