Closed Eakam1007 closed 1 year ago
This is going to require us to pass down the ROOT_DOMAIN
from the back-end (env
) to the front-end, probably via a loader. Another option that might be better: in the back-end, when we create the user in the session, we could add a .domain
property, which would be {username}.{root_domain}
and then send that along in the loader that the root calls, so it's always available to the front-end code.
I suggest we specify minimum characters for each form field to prevent the user from being able to create domains with a single character. We can add a regex for Ports
form to check if the user has provided with numbers that are comma separated. We can also enforce a format for course that is similar to what seneca does i.e., 3-char followed by 3-nums
I wouldn't bother doing format checks on the optional fields. They are purely informational. Let's not hard-code in some logic for what a course code looks like, and then have some bug later where people can't enter their course. For ports, course, etc, we don't care what they enter.
From what I can see it just doesn't seem like there's point having those optional fields... If we're keeping them for informational purposes, at minimum it's a good idea to have a standard format students has to follow when adding them.
Maybe in the future we can provide faculty members the ability to filter out the table to only display dns records with course code "web322" as an example. Should make it a lot easier for viewing students websites for a specific course.
Based on https://github.com/DevelopingSpace/starchart/pull/243#discussion_r1117075338, we could add different validation for the DNS Record form fields based on what
type
of DNS Record it is.Alongside this, we should also show
.{username}.domain.com
on the right side of theDomain Name
field. This can be accomplished using<InputRightAddon>