It's been a hard month

It's been almost a month since my last update. Most of it was out my control, as school has started up and the last month of summer/first month of school are the hardest and I've been swamped. A lot of it also had to do with implementing the view permissions. It turns out it was pretty hard to do, but I believe that I have a good solution.

So, let's go over what was achieved.

DiCMS

Beef up the text editor, I need to be able to add links and lists and other goodies. 

Done! he editor has been updated to something a bit better. I can at least add bulleted items and color changes. At this point it if functional enough to be able to blog so unless I see something obviously missing, I'm sticking with this.

Beef up Grapesjs for better layouts.  Add more icons and look into the possibility of adding symbols

A slight change on this, mainly to tie in the new Image Manager system, as well as some more goodies. The main upgrade for this was better fitting divs so they're easier to see.

Add artisan backup command

Done! The system can now be backed up through Artisan commands.

Asset manager

Done, and the largest part of the update. It adds a new asset manager widget (build through Livewire) that lets users drag and drop images and use them in the text editor and grapesjs.

I will say that the Asset Manager was a really neat Livewire component. Which failed as soon as it was uploaded into GAE (Google App Engine). I swear I've had so many issues with this. What finally fixed is was a combination of creating a CORS file to deploy in my Google Storage Engine like:

[
    {
        "origin": ["*"],
        "method": ["GET","PUT","POST","HEAD"],
        "responseHeader": ["*"],
        "maxAgeSeconds": 3600
    }
]

 And then deploying it to the storage by doing:

gcloud storage buckets update gs://<BUCKET> --cors-file=cors.json

After that issue was resolved, then we needed to tackle with the fact that, for whatever reason, Livewire 3 insist on generating a facade class in the local cache. A comment on GIT saved the day, and I felt obligated to contribute back.

Finally, even after that, ImageMagick wouldn't load, which I used in order to make thumbnails. Since I didn't want to switch to GD over this, I found some Google Documentation on how to enable the extension. Essentially, I created a file named php.ini with the following contents:

; configuration for php imagick module
extension=imagick.so

Finally, this made it work.

FabLMS

Create the viewing permissions system, including the admin view and user view.

This was the hardest part of the whole thing.  It took me weeks to come up with a good solution and there was a lot of circular thinking going on. Here is how the system ends up working: there are 3 main sections to it, and it spans across 4 tables. Since we need granular control over each viewable field, I first created a table that would define each field that was viewable that I needed permissions for. I also found that just "listing them" was really complicated so I added a CRUD table that would hold the categories.

On the other side I added another table called Policies. Now just like my previous post outlined, I tied everything to an Employee Role (which I created and all Staff/Faculty will be tagged with it), a Parent Role, or a Student Role. Now, here is the important part, the policy describes what other Employees, Students, and Parents can see about this role, as well as whether a field can be edited by that role and viewed by that role.  For example, taking a look at the Employee Role you can see the first name default settings:

This means that Other employees, students and parents will be able to see an employee's first name. Also, Employees can all see their own first name, but not edit it.  This is done by using the following class diagram:

Along with this, there is a privacy setting that allows a user to select whether they would like to show the unenforceable fields.  However, having the people.view permission (which originally was needed to see a person, now it does not) will allow a user/role to view all information on a person.

Create the editing permission system and make all information editable

This is done, at least for the basic information. Not the portrait upload yet, but that will come soon.  Also, the permission people.edit will allow the user to edit all information.

Add addresses and phone numbers to the system.

Not yet. This will be addressed in this post.

Make "suggested" permissions and put them in the seeder, so they always come up.

This is done! it was a lot of repetitive work, but it's really good, I think. Login as a staff member to see it/play around in it.

No adding or deleting yet, but we need to be able to merge accounts, so we need to start work on this.

Not yet.

Looking Ahead

I was originally going to start working on the merge functionality first, but the field permissions simply took too long. Because of this, and the fact that I was working a lot, I decided to end it without starting the merge. I'm also interested in seeing how to expand the fields permissions, as all of them right now come from a single Parent Class, Person.

Instead of focusing on the merge component then, I decided to stop to write this post.  At this point, I'm going to put the merge off to one side and concentrate instead on more fields and an entirely different set of classes: Addresses and Phones.

Now, all people in the system will be able to have multiple phones and addresses. Parents will usually have at least a cell phone and a business phone. Sometimes, although less often now, they might even have a landline. Students starting as early as 3rd grade (or earlier, I know) will start having cell phones, but we will still want them to be able to share them with their parents, especially those mythical landlines.  Along with that, we will need to be able to show these fields and assign permissions, so that the seeders will need to be updated.

I also need to be able to start creating users and assigning them roles. I will continue with the idea of the trinity of users: Employees, Students and Parents, and begin to define each user along each of those archetypes.  In order to be able to do that though, I need to have an easy way to assign roles to people, so that will have to be done first.

Since I'll be assigning roles, it is also important to be able to do something special with one kind of role, but not another one. For example, a Staff or Faculty Role should only be assignable to an Employee Role, whereas only students should be able to access the class enrollment system.

This also speaks to a deficiency in the nomenclature when it comes to the Parent role. What we really mean is not Parent, but “Outsider” or “Visitor”, but those are simply too unfriendly. This leads me to believe that I should be changing the way my roles are built and base them on 3 "Base" roles that are hardcoded. The roles are the basic 3 that I talked about in my previous post:

Because there's really only 3 real groups here: employees because we hire them and manage them, non-employees, which we call parents but could be friends or some other role, and students

So what should the Parent Role really be named? Friend? School Associate? It might have to include vendors and substitutes at least in some cases, so even those names are not really broad enough.  We also need to be able to translate it into different languages, so we will actually be dealing with ID's instead. Mainly the roles table will need to have 3 roles added at ID 1, 2, and 3:

1 - Employee

2 - Student

3 - Parent

Yep, back to Parent. Why? because that's who we serve. Yes, the school will have vendors and friends, those will have to be tied to a Parent base account. Parents are our main customers (although I hate using that word), where the money comes from and who we're answerable to.  Since those will be the base roles, every Person record will be retrofitted to have at one base role. Further, each role, except for the base ones, will have a base role they're derived from. Those roles will give users some base permissions and abilities that other base roles will not have.

Make sure we realize that a Person record will have one base role, but can have multiple base roles attached. Yes, you can be a Parent and an Employee at the same time, but your base role should be main role. I might change my mind on a single base role though, not sure.

So with that, I have a list of my next updates:

1. Add Addresses and Phones to the system

2. Make changes to Roles to support the idea of the 3 basic roles

3. Add the role editor

4. Tie in the new roles, addresses and phones with the editor/view permissions

5. Create new people.

But let's not forget DicMS/Blogger:

1. Archive/Restore/Duplicate sites.

2. Previews!

3. More features to GrapesJS and CKEditor

4. Make the blogging system prettier!

I would also like to add content to the actual website and the README's.  Will update when done.