sirs / tasks
Requires
- php: ^8.1.0
- cviebrock/eloquent-sluggable: ^10.0
- laravel/framework: ^10.0
- venturecraft/revisionable: ^1.4
- dev-master
- 10.0.x-dev
- 10.0.0
- 9.0.x-dev
- 9.0.0
- 4.0.x-dev
- 4.0.12
- 4.0.11
- 4.0.10
- 4.0.9
- 4.0.8
- 4.0.7
- 4.0.6
- 4.0.5
- 4.0.4
- 4.0.3
- 4.0.2
- 4.0.1
- 4.0.0
- 3.0.x-dev
- 3.0.11
- 3.0.10
- 3.0.9
- 3.0.8
- 3.0.7
- 3.0.6
- 3.0.5
- 3.0.4
- 3.0.3
- 3.0.2
- 3.0.1
- 3.0.0
- 2.4.21
- 2.4.20
- 2.4.19
- 2.4.18
- 2.4.17
- 2.4.16
- 2.4.15
- 2.4.14
- 2.4.13
- 2.4.11
- 2.4.10
- 2.4.9
- 2.4.8
- 2.4.7
- 2.4.6
- 2.4.5
- 2.4.4
- 2.4.3
- 2.4.2
- 2.4.1
- 2.4.0
- 2.3.12
- 2.3.11
- 2.3.10
- 2.3.9
- 2.3.8
- 2.3.7
- 2.3.6
- 2.3.5
- 2.3.4
- 2.3.3
- 2.3.2
- 2.3.1
- 2.3.0
- 2.2.1
- 2.2.0
- 2.1.4
- 2.1.3
- 2.1.2
- 2.1.1
- 2.1.0
- 2.0.x-dev
- 2.0.12
- 2.0.11
- 2.0.10
- 2.0.9
- 2.0.8
- 2.0.7
- 2.0.6
- 2.0.5
- 2.0.4
- 2.0.3
- 2.0.2
- 2.0.1
- 2.0.0
- 1.3.0
- 1.0.2
- 1.0.1
- 1.0.0
- dev-9.0-dev
- dev-force-fresh-after-rest-save
- dev-psr0
- dev-psr4
- dev-documenting
This package is auto-updated.
Last update: 2024-11-18 22:38:07 UTC
README
Provides migrations, seeds, models, events, artisan commands, and jobs to support task management.
Overview
Tasks are to-do items to be completed by or for their Owners (polymorphic relationship). Tasks are described by their TaskType (Task belongsTo a TaskType) and their status is denoted by a TaskStatus (Task belongsTo a TaskStatus).
As of version 2.2.0 you can define a task router to route a user virtually anywhere when they go to the url of a task (see tasks.router middleware below). Also as of 2.2.0, you can apply global scopes to tasks in config/tasks.php (see Configuration below).
Versions
Laravel | Sirs\Tasks | ||
---|---|---|---|
10.0 | 10.0 | ||
9.0 | 9.0 | ||
6.0 | 4.* | ||
5.7 | 4.0 | ||
5.5 - 5.6 | 3.x | 4.0 | |
5.1 - 5.4 | 3.x | ||
5.0 | 1.3.x |
Installation
composer require sirs/tasks
Note: specify version 1.3.0 for laravel 5.0.x- If you are not auto-detecting service providers add
Sirs\Tasks\TasksServiceProvider::class,
to config/app.php - Vendor Publish to get the config file, migrations, default seeders, and default TaskRouter.
- Add your seeders to DatabaseSeeder.php.
- Any models that will be task owners must implement
Sirs\Tasks\Interfaces\Taskowner
which can be satisfied by usingSirs\Tasks\TaskOwnerTraits
- Create EloquentResources for your TaskOwner models. (optional)
Upgrading
to 9.0.0
In order to use the published factories, you must create a corresponding model in your application that extends the package model.
3.x to 4.0.0
get a fresh config and set it up.
If you have specified a fractal transform for a task owner you should replace it with an Eloquent Resource (see Task Owners below).
2.2 to 2.3
- You will need to add the following to your tasks config to make these items work:
'ui'=>[ 'chrome'=>'app' ],
You will also have to do a global search and replace due to a renamed task route:
route('taskShow’,
should be replaced withroute('tasks.show’,
Configuration
Customize TaskType and TaskStatus seeders to fit your project. Then update the config as needed. The config options are:
- apiPrefix: route prefix for the task api routes. Defaults to 'api'
- routeGroup: route group for task routes. defaults to
`
['middleware' => ['auth','tasks.redirect']]`
- owner_transformers: map of ownerTypeClass=>ownerTypeTransformerClass where transformer class is a Fractal Transformer. Defaults to empty array;
- global_scopes: Array of global scopes to apply to the Task model. Defaults to empty array
- taskToAction: A map of TaskType->slug => action. See config/tasks.php for examples
- router: Task router class name for use with tasks.router middleware. Defaults to published App\TaskRouter::class,
- bindings.models: use your own models that adhere to the relevant interfaces setting this. Example
... 'bindings' => [ 'models' => [ 'Task' => \App\Task::class, // where \App\Task implements \Sirs\Tasks\Interfaces\Task 'TaskType' => \App\TaskType::class, // where \App\Task implements \Sirs\Tasks\Interfaces\TaskType 'TaskStatus' => \App\TaskStatus::class, // where \App\Task implements \Sirs\Tasks\Interfaces\TaskStatus ] ], ...
tasks.router middleware
Register the task.redirect middleware in App/Http/Kernel.php:
protected $routeMiddleware = [
...
'tasks.redirect' => \Sirs\Tasks\Middleware\RedirectTasks::class,
]
Customize your taskActions map in config/tasks.php:
'taskToAction'=>[
/** examples:
* 'task-slug' => 'action_type:slugOrIdentifier'
* 'survey-task' => 'survey:surveySlug',
* 'schedule-appt-task' => 'appointment:apptTypeId',
* 'redirect-to-url' => 'url:/path/to/thing'
* 'custom-task' => 'custom:someIdentifier'
**/
],
TaskRouter class' resolve function in TaskRouter.php if you need custom task routing functionality:
public function resolve(Task $task){
$taskToAction = config('tasks.taskToAction');
if( !isset($taskToAction[$task->taskType->slug]) ) return null;
list($type, $identifier) = preg_split('/:/', $taskToAction[$task->taskType->slug]);
switch ($type) {
case 'survey':
return url('app-participant/'.$task->owner->identifier.'/survey/'.$identifier);
case 'appointment':
$url = 'appointments/create?appointment_type_id='.$identifier.'&attendee_id='.$task->owner->identifier;
switch ($identifier) {
case 2:
// $forTask = $task->owner->tasks->where('task_type_id', 1)->first();
break;
default:
$forTask = null;
break;
}
$url = ( $forTask ) ? $url.'&task_id='.$forTask->identifier : $url;
return url($url);
case 'url':
return url($identifier);
default:
return null;
break;
}
}
This function should return a url for use in the Laravel redirect() helper function or null for default routing.
Even if you've mapped a task type to an action above you can bypass the router by adding bypassRouter=1
to the tasks url. For example I can force task 383 to go the default task form with the url: /tasks/383?bypassRouter=1
As of version 2.3.9 the middleware will pass query string attributes on the original task url.
Example task type of task 123 routes to /monkeys:
http::project/tasks/123/food=fruit&drink=coffee
will redirect to http::project/monkeys?food=fruit&drink=coffee
Task Events
Task lifecycle events are built on top of models events.
- Sirs\Tasks\Events\TaskStarted
- Sirs\Tasks\Events\TaskCompleted
- Sirs\Tasks\Events\TaskCanceled
- Sirs\Tasks\Events\TaskDataUpdated
- Sirs\Tasks\Events\TaskCreated
- Sirs\Tasks\Events\TaskStatusUpdated (deprecated)
- Sirs\Tasks\Events\TaskWasCreated (deprecated)
- Sirs\Tasks\Events\TaskStatusWasUpdated (deprecated)
TaskTypeWorkflowStrategy
To help consolidate task lifecycle logic you can now create workflow strategy classes that allow you to write event handling code for all events fired by the sirs/tasks package.
TaskTypeWorkflowStrategy should live in app/Tasks and are constructed with the task and the event, and have methods corresponding to each of the TaskEvent types:
- TaskStarted -> TaskTypeWorkflowStrategy::started
- TaskDataUpdated - TaskTypeWorkflowStrategy::taskDataUpdated
Stubs for these files can be generated using the command:
php artisan tasks:workflow [task-type-slug|all]
Using all in place of a task-type-slug will generate Workflow strategy classes for all task types.
TaskTypeWorkflowStrategies are optional and do not need to be created for a task type.
Commands
- AutocancelTask - sets task status to task auto-canceled
- CancelTask - sets task status to canceled
- CompleteTask - sets task status to completed
- FailTask - sets task status to failed
- MissTask - sets task status to missed
- StartTask - sets date_started timestamp
- UpdateTaskStatus (deprecated use task->update())
- CreateTask (deprecated use Task::create(...))
- DeleteTask (deprecated use task->delete())
Task Owners
Models that will be task owners must implement Sirs\Tasks\Interfaces\Taskowner
. This is easily accomplished by using the `
Sirs\Tasks\TaskOwnerTraits`
trait on the model and giving the model a fullName method that returns the full name of the owner. TaskOwnerTraits gives the model a hasMany relationship to tasks.
You can optionally define a Eloquent Resource for task owner in the configuration:
...
"owner_resources" => [
User::class => MyUserResource::class
]
...
Task management screens
Version 2.3 introduces basic task management screens that allow users view tasks and update tasks statuses and due dates outside of task related forms.
These screens are at
Default task form
As of Version 2.3 there is now default task form.
The form asks whether the task is complete, and allows the user to set a status or leave the task pending if it is not complete.
The route
Task REST API
REST API Controllers for tasks, types, and statuses.
Who do I talk to?
- TJ Ward - jward3@email.unc.edu