I think I might be able to keep this going, especially if I'm able to release substantial updates. I had both major updates in DiCMS and FABLMS, with DiCMS having its own blog now! In this blog I'll still be doing only FABLMS. So let's go over what was done:
Add Addresses and Phones to the system
Done! Yes, addresses and phones are added, with a duplication-catching system for both. They're also included in seeders so people will always get at least one of each. I've also added relationships! essentially, it is a way to create links between people with a tag. After long thought I've decided that these relationships should be reciprocal, meaning they both must be attached to each other through a tag. Thus, a Parent (I've decided to go with gender-neutral tags, as I don't want to deal with genders) has a relationship to a Student through a tag of PARENT, while the same Student has a reciprocal relation with the tag CHILD. I've chosen to use CHILD as a simple tag for all relations, no matter if they're a step parent or a grandparent.
Make changes to Roles to support the idea of the 3 basic roles
Not a thing anymore. I played around with the concept, didn't like it. Honestly, I'm hating the current view permissions. I like the user simplicity, I hate everything else. It will have to change.
Add the role editor
Yes! This is now done!
Tie in the new roles, addresses and phones with the editor/view permissions
Yes, also done. But barely. This is because I really don't like the viewing permissions system. It will be changed.
Create new people.
Yes! I also added a new, simple directory. It will evolve into a data tables incarnation, but it is not needed yet.
People are in a Good Place
What I man by this is that, although not even close to complete, the People section of the LMS trifecta is at a place where it is starting to grow to the point it needs the rest of the support. I put up this diagram in a previous post:
On the left side are the three components needed to make classes to generate the output. We have been working on People side and have all the major points done: Roles, Access, Preferences, Relationships. We are not yet ready for Users, so we'll keep that simple and there's still a lot of polishing that needs to happen, but I ran into a point while seeding people that made me pause.
One of the improvements in this new version is that I've split the seeding into categories of roles and further created the idea of a family seeder. So if you take a look at the code, there will be new seeders for each important employee role. the AdminSeeder will be responsible for accounts that we can login to, while the StaffSeeder, FacultySeeder, and CoachSeeder will seed each into it's own role. It looks really meager now because there' not much we can link to it, as there is nothing else built. FacultySeeder will be responsible for actually placing Faculty into Classes, but we can't do that with out at leas some of the other two requirements: Subject Matter and Locations. Students and Parents are handled differently. Instead, I'm starting the concept of a FamilySeeder, where instead of seeding people as students or parents, I make a student and build a family around them so all their phones and addresses are linked (just like in real school), and they have parents, step parents, and families of different sizes. I came up with what I think is a good distribution for a school (it might change):
10 faculty - each with it's own subject
4 staff
1 coach
65 families
5 students per grade (K-12)
1-4 parents per student (parent, step parent and grandparent combination, with spouse possibly thrown in the mix)
Some kids should be siblings in the same grade
Some kids should be siblings in different grades
Parents should share addresses with students
Parents should share phone numbers with students
I got quite far in this list, when I realized how much I lacked in terms of grade level. Grade level (or year level, or something else), is an integral part of a school, as it determines quite literally everything in a Student's record. I got quite stuck with out the Location information, which will inform me of campuses and which grades they contain. I'm at the point where I could continue with People, but I require so much of the other two components (and will only require more the more I build) that I though it wise to take a step back and focus a bit on the other two, starting with Locations.
Locations entail a few, very specific set of components:
Campuses - This is the physical or virtual location where learning takes place. This is the next biggest container that holds everything, with the largest being the School. This location defines what grade levels are taught this location. It is also the base container for Rooms and are co-owners of Semesters.
Years - This is the temporal location where learning takes place. It is the time it takes from a student to move from one grade level to the next and that students at the top level are “graduated”.
Semesters - Are a combination of Campuses and Years. Semester is just what I will be using internally, they could be considered quarters, or terms, or whatever. At the end of one, a final assessment is due.
Rooms - The physical or virtual location where the classes take place. They are more than rooms, really, they could be buildings or zoom rooms, etc. But a room is what I call a unit of space the the actual class takes place.
The diagram looks like this:
This should not take that long, as it will not have many bells and whistles, but it will allow me to start thinking about tying it in with people to create students, or to move on to the Subject matter to tie to Faculty.
With that in mind, these are the goals for the next release:
Create Campuses and allow the editing of them
Create Years and allow the editing of them
Create Semesters and allow the editing of them
Create Rooms and the structures around them to begin creating a school
Seed all these new components.
And for DiCMS:
More blocks, especially tables
Auto save content for backups
More decorations on blogs, like next or previous
Widgets