# Tier Access Model Update: Sequential and Adhoc Tiers

## Goal

Introduce a tier type flag so the system can support two distinct behaviors:

1. Sequential tiers
   - Existing ladder-style tiers such as BIASHARA 1 to 8.
   - Access is inherited downward in the sequence.
   - Example: if a user is granted Tier 3, they can also access Tier 1 and Tier 2 through the existing ladder logic.

2. Adhoc tiers
   - Independent tiers such as Monthly Tier.
   - They are not part of the sequential ladder.
   - Assigning an adhoc tier to a user should not unlock or imply access to other tiers.

## Scope

This change must be implemented in a backward-compatible way so existing sequential tier behavior remains intact.

## Expected Behavior

### Sequential tiers
- Keep the current ladder-based access model.
- Existing tiers remain usable as before.
- Access checks should continue to behave as a progression from lower to higher tiers.

### Adhoc tiers
- A new tier type will be stored on the tier record.
- When a user is assigned an adhoc tier, the system should treat that tier as a standalone access level.
- Adhoc tiers should not automatically unlock other tiers.

## Implementation Notes

### 1. Add tier type support
- Add a new field to the tiers table to distinguish tier behavior.
- Recommended values:
  - sequential
  - adhoc
- Default existing tiers to sequential so current behavior is preserved.

### 2. Preserve existing logic
- Existing sequential tiers should continue to work without requiring any manual migration for current users.
- Existing admin and user flows should still function normally for the current ladder-based tiers.

### 3. Update access checks
- Any place where tier access is evaluated should check the tier type before applying ladder logic.
- For sequential tiers, keep the current comparison against the user’s assigned tier.
- For adhoc tiers, only allow access to that exact tier and do not imply access to other tiers.

### 4. Admin creation and edit flow
- The admin tier form should allow selecting the tier type when creating or editing a tier.
- The default value should be sequential for backward compatibility.

### 5. User assignment behavior
- Admin assignment of a tier to a user should remain the same.
- If the assigned tier is adhoc, the user should receive that standalone tier access only.

## Acceptance Criteria

- Existing sequential tiers continue working as before.
- A new tier can be created as adhoc.
- Assigning an adhoc tier to a user does not grant access to other tiers.
- Assigning a sequential tier continues to work as a ladder-based access model.

## Suggested Implementation Order

1. Add tier type support in the database and model.
2. Update admin tier create/edit handling.
3. Update tier access checks in the relevant controllers.
4. Verify that existing sequential logic remains unchanged.
