I'm posting this from the console of my new tiny-cms that I had to cobble together, because there is simply no good laravel, drop in cms. I'm thinking I might write one, but not right now. On to the goals met:

Create a basic Person Model and Management system

Yes and no, this will be the main discussion in this post. The model is built, but it needs to be rebuilt and talk about the management system must be expanded.

Create Basic roles  and allow for adding custom roles.

This is done. All the roles are created and some permissions have ben assigned.

Create InternalUser and ExternalUser and determine how they will be kept and logged in. Add an admin page for them

So this is the big change. Originally, I was going to splig the users into 2 kinds, have 2 different models and 2 gates, etc. I decided instead that the Person model will be User model, meaning the (single) guard will always return a Person object when querying the logged in user. Authentication will need to be updated so that only people withese roles log in, and then all content can be differentiated by basic roles. This also means that content can be gated off by checking the type of user, or whether the user has a parent role.  The goal will be to integrate the parent portal and staff/faculty portal if a person is both (which happens often).

Create permissions and roles, add controllers/editors for them and integrate permissions.

This is done. A real nice interface was made for it. One that will be replicated and extended to keep patterns in the UI.  All the strings have been localized and seeders have been created where all the permissions/ roles will be kept for fresh new installs.

Create factories/seeders for all of these to have a working database with fake data to test.

Done! Not much to see yet though.

Create a simple external and internal homepage. We will eventually make the front side a CMS, where I will move this dev diary to.

This was the biggest pain in the ass. There is simply no drop in CMS that I could use in laravel. I tried pretty much all of them. Twill CMS was the best one I tried, but they all simply have to manage the users and security. So I made something stupid simply. I downloaded a theme from Start Bootstrap and used the Cerulean theme from Bootswatch Themes and made a stupid blog and at least I have a site!

Upload all of this to Google Cloud Build, tie in database, fix some fields

This was suprisingly easy. The trick was to define the database fields in the app.yaml file and a couple of extra options and it came right up. I will post up a full version of the app.yaml file once I upgrade this editor.

So now the system is looking pretty good. Except for the CMS, of course. There is simply no good drop-in laravel CMS that works without it hacing to get in the way. I have an idea for one, which I may write up, where the main thing is that it asks the user to put in their routes 2 funtions: adminRoutes and contentRoutes. These functions would define all the routes needed for each of the section of the CMS. You can then warp these routes around anything you need. Want to put them in in a sub url? Add a Route::prefix('/url') and it's now served from there. You can tie any middleware and requirmenets you want from there.  Finally, everything would be done through Policies that are optional and user defined.  I have the idea, I might do some parallell deveopment, but if I do it's onlybecause the simple CMS that I have to deal with now is pissing me off.

The next step is the most critical in the system: defining a Person. Being one of the core objets, it will probably end up being the largest (with class sessions being next contender). THis is because lots of things will be attahed to it, such as addresses, phone numbers, student records, parent recrods, etc. For this reason there will be some functions in the Person space that wil be critical. 

The first one is Adding/Managing a new person. Really it's managaging that is the tricky part. This is because managing will happen not just by an admin, but by the user themseleves, as this will be their record. Adding a user will be as simple as entering a last name. That is all that will be needed. After that, we go into the "management" section, where the magic will happen. Roles will be added here, user accounts will be created, addresses/phones/occupations/etc will be managed. It will be a collection of multiple forms that be a center that can update a person and everything related to one, which is basically almost everything in the system.

Although we think adding is simple matter, the verification for adding should not. One of the hardest things to manage is that person dupliucation WILL happen. It will be the goal of this system to make person merging, but if we can catch it before adding, then even better. For this, the only thngs needed to enter will be a last name, but they will be prompted to enter more, such as email, first name, etc. A List of potential users will then be listed in the ardent hopes that the user will go through them to avoid duplication entering.

Once entered the management system will take place, which will be built in small increments.  The first goal will be to edit basic information, assign roles, and login information.  Extra if we can start adding addresses and phone numbers.  But there should also be a way for the users themselves to edit some data. WHich also nesseciates a way for admin to decide what fields are editable by users.

All user deletion will be soft deletion. Merging will be the only time we actually delete a record.

The last 2 steps are tied together, which are person viewing and searching. Viewing will include a full profile, which means that viewing permissions must be attached, as certain users (such as students and parents) should never be able to see phone numbers of staff, but maybe staff can see students' addresses. All these permissions are way beyond IT's paygrade (although we're asked to make them), so our goal will be to make the system customizable enough to assign these view permissions, but also give a good default that meets good privacy standards out of the box.

Searching will also need to have some permissions, as who you're allowed to search for follows who you're allowed to see.  There will be a bigger discussion on this once we have a system built.

So this new, major subsystem will depend on one thing: the definition of a Person object. One of the things that a Person object will have to have are some fields that are school-customizable. Think like gender, title, ethnicity, suffix, etc. These originally were Enums in my system, but now they simply have to be editable fields by the school. This will mean a lot of tables that are CRUD-tables. For these we will be using a new system that I plan to learn Laravel Backpack.  I will be building a new subsystem with it for managing just these tables that are simple, form-filling tables.  These will be used at thet start to define person-related fields.

Now I want to start defining the Person object, but I'm a bit upset at this editor, since I can do some of the image stuff.  So I stopping here with a mini-update and these goals:

• Integrate Laravel Backback and use it to manage the ethnicities tables.
• Add another user with less permissions that can browse the system, then give that one out for people to use.
• Lock the CMS out of the public. Don't feel like dealing with people changing the blog
• Upgrade the stupid editor
• Tie in Google Cloud Storage.
• Create the scheduler and do a full db refresh+seed every night but backup my blog posts.

Once that's done I'll come back with a discusion on what the start of a Person object should look like.  Will update when that happens.