Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://django-river.readthedocs.io/en/latest/faq.html below:

Website Navigation

• django-river

FAQ — django-river 3.2.0 documentation

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.

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4