Production backoffice administration

Production website

The production backoffice is separate from the public member website. Open Production WYA Backoffice. It redirects to the language-specific admin login; the hosted page title is Log in | WYA Backoffice.

1. Enter your authorized staff Username and Password.
2. Select Log in.
3. Open the permitted area from the administration menu. A normal public member account does not grant staff access.
4. Use the list search and filters to find the correct record, then open it to review or edit. Confirm its owner and ID before saving.
5. Use the backoffice logout control when finished.

The login destination and visible login controls were checked read-only. The protected workflows below were reviewed against the legacy application; deployed templates can differ. Match each visible control before changing a record.

New staging website

Staging uses a separate administrator login and interface. Use New staging sign-in and access, People and directory and Events and bookings. Production login credentials and sessions do not automatically grant staging access.

Verified legacy app registry

The legacy source lists these Django applications in INSTALLED_APPS: user_profiles, schools, testimonials, contacts, teachers, events, videos, orders, invoices, payments, notifications, otp, plus django.contrib.sites, oauth2_provider, social_django, allauth, cities_light, django_db_logger, and related framework/integration apps.

The following model registrations are directly present in legacy admin.py files:

Legacy area	Registered models or records
User/profile	User, Profile
Schools	SchoolType, SchoolLevel, SchoolLevelAdditional, SchoolTrainingType, SchoolStyleOfYoga, SchoolListTeacher, SchoolMainTeacherCertification, SchoolMainTeacherTeaching, SchoolIssueCertificate, School, SchoolRatingAndComment, SchoolGraduate, SchoolGallery
Teachers	TeacherType, TeacherTypeApply, StyleOfYoga, TeacherLevel, TeacherExperienceYear, TeacherBackground, Teacher, TeacherGallery
Events	Event, PlatformEvent, PlatformEventAttendee, EventInstructor, EventImage, EventStatus
Commerce	OrderStatus, Order, InvoiceStatus, Invoice, PaymentStatus, PaymentProvider, PaymentTransaction, PaymentMethod, PaymentType
Content and communication	Video, Testimonial, Contact, Notification

The legacy app registry also includes authentication, OAuth, social-login, OTP, location, logging, and upload integrations. Their presence in Django settings does not prove that an administrator may safely edit every record or that the feature is enabled in a deployed environment.

Source-backed legacy tasks

These steps describe the controls and fields defined by the old Django admin.py files. The deployed legacy templates can rename a button or add a confirmation prompt, so match the visible production control before submitting a change. The new staging guides do not use these steps.

Review or approve a school

1. Open the legacy Schools area and choose School.
2. Search by school_name or school_id. The list displays school_id, school_name, Level Registration, school_training_type, expiration_date, rating, viewer, training_event, graduate, comment, is_active, and status.
3. Open the school record. The source groups fields under School Infomation, Yoga And Faculty, and Document.
4. Review the owner/user, contact fields, expiration, is_active, status, is_recommended, is_approved, and show_contact. Review the attached registration inlines: Level Registration, Level Registration (Additional), Type, and Style of yoga.
5. Review the document fields doc_logo, doc_cover, doc_cv, doc_school_detail, doc_syllabus_curriculum, and doc_training_course_outline.
6. Save only after confirming the school identity and approval decision. The source exposes approval as the is_approved field; it does not define a separate school approval action in SchoolAdmin.

The school change form includes the visible Re-Generate Slug button. Use it only after checking school_name; the source reports Slug regenerated. after it saves the new slug. Recheck the public school link before sharing it.

Review or approve a teacher

1. Open Teachers → Teacher and search by name or the linked school’s school_name.
2. Check the list values teacher_id, name, user, school, teacher_type, training_event, is_active, is_approved, and created_at.
3. In the Teacher Infomation, Yoga And Faculty, and Document sections, review identity, school, contact, expired_date, status, is_active, is_approved, is_recommended, and show_contact.
4. Check the inline rows Apply Type, Level Registration, and Style Of Yoga, then review doc_avatar, doc_cover, doc_cv, doc_syllabus_curriculum, and doc_certificate.
5. Save the approved field values after confirming the teacher identity. The source exposes approval as is_approved; it does not define a separate teacher approval action.

The teacher change form includes the visible Re-Generate Slug button and reports Slug regenerated. after the new slug is saved. Recheck the public teacher link before sharing it.

Approve an event

