It means that the changes require neither a code change nor a deployment.
In other words it is called as Dynamic Workflow.
Ease of modifications on workflows. People most of the time lack of having easily modifying workflow capability with their system. Especially when to often workflow changes are needed. Adding up one more step, creating a callback function right away and deleting them even for a specific workflow object when needed by just modifying it in the Database is giving to much flexibility. It also doesn't require any code knowledge to change a workflow as long as some user interfaces are set up for those people.
Again, ease of modifications on workflows. Having too much freedom sometimes may not be a good idea. Very critical workflows might need more attention and care before they get modified. Even though having a workflow statically defined in the code brings some bureaucracy, it might be good to have it to prevent accidental modifications and to lessen human errors.
There are different kind of workflow libraries for django. It can be
working either with dynamically defined workflows or with statically defined
workflows. django-river is one of those that works with dynamically defined
workflows (what we call that it supports on-the-fly changes) where as viewflow
is one of those that works with statically defined workflows in the code.
There are different kind of workflow libraries for django. It can be
working either with dynamically defined workflows or with statically defined
workflows. django-river is one of those that works with dynamically defined
workflows (what we call that it supports on-the-fly changes) where as django-fsm
is one of those that works with statically defined workflows in the code.
No. The way how django-river works is that, whenever one of your workflow
object is created, the state field of the workflow inside that object is set by
the initial field you specified. So it would be ambiguous to have more than one
initial state.
Yes. django-river allows that and as it circulates, django-river extends
the lifecycle of a particular workflow object with the circular part of it.
No. You can have as many as you like.
Yes. It functions like an or operator. One authorization rule is defined with multiple user groups or permissions and anyone who is any of the groups or who has any of the permissions defined in that authorization rule can see and approve that transition.
Can I have two authorization rules for one transition and have one of them wait the other? (Vertical Authorization Rules)
Yes. django-river has some kind of a prioritization mechanism
between the authorization rules on the same transitions. One that is
with more priority will be able to be seen and approved before the one with
less priority on the same transitions. Let's say you have a workflow with a
transition which should be approved by a team leader before it bothers
the manager. That is so possible with django-river.
Yes. The qualifier of a workflow for django-river is the model class and field name.
You can have as many workflow as you like in a Django model.
Yes. The qualifier of a workflow for django-river is the model class and field name.
You can have as many workflow as you like in a Django model.
Yes. The qualifier of a workflow for django-river is the model class and field name.
So it is possible to qualify yet another workflow with a different model class.
Theoretically yes but it is only tested with sqlite3 and all PostgreSQL versions.
Simply nothing. Existing workflow objects are not affected by the changes
on the workflow (Except the hooks). The way how django-river works is
that, it creates an isolated lifecycle for an object when it is created
out of it's workflow specification once and remain the same forever. So it
lives in it's world. It is very hard to predict what is gonna happen to the
existing objects. It requires more manual interference of the workflow owners
something like a migration process. But for the time being, we rather don't
touch the existing workflow objects due to the changes on the workflow.
The answer has ben yes since django-river version 3.0.0.
The answer has ben yes since django-river version 3.0.0.
The answer has ben yes since django-river version 3.0.0. django-river also
comes with an input component on the admin page that supports basic code highlighting.
There is none. It is applied immediately.
The answer is no unless you can make Django work with sqlalchemy.
django-river uses Django's orm heavily. So it is probably not a
way to go.
django-river provides two kinds of API. One which is for the object and one
which is for the class of the object. The Class API is the API that you can access
via the class whereas the Instance API is the API that you can access via the instance
or in other words via the workflow object. The APIs on both sides differ from each other
So don't expect to have the same function on both sides.
# Instance API
from models import Shipping
shipping_object = Shipping.objects.get(pk=1)
shipping_object.river.shipping_status.approve(as_user=someone)# Class API
from models import Shipping
Shipping.river.shipping_status.get_on_approval_objects(as_user=someone)You can see all class api functions at Class API and all instance api functions at Instance API.
approve is a function of Instance API not a Class API one.
It means the user that you are trying to approve with is not really authorized to approve the next step of the transition. Catch the error and turn it to a more user friendly error if you would like to warn your user about that.
django-river has behavioral tests that are very easy to read and write. One can easily set up one
and see if everything is running as expected. Please look at other examples (that are the files with .feature postfix)
under features folder that you can get all the inspiration and create one for yourself before you open an issue
Then refer to your behavioral test to point out what is not function as expected to speed the process up for your own
sake. It is even better to name it with your issue number so we can persist it in the repository.