noahheck / office-forge Goto Github PK

This should probably be implemented as a trait/interface so it can be attached to multiple entities (projects, tasks, etc).

It will need to take into account the user's timezone for doing the date calculation.

I'll probably end up just usuing the same one I've used in the past, but I should spend at least a little time reviewing them. There might be a nice new one out.

We'll need to have a way to customize the details for the organization in order to do this, so let's go ahead and grab the organization's name as well.

The organization's timezone should become the default timezone when creating new users.

This might be the best way to handle the situation. The only downside is not being able to update the value of that through the UI, but there might be a library or process I can implement to do that later on as needed.

I want to see if there's enough overlap between and among these types of interactions that I could work through them in a process-oriented manner.

• Design interface (on paper)
• Design schema (on paper)

Scaffolding

• Run artisan make:model -a Process
• Add initial content to migration file; run migration ./artisan migrate
• Add resource routing for Process
• Make view directory for resource and add index view (copy from sibling directory)
• Ensure the blank state (e.g. when there are no entries in the list of that resource) is functional and attractive
• Create and process the Create action
  • Add create view (copy from sibling directory) and _form view
  • ./artisan make:request Admin/Process/Store, then fill in requirements
  • ./artisan make:job [--sync] Process/Create, then fill in creation process
• Make sure the list view is acceptable
• Create the Show action and template
• Create and process the Edit action
  • Add edit view (copy the create view, probably)
  • ./artisan make:request Admin/Process/Update, then fill in requirements
  • ./artisan make:job [--sync] Process/Update, then fill in update process

There are a few things I might not have thought about relating to teams, so let's go through some of them:

Teams might need to be temporary

I was thinking about how to implement a Project feature (with tasks, due dates, etc), and when considering how to control access to a project, I followed my default of restricting by teams. That doesn't necessarily seem like the best way to go about it though, because it leads to a decidedly unwanted situation.

If a number of staff are put into a team simply for the ability to restrict access to a Project, that team then has to exist into perpetuity. Think of 2 people from different departments in the company who happen to be paired together for a single project that takes a week to complete. If a Project is access restricted to a Team made up of just those two people, that Team has to exist forever, even if those two people won't work together again.