1. Open Events → Event. Use the source filters school, is_active, status, accept_eyep, and accept_ce to narrow the list.
2. Check the row values school, teacher, subject, Status, dates/times, limited, currency, price, accept_eyep, accept_ce, region, is_active, and is_recommended.
3. Open the event and review the Info, Accommodation, Student Programs, Contact, and Social sections.
4. Review the inline rows for instructors, images, event facilities, selected options, and custom event options.
5. Use the visible Approve Event or Reject Event control only after checking the public-facing details. The source handler is intended to set the status to Approved or Rejected and report Event has been approved. or Event has been rejected.

There is a source mismatch to verify before treating either button as reliable: the legacy template submits the visible buttons with Approve Event/Reject Event, while the current handler checks different form keys. Source review therefore cannot prove that the click changes the status in a deployed copy. After any action, reopen the event and confirm the Status value in the list and form; if it did not change, stop and have the legacy system owner reconcile the deployed template and handler.

The source also sends an approval or rejection email to the event creator when an email is present. The message handler uses fail_silently=True, so the admin message is not proof that the creator received the email. Confirm the visible status separately.

Maintain a platform/community event

Open Events → Platform event. The source form groups subject, slug, contact fields, image, dates/times, limited, currency, price, description, is_active, is_recommended, email_target, and google_meet under Info, then has Contact and Social sections.

The custom change-form actions include sending an invitation, generating a Google Meet link, and regenerating a slug. The invitation handler queues one email per target recipient and reports Invitation email currently in the queue and will be sent shortly. That message means queueing occurred; it does not establish delivery. If the deployed form exposes Generate Google Meet or Re-Generate Slug, verify the resulting google_meet or slug field after the action.

Check who booked and update a booking

1. Open Events → Event booking.
2. Search by booking_reference, contact name/email/phone, event subject, username/email/name, or filter by status, currency, booking date, event start date, school, or teacher.
3. Use the displayed booking_reference, Event, User, status, total_participants, total_amount, currency, booking_date, and Payment Status to identify the reservation.
4. Open the booking and review Booking Information, Event & User Details, Participants, Contact Information, Address, Pricing, Special Requirements, Emergency Contact, Admin Notes, and Timestamps.
5. Review the inline BookingParticipant and BookingSelectedOption rows before changing contact or participant data.

The source actions are labelled Mark selected bookings as confirmed, Mark selected bookings as cancelled, and Send confirmation emails. If no matching confirmed/cancelled status exists, the source reports No confirmed status found. Please create one first. The email action’s source comment calls it a placeholder and counts confirmed bookings; its success message is not proof of mail delivery.

For cancellation history, open Events → Booking cancellation. The source list shows booking reference, reason, refund_amount, refund_processed, cancellation_date, and the cancelling user; filters cover reason, refund state, and date.

Create an invoice from an order and inspect payment history

The old Orders → Order list can be filtered by order_type and status and searched by ref_order. Open an order to review its currency totals and the Order Items inline. The source action is Create invoice; it skips an order when an invoice already exists and reports a warning in that case.

Open Invoices → Invoice to search by ref_invoice or filter by status. The list includes the user, invoice reference/date, order, USD totals, contact/address fields, status, remark, and timestamps. The edit page groups fields under Invoice, Price USD, Price THB, Price EUR, and Price INR.

The invoice page includes PaymentTransaction rows as read-only data. The source does not allow adding or deleting those inline payment rows. Check the payment reference, provider, method/type, amount, status, request/response text, and dates without rewriting provider history. InvoiceStatus also has deletion disabled in the legacy source.

Handle legacy content

• Videos: open Videos → Video. The list shows name, cover image, viewer, is_public, is_active, created_by, and timestamps. Open a row to edit the legacy record’s translated fields and visibility values, then verify the public media page.
• Testimonials: open Testimonials → Testimonial. The list shows avatar, testimonial/school attribution, website, region, message, is_active, and timestamps. Review the attribution before changing is_active.
• Contacts: open Contacts → Contact. The source list shows name, email, subject, message, and timestamps. Add and delete permissions are disabled; use the displayed contact details to reply through the approved mail process.
• Notifications: open Notifications → Notification. The list can filter read, creation time, notification time, and type, and search username or message. Confirm the recipient before changing a notification.

These steps are a legacy source map, not a claim that the same records, labels, or permissions are available in the new staging workspace.

Verification limits

The production backend admin URL and login screen were checked on 8 October 2026. No protected production staff session or record change was performed. The models and workflows below the login are source-reviewed; current staff permissions and record availability must be checked in the signed-in backoffice.

Do not use this page to document passwords, token values, payment-provider secrets, database settings, or deployment instructions. For any record that is not present in the new staging workspace, ask the system owner which system is authoritative before making a change.