Lots of goodies and I made some decisions. First what I got done:

Integrate Laravel Backback and use it to manage the ethnicities tables.

Done. Backpack is surprisingly good. Better yet, it's great at being integrated into places. No need to re-login or re-create users. Just plug in the user models and turn off auth and you're good to go! I plan on making quite a few of these tables, so I plan on learning more thoroughly.

Add another user with less permissions that can browse the system, then give that one out for people to use.

More than done! There is a super admin that I will only have access to. Those credentials are set up in the app.yaml through environmental variables so I only get to tdo them when I deply or refresh my db. However, I've created a slews of users so that I can test a lot of the features directly from those accounts. Plus this way I don't have to go impersonating..yet (it will be coming though). But I also made some accounts:

Staff Account: staff@kalinec.net / staff

Faculty Account: faculty@kalinec.net / faculty

Student Account: student@kalinec.net / student

Parent Account: parent@kalinec.net / parent

Coach Account: coach@kalinec.net / coach

At this point these accounts don't do much other than tell you your role. Except for the staff account, which actually has access to backpack and to view roles and permissions (but not edit/create).

Lock the CMS out of the public. Don't feel like dealing with people changing the blog

This should be done. I think. I hope?

Upgrade the stupid editor

Done! no one will get to see it yet, it is an editor based on tinymce with all the features turned on.

Tie in Google Cloud Storage.

Tied in through a disk that is tied to the CMS so that I can upload pictures in the blog.

Create the scheduler and do a full db refresh+seed every night but backup my blog posts.

This should be good. I made the cronjob and tied everything together. Will be testing it tonight.

Assuming it all runs well, I plan on publishing a .env.sample with all the necessary variables and all the yaml files (app.yaml, cloudbuild.yaml, cron.yaml, and dispatch.yaml_ as .sample files so people can deploy it if they want to, and for reference.

On to the updates.

The Person Object

As this will be one of the pillars that this system is built on, it is important to put a lof thought into how it is going to be designed. Understand that pretty much all things built in this system will eventually refer to a user, which is important to build this with a lot of room to grow and to leave enough hooks in so that it can be customized by things like plugins.  It also will be used a lot, even as placeholders. With this in mind, the minimum data that is required to enter on person object will be last name. Why only one and last name? experience. It so happened that I had a student at my school with a single name, just a first name. I will not mention it here, as it would be really easy to find them, but they were a wonderful kid and their parents decided to not give them a surname, only a first name. Basically, they didn't work on most DB's, but they did on mine! Mainly it was because I was asked to be able to create "place holder people" that my development department could use to enter information about people they were trying to contact, but didn't know all the info yet.  So I extended that system into the main system and that kid was able to display their name without any kind of weirdness attached ot it, as most dbs couldn't handle it.  For that reason, the only thing needed to enter a person will be their last name. Why not their first? Last is more common and it can double up as first in the "name" scheme.

But what other fields should we offer?  We want to really be able to throw the kitchen sink at these, as you never know what information could be useful. So let's define some basic ones that we can all agree on. Because a lot of these need to be "school-defined", will add a table designation next to the fields that will link to another CRUD table that the school will be able to define. Thus, we can define a (very) basic person record as:

A few notes. Why occupation, job_title, and work_company? wouldn't it be better to have a job history? Yes! and t will be added, but a lot of the times, admins and people accessing the record need to see fast information. They don't need to slog through work history, they need the quick facts. This is especially true in development. SO we put these fields for quick access and searching.

Salutations? Yes! because sometimes we would like to have a default salutation saved because Mr. Smith would really like to be address as Mr. Smith, Board Member at all times, so we add this to override all salutations or official names.

portrait_url/thumbnail_url why not something more in the cloud? Because we don't let kids (and staff too) pick their own damn pictures, that's why. Especially fucking parents, who will upload a fucking pic of their kid in a bikini and then have a fucking pikachu face when their kid is embarrassed and they're the talk of all the school come first day. So we specify the official pictures, we add permissions to lock people out of changing pictures and we add ways to mass upload pictures when, come picture day, we get a big dump of images. Oh, and we'll also need a way to make rosters for the photographers, but later :-).

Finally, the temporary fields are mainly authentication, which WILL be moved off to it's own system as we would like to have a very fine-grained approach to authentication backends.

So this gives us a start, we have a person object to build, then create and ...manage...shudder.  Yes, we will start on this system which will allow us to add roles as well as let users edit their own profiles, which also means permissions to edit/view fields and profile options. Finally, we need to incorporate search and search permissions and make that upper left hand corner search start working for us.

But first! As I was working on the blog system, it struck me how much I really need a CMS.  The upgraded editor was a huge help, and I'm for comfortable writing my posts now, but I do need to build my page with a contact, about, etc. So, I decided that I might as well build a small, drop in content management system that will be very basic. Since I'm doing this, I might as well spin it into its own project and make it a solutions for people, like me, that need something they can throw together that stays away from things like managing users or permissions. It will just content manage, have sensible defaults, and let user customize everything else though policies and route declarations.

So I will be starting another project, because why the hell not? that will spin off what I've built into something that will be a component. Of course, I will need to learn how to write components, which is a bonus. With that in mind here are the goals:

Publish the sample env and yalm files.

refactor the person object into the above

Add the ability to view all people in the system (this will eventually be deprecated, just a jump of point for now)

Add the ability to create new people

Include the start of a duplication detection system that prompts users before adding people.

Add a very basic person management system that will allow someone to edit basic information and maybe assign some basic roles and permissions.

Add and test soft deleting people.

Add a way to merge people. Include a way to expand it with new systems

Create a new Git project for the drop-in CMS

Learn and start authoring a Laravel package

Integrate it as a "replacement" in my existing environment.

This is actually quite a tall order. There is a chance I might be changing my mind on a few things, so I will update when I think I have enough to discuss.