Having to maintain that Team (displaying it in the User's list of Teams and in the Admin Teams list, for example) forever doesn't seem too efficient. We'd need a way to archive/remove them from these views.

Organizations change

At BestNotes, we've gone through dozens of small organizational shifts, as well as a number of major overhauls. Having Teams be so central to the organization of the application, they almost have to exist in perpetuity.

In order to use Teams effectively, they really need to be thought of as transitive, and their life cycle processes clearly thought through and communicated.

For starters, to help ensure no data is ever lost or inaccessible, System Administrators (or some subset of them) should be able to access all content of the system.

There's enough content here now for the clean up to start to get unwieldy. Let's get in place some good copy edit, and implement the translation layer for everything we've done so far.

Also, make sure to get in place proper Form Requests for the Team interactions.

This could be very similar to what I did for Glassbowl, so hopefully I'll be able to reuse some of the code from that project here.

One thing I didn't like about the implementation in Glassbowl was "eager-loading" the response form for each thread within a discussion. I think to keep the resource payload lighter, I should load the response form from the server when the user tries to respond to a thread.

While doing this, see if the steps taken in #43 can be applied in the same order here.

Going through this crap again...

Spend some time trying to really think about the requirements (images, html availability, number of formatting options, etc)

Services needed:

• Meta
• Routing (?) - maybe next time
• Ajax
• Accept image uploads
• Collect images when new resource is created

I need to complete the design work for the Activities items described in #15. At this time, the Activities will include:

• Scope definition / description
• Tasks
• Documents / Files
• Discussion / Communication tools

Tasks should have a title, details, a due date, a user to whom it is assigned, and a completed status.

Later on, we'll be able to have discussions on the task items themselves, as well as upload files for them. For now though, these will be pretty straightforward task items.

I want users to know that we care about the accessibility of the application. For users not wanting this functionality visible, we can provide an option in their settings area to hide accessibility targets, but they should be present by default.

Allow user to:

• Edit details (name, email, timezone, job title)
• Change password

Also provide a container for setting system preferences, such as showing/hiding accessibility items

This actually needs to be implemented in a way to achieve 2 different goals:

• Allow the user to upload their photo
• Provide an easy way to generate a link to the user's photo for easily outputting an image for that user

File uploads are actually relatively simple. We can use Laravel's Request/UploadedFile implementation to accept the image file; we can use the Intervention Image library to resize and orient the photo correctly; we can use Laravel's Storage system to save the photo to the local hard drive.

Where things start getting a little hairy is when trying to expose an easy way to generate the HTML for the image tag regardless of the image status for the user.

If the user has NOT uploaded an image for themself yet, we should respond with a default placeholder image for the specified size (I still like the options for icon, thumbnail, and standard size photos).

If the user HAS uploaded an image, we'll need to get the correct version of the uploaded image (if they've uploaded more than one photo, we'll want to reference the latest version for e.g., caching) and use that version to generate the src attribute for the image tag. On that route, we'll have to verify the

You know, perhaps profile photos should be their own Model/Entity. That actually makes a lot of sense. If a model with a photo is attached to a document in some way (face sheet, for example), the HTML of that snapshot could contain a canonical img tag that points to an exact version of an uploaded image without having to worry about version dates and crap.

An IsPhotogenic trait could be attached to any Model that should have uploaded photos (Users, Files, Teams (?), even Projects). This trait could include the relationship to the UploadedPhoto Model (if appropriate), and contain the logic to generate the img tag for the current image for that Entity.

This should be a nice looking view of a task. It could have a big checkbox to indicate it's done status, a way to upload files for the task, and, when it's available, a discussion widget so progress and comments can be added to the item.

The administrator shouldn't have to assign a default password, at least as long as email functionality is setup for the installation. I don't like having anybody know the account password except for the person using that account.

If the installation has email stuff set up, we can provide an initial log in link when the user is created, and the user can request a password change from the main ui.

If the installation doesn't have email set up though, we'll need a way for the administrator to set an initial password which should have a flag for forcing a password reset or something.

We'll need to create a form control that lists the Teams in the system and allows selecting one or more of the teams. Then we'll need to have a db migration to create the structure tying the Processes to the Teams. We'll need to update the Process and the Team models to reference their relationship with the other.

• Create Team multi-select control
• Add migration
• Establish relationships between Process and Team models

This should be similar to how I did it in Glassbowl, so hopefully I can reuse some of the code for this process from that project.

I still like the idea of ResourceFiles, and being able to attach them to any number of different resources within the system. Right off the bat, I can think of the following entities that will need to be able to handle accepting resource files:

• Projects
• Tasks
• Discussions
• Processes
• Files

Make sure there is a check for the "completed" status done first.

Also, make sure the date calculations are correct across timezones. UTC time for the timestamp is appropriate; just make sure the translation to local time is appropriate as well.

Make sure to update tests after implementing assigned_to and owner_id

As I mentioned in #15, and especially in this comment, there's enough difference between projects and processes that trying to express their features with the same models is likely to result in neither of them being expressed very well. So let's do our best to describe the way the Process system will work that can be used to guide our work on that system.

The vision of a Process management system begins with acknowledging the following about processes:

• They are completed routinely; they may be invoked as needed or scheduled for completion ahead of time
• Their inputs and outputs are known ahead of time
• The roles of the personnel completing them are known ahead of time
• They are composed of one or more tasks that follow a specific completion order (though some tasks may be skipped); the output of one task may serve as input into one or more following tasks
• Each task may have several distinct sub-tasks (actions) associated with it
• Importantly, the entirety of a process should be expected to evolve and change over time; as a project, we should encourage and promote process improvement in our education, training, and within the software itself

Our first iteration of providing process management features will involve:

• Providing a back-office for designing processes; this will include:
  • CRUD activities for Process entities (with an appropriate version identifier; as the process is updated, the process version will be updated as well) (perhaps a db field flag to indicate that an instance of a Process has been created, so a new version of that process should be recorded when changes are made next)
  • CRUD activities for Process\Task entities
  • CRUD activities for Process\Task\Action entities
• Providing a front-office for instantiating instances of processes; this will include:
  • CRUD activities for Process Instances
    • Upon invocation of a Process Instance, the Process's current Tasks and Actions will be instantiated for that Instance
    • Instance\Task and Instance\Task\Action completion tracking
• Providing a front-office for reporting on Process Instances
  • Reporting activity might include:
    • Number of open Instances
    • Number of created Instances within a time frame
    • Number of abandoned Instances
    • Instance activity by user
    • Instance activity by Instance type
    • etc...

Processes

The process itself should have some textual/narrative content specified defining e.g., the purpose of the process, the reason for it's invocation, relevant regulations satisfied by completing the process, etc. A process instance should also have the ability to specify additional textual/narrative information about that instance.

A process should also be able to be restricted for instantiating and accessing only by members of specified Teams. Administrators should be able to instantiate/view/report on all Instances of all Process types.

Delete behavior for a Process entity should only be exposed if no Instances of a Process have been instantiated. Alternatively, an active flag of some sort can be utilized to ensure the no new instances of a particular process are created.

Process Instances should have an Owner attribute: a user to whom the responsibility of ensuring the Instances completion belongs. The owner will start out as the User who is instantiating the Instance, but may later be changed either by the current owner or by an Administrator.

Tasks

Tasks represent specific work items that need to be completed for the Step to be considered fulfilled.

Task Instances can have a specified due date, along with an assigned User to whom the responsibility for completing the Task belongs.

Like Processes, and Process Instances, the Task Instances can receive narrative information regarding that item. The Task narrative should generally include specific information on the activities to be done in order to satisfy the Task.

(Tasks will be the level at which Deliverables will be defined)

Actions

Tasks can contain any number of Actions. Actions can receive narrative information regarding them, and the Actions can be ordered within the Task.

Like Task Instances, Action Instances can have a specified due date, an assigned User to whom the responsibility for completing the Action belongs, and can receive narrative details regarding the item.

All of the Instance items defined here (Process Instances, Task Instances, and Action Instances) will:

• Have discussions attached to them
• Accept file uploads
• Accept a due date

I would very much prefer the visual design of these interactions to be very cohesive, and to feel almost like what completing a checklist on a piece of paper attached to a clipboard would feel like, that is, as though the entire Process Instance represents a single document.

Solid visual indicator showing clear completion statuses and next steps would be very good. Being able to expand/collapse different sections of the document as they are needed would be nice as well.

Basic user management right now (name, email, administrator, timezone, etc)

I'll need to do this eventually, and I should do it sooner than later anyway.

I should strive for 100% coverage of all classes in the Jobs namespace at least.

Article discussing the difference between projects and processes

One of the things I was excited about when I was getting started setting out to create my business was an idea that I could help businesses operate similar to how a McDonald's was operated. That is, there can be a prescribed way to do everything that needs to get done. Importantly, you really only needed to understand how to follow a process in order to get the work done; you didn't necessarily need to know how to do all the things ahead of time.

There's an efficiency that is gained when work is carried out according to a process, and that is illustrated when it's time to amend a process to remove, add, or change some behavior. The process is updated with the changed behavior, and the next instance of that process execution will include the modified activity.

In my mind, projects and processes share a lot of the same traits. The article referenced above made a nice distinction between the two:

• Processes - Standardized units of work with known starting and stopping points - the main activities carried out by an organization
• Projects - Units of work carried out to improve processes - variable starting and stopping points, and generally having a flexible scope

From my experience, examples of processes would include:

• New BestNotes implementation (training calls, documentation, etc...)
• McDonald's month-end (reports, inventory, etc...)
• Hiring/training new employees (paperwork, drug tests, uniforms issued, training tasks, etc...)
• BestNotes sales pipeline (demo, follow-ups, paperwork, implementation scheduled, etc...)

Examples of projects would include:

• Launching a new McDonald's menu item
• Putting together a training presentation for BestNotes staff
• Designing a way to spin up new web servers

I think it's worth pointing out that most organizations will follow a process when beginning a new project.

There is a lot of overlap between the concepts present in projects and tasks, especially with regard to how they can be expressed in software:

• Tasks - Both are primarily concerned with accomplishing tasks in order to move the business forward
• Documents / Files - Work to be done generally requires inputs and/or generates artifacts (signed contracts, statements of work, completed documentation, mockups, etc...)
• Communication - Multiple people working together need tools to communicate and collaborate
• Scope - What is expected to be done

Of course, they differ in a number of ways as well:

• Tasks - Process tasks are generally known ahead of time, and the order in which they're completed is generally linear (do this, then that) - Project tasks may not all be known ahead of time and can be expected to change throughout as more clarification around the project is surfaced
• Documents / Files - Process inputs and artifacts are generally known ahead of time (e.g., photo id and SS card as inputs and a completed I9 for an employment verification process) - Project inputs and artifacts will generally be different for each project
• Scope - A process' scope is generally stable and known at the time the process is begun - A project's scope is likely to change and/or not be known from the outset

It seems that having the same model in the software for both Projects and instances of Processes would be acceptable. The Process items would really be templated instances of this work item. They could have a default description, established tasks, and placeholders in the documents/files area for the known inputs and artifacts. A naming attribute on a project would make simple sense ("Spicy McChicken Launch", "Rcopia Integration", etc...), but a sub-name on a process component would seem to be more appropriate ("Employment Verification - Noah Heck", "Month End - January 2019", etc...).

Another thing that Processes and Projects have in common are people. One or more people will be responsible for and participating in the activities for both. Again, the people involved in a project may be more flexible (e.g., not all dev projects at BestNotes required input from somebody on the Profile Creation Team), while the participants on a process are generally known ahead of time (at least, you'll know that member of a particular team will be involved, HR or Marketing, for example). I guess you might consider these things to be "roles" with a requirement that only members of certain Teams can fill a particular role.

Projects and Processes both generally have a completion status: when all the tasks for that item are completed, that item should be removed from the participants' work queue/log/folder/dashboard/whatever.

Projects and Processes might both be suspended or terminated prior to their conclusion for a number of reasons. A sales pipeline might end if the client has chosen a different provider; an employment training process might end if the employee quits before it can be concluded; a software project might be cancelled if the client's funding doesn't get renewed. This creates a distinction between a "completed" status and an "active" status.

This is just going to be pretty bare-bone at this time, mostly just to get in place the skeleton for so many other things that need to get done. This will be foundational to a lot of the rest of the application though, and most of the things I do to get this in place will change quite a bit, so don't get too hung up on things.

I think having an "Assign to me" quick link would be handy

Situations when a password change should be forced:

• When a user is first created with a temporary password
• When an administrator has reset a user's password

The first time a user logs in following one of these situations, they should see a form prompting them to set a new password for their account. They will be unable to take any other actions within the system until that is done.

• Design interface
• Design template inheritance structure / implementation
• Implement nav bar in all templates

Go back and implement this everywhere where it makes sense to.

One are to be wary of is in the userSelect form field type. It may not be beneficial at all to have this in play there (or maybe it will; just make sure to see if it is or not).

Doesn't have to be very fancy, but I want to have a complete set of REST points for them.

This will apply to both Projects and Tasks at this time.