Jobeet
Jobeet/Jobim
"Jobeet" - originally, a Symfony tutorial app use case that is a fully functional jobs site .
- Chapters up to 19 for Symphony 2.
- Original Jobeet (Symfony 1)
The laconic/DRY design package in the next § moves with working target. Other top level stuff below it.
Day 0 Refactor for DS
Story Rewrites / Additions
Jobeet for DS/PM is the heart of my use/implementation of the Public Job Shop. It retains much from the original, updated for Symfony 2 and inverted to its purpose in PM/PJS.
F0: The user is defined per PM
The tutorial did not really address registration or the like, there's actually only admin and anonymous class and the later are created and defined by use of the job posting form. In Jobim, a DS/PM SSO is operative.
F1: On the homepage, the user sees the active biz cases
The homepage displays the lines of biz and the cases the practitioner wants to pursue, exemplifying the refactoring of the original.
The search function is essentially the same but with the shown altered target domain and changes in the field targets as well.
F5: A user posts a job
The Post a Job form becomes sensitive to the users PM role:
none
The original function of the posting form is preserved for the anonymous user. The disposition of the post is determined by the practitioner and may be either kept local or posted to the general PJS.
customer
A posting by a customer is interpreted as a job order in PM/PJS.
merchant/peer
A posting by a user with this role is a job order which the user is handling as a broker.
F6 A user becomes a LoBAffiliate
This is automatic based on the user having merchant/peer role.
F7 A LoBAffiliate retrieves the current active job list
The LoBA may select from either the practitioners cases, all those active in PJS , or both.
F8 A mobile app for iOS and Android
"Jobim", as a product name, is only used for the Cordova app of this feature:
- webviews for non-desktop form factors.
- adds a notification service to the affiliate service as originally defined and modified per the reinterpretation of affiliation
- other controls/subfeatures. Small factors will have a small subset of other feature sets, but are the target of the notification service
F9 JobsSite Entity and Job Form changes for it
Elements are added to both model and view to associate a jobs site such as Craigslist (that is the specific main target), Monster, etc. with the Job posting/order.
B3 An admin manages the affiliates and jobs sites pulls
PJS is populated largely from feeds from jobs sites stimulated by the job postings and collected either by agents running in the practitioners domains or by PJS itself (i.e. in my domains).
F10 PJS is populated with scrapes from job sites
This is done in PJS but the FE for it is here.
Meaning Here
In the context of my softwares, the Jobeet original use case has been reworked to a completely different use case and a serious production function in my space:
- Job Categories replaced by Lines of Business
- Two kinds of Jobs, those entered via Doctrine programmatically are actual completed jobs in such lines of business, others job orders
- CategoryAffiliate is replaced in the model by LoBAffiliate
The first refactoring was complete in early 2014-05.
The first refactoring is fairly superficial. The jewel of the refactoring centers on the LoBAffiliate and remodeling it as job sites such as Craigslist, monster, etc. The design intent is that the practitioner can look for related work and those recruiting can post jobs to the Public Market in addition to the attention of the specific practitioner, initially just me.
As a name for standard biz case working pattern
I'm also using this term to refer to an encapsulation of the standardized approach I've developed for working jobs. The specific elements vary, but a timeline, sources in FishEye/Git, and a support network as a WordPress multisite and generally included.
Carries Symfony-Drupal Salient
DS users (initially just my clients) will be able use my space without registration by supplying a single secret, generally known on a group basis. They then can access any resource for which they know another group secret, supplied either operationally and implicitly such as in a URI path member or explicitly bu supplying the role name/id secret.
Primary user identification is performed by a third party or transmitted cert.
