Add permissions

[shanirub]

Phase 1: Basic Permissions Setup

• [x] Research & Plan Review the types of users/roles your app will support (e.g., admin, staff, customer). Decide on which actions/views will require permission control (e.g., accessing admin panel, managing orders, etc.).

• [x] User Roles Use Django’s built-in user groups and permissions to categorize users (admin, staff, customer). Create initial user roles using Django’s auth.Group and assign permissions accordingly.

• [ ] Define Permissions for Views Use Django’s @permission_required or UserPassesTestMixin for CBVs to restrict access to specific views (e.g., only admins can delete products, only customers can place orders). Ensure login_required is added where necessary for authenticated-only views.

• [ ] Testing Write unit tests for permission checks, ensuring users with appropriate roles can access/modify content while others are restricted.

Phase 2: Fine-Grained Control

• [ ] Object-Level Permissions (Optional) Consider implementing object-level permissions (using Django’s django-guardian or custom logic) for more fine-grained access control. Example: A customer can only view and manage their own orders but not others’.

  • [ ] Custom Permissions for Orders Define custom permissions for actions like creating, viewing, updating, or canceling orders. Integrate these permissions into your order views and models.

  • [ ] Test Permissions in the Order System Once implemented, ensure users with appropriate roles can create/view orders. Validate that unauthorized users get proper permission denied responses.

Phase 3: Refine and Optimize

• [ ] Admin Permissions Ensure that admin/staff users can manage orders, products, and customers. Implement Django’s built-in admin features or create custom admin views if necessary.

• [ ] Access Control in Templates Use template tags to hide or show certain UI elements (like buttons or links) based on the user’s permissions (e.g., only customers can see a "Place Order" button).

• [ ] Enhance Security Review all views, forms, and models to make sure permission logic is tight and secure. Ensure your tests cover permission-related edge cases (e.g., URL manipulation to access restricted views).

[shanirub]

Research and plan draft

1. Customers

   Permissions: Can create, update, and delete their own orders and order items. Can only read products. Approach: You can assign customer users to a "Customer" group and apply these permissions via the views and models related to orders and products.

2. Staff

   Permissions: Can create, update, and delete customer users. Can read orders and order items but cannot modify them. Full access (CRUD) to products and categories. Approach: Staff members will be part of a "Staff" group. Permissions can be managed using Django’s model-level permissions and some view-level logic for restricting order modifications.

3. Admin

   Permissions: Full CRUD for users, orders, products, and categories. Primarily used to manage staff users. Approach: Admins can be in the "Admin" group with the highest level of access.

4. Stock Personnel

   Permissions: Can only update product prices and quantities, without touching other fields. Approach: You can add a custom group "Stock Personnel" and restrict access to specific product fields using forms and model-level restrictions.

5. Shift Manager

   Permissions: Combination of staff and customer permissions—full access to products and users, plus the ability to manage orders. Approach: The "Shift Manager" group would combine the permissions of both "Customer" and "Staff" groups.

[shanirub]

		groups	customers_group	staff_group	stock_personnel_group	shift_manager_group
models
Product	create			v		v
	read		v	v	v	v
	update			v	v	v
	delete			v		v
Category	create			v		v
	read		v	v	v	v
	update			v		v
	delete			v		v
Order	create		v			v
	read		v	v		v
	update		v			v
	delete		v			v
OrderItem	create		v			v
	read		v	v		v
	update		v			v
	delete		v			v
User	create			v
	read			v
	update			v
	delete			v