ewink's Coding Dojo SOLO graduation project!
I feel like this is going to be me in a few days, except I won't have anywhere near as much hair, won't be anywhere close to being as adorable as Miku is, and will be a real human male, rather than a fictional girl. So, I guess that's won't be me?
UPDATE: Yeah, it is me, without the kawaii...
Anyway, welcome to the GitRepo for my solo graduation project.
The web application is at
version 1.0 right now. For the record, MgRonald's is a McDonald's stand in often used in anime, which is why I chose it to be my
fake business for the purpose of this project. Weeb's gotta weeb.
When complete, this project will act as a mini-intranet Twitter style message board for a business' employees. Basically, a digital breakroom corkboard.
Managers at both the department and top tier levels will be able to sticky messages and add events to the system to ensure all users see things that will be affecting them and their departments.
To increase the systems usefulness, there will also be a time management system built into the BBS, allowing employees to clock in and out and track their hours.
For the purpose of this README, there are three classes of users. Superuser which could be considered top-tier level management (e.g. a store's general manager). Managers which would run departments (e.g. a restaurant's head chef, or a shift supervisor). Employees, which should be considered base-level hourly staff with little or no supervisory role. Admins, for the purpose of this explanation, are both Superusers and Managers. Users are all users of the system, regardless of admin level.
There are three primary functions of the BBS:
The purpose of the posting function on the system is to mirror a system similar to Twitter. Simple messages posted to a group.
The current version (1.0) allows site management to set 'departments'. Employee level staff will only see messages from their own department on their timeline, with a couple of exceptions.
Sticky posts, that are set by admins, are always at the top of the list and are not included in the pagination. They are identified as sticky posts by both the red border around the post, and the red bullhorn icon in the bottom right hand corner.
Storewide posts, also set by admins, have less priority than sticky posts, and as such fall below them in the post list, but still maintain priority over normal posts, so they are also not included in pagination. They have a yellow border and a yellow bullhorn icon.
The difference between STICKY posts and STOREWIDE posts are that STICKY posts can be and should only be restricted to a single department. Making a storewide post sticky will result in the post being double-displayed. This is something that can be possibly changed in a future version.
Below the priority posts, Employee level posts will be displayed. These posts are paginated to make the page from being too long. In v1.0, the list will update every 10 seconds.
Posting to the main timeline happens from the main BBS page. Adding a post will refresh the post list. An employee level user has no control over the post priority or what department the post is sent to (it will always default to the employee's department and level one (normal) post priority.
Manager level employees can set what department they broadcast their message to. It's important to remember that only users in the department you set will be able to see a department restricted post. Only manager level staff have the ability to view all department posts.
As well as department, managers can set whether or not the post will be stickied. Again, stickied posts should NOT be set as storwide, since those posts are sticky by default. A future version of the app should have the ability to set expiration dates on the sticky/storewide posts to ensure there isn't clutter and admins aren't forced to manually prune posts.
Replying to posts is as easy as clicking on the green reply icon! Doing so will take the user to the post's display page, which will only show the post selected and that post's replies. You can also access this page by clicking on the post date hyperlink.
On the post page there is another
textarea input box that will accept a reply to the origional message. Replies will not display
in the BBS main page. The number of replies are displayed, so it's a simple task to go to the post page to see the replies.
Replies cannot be posted to a different department than the parent post. Replies cannot be set to sticky.
Replies each have their own post page and can accept likes and replies as well. Both posts and replies can be deleted from their page. Editing posts is NOT allowed. This may be changed in a future update.
Users are provided a profile that will allow them to upload a custom picture and set a biography. There are no programming rules to either of these fields, so they would have to be set by management policy.
In v1.0, all images are resized during upload to 500px wide or 500px high, maintaining the aspect ratio. It is encouraged to use a square image so the reshaping of the post avatars will still look good.
After upload, images are changed postwide, so all images of the user will reflect the uploaded image.
For the demo site, images are stored off site in an Amazon S3 bucket. Old images are not deleted when no longer used, so eventually a function will need to be added to handle that. A default image is provided for users that have not uploaded their own image.
Included in the BBS Home page is an event summary box. This will display events that have been setup to be relevant for the user.
Like posts, events can be set to be restricted to departments (for instance, if there is a training class for a new grill, the front of the house staff wouldn't care about that or need to know). There are also storewide events which are displayed for all.
The summary is not paginated, but it is reduced to only display the next 5 relevant events.
The user has two options. They can click a link to view all the relevant posts (if there are more events than 5, otherwise the list display will be the same as the BBSHome list), or they can click on the post its self and view the event details.
Management level users have the ability to CREATE NEW, EDIT EVENT, or DELETE EVENT.
Old events (events where the END DATE has passed) remain in the database but are no longer displayed.
The application's Time Management System (TMS) as it is right now is rather simplex. It tracks the time you clock in, the time you clock out, and the time elapsed between those two 'punches'.
Using the single click punch method of clocking in or out, you simply click the 'CLOCK IN/OUT' button on the BBSHome page. This button will offer you only the option of clocking in if you are shown as being clocked out. Conversely, if you are shown as being clocked in, it will only provide you with the option of clocking out.
Mistakes happen and sometimes people forget to clock in or out. This is what the 'oops' hyperlink is for!
If a staff member has forgotten to clock in or out, clicking the link will allow them to manually enter the date and time of when they should have clocked in or out. Once that is submitted, they will be able to clock in or out via the Single Click Punch method. This can also be used to enter in sick or vacation time in a very basic way. Functionality to more directly add PTO could be included in a future update.
On the user's profile, the last few punches are show, sorted from most recent to oldest in the display range (10 by default).
The punch ID, clock in, clock out, and total hours:minutes worked is displayed. In version 1.0, there is no method for editing or deleting time through the front end, though all time punches can be edited or deleted via the backend administration. This is not the prefered method and would be changed in a future update.
As well, in version 1.0 there is no method for calulating the weekly total of time worked. Again, the TMS is a very, very simplex system designed, as of now, to do nothing more than track time and durations. Future updates would hopefully allow for the 'declaration' of a work week and more complex time tracking processes.
The back end of the application is built using Django v2.2. Django's built in user authentication was used and built upon for the application.
The back end also calls upon, in part, some of the following libraries:
Thanks for checking this out!