This issue tracks the implementation of the Jazzband guidelines for the project django-formtools

It was initiated by @felixxm who was automatically assigned in addition to the Jazzband roadies.

See the TODO list below for the generally required tasks, but feel free to update it in case the project requires it.

Feel free to ping a Jazzband roadie if you have any question.

TODOs

• [x] Fix all links in the docs (and README file etc) from old to new repo
• [x] Add the Jazzband badge to the README file
• [x] Add the Jazzband contributing guideline to the CONTRIBUTING.md or CONTRIBUTING.rst file
• [x] Check if continuous testing works (e.g. Travis-CI, CircleCI, AppVeyor, etc)
• [x] Check if test coverage services work (e.g. Coveralls, Codecov, etc)
• [x] Add jazzband account to PyPI project as maintainer role (e.g. URL: https://pypi.org/manage/project/django-formtools/collaboration/)
• [x] Add jazzband-bot as maintainer to the Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-formtools/users/)
• [x] Add incoming GitHub webhook integration to Read the Docs project (e.g. URL: https://readthedocs.org/dashboard/django-formtools/integrations/)
• [x] Fix project URL in GitHub project description
• [x] Review project if other services are used and port them to Jazzband
• [x] Decide who is project lead for the project (if at all)
• [x] Set up CI for Jazzband project releases if needed and open ticket if yes

Project details

Django 3.0 will soon be out there, and the latest release of django-formtools cannot work on Django 3 because Python 2 support was dropped (no django.utils.six anymore.). I can see that Python 2 (and therefore usage of six) is already dropped from master here. But until there is a release, it's not possible to use this on Django 3. Please do some release and publish it on pypi so that django-formtools can be used with Django 3.

I have a use case where I inject extra steps (dynamically, in some cases), and this was the only change I needed to make.

Is there a reason that this line is not already using self.get_form_list()?

Django will remove the vendored django.utils.six in the upcoming 3.0 release. six is in use in django-formtools for normalization of string types and iteration.

Since I see that the next version of django-formtools will drop support for Django versions 1.10 and below, and will add support for 2.1, the smoothest experience for everybody concerned would probably be to depend on six directly for a bit?

Originally reported in #23792. Should we use the freeze_time() contextmanager proposed there? If so, it seems we'll have to drop compatibility with Django 1.7.

The release from 2h ago is breaking python 2.7 (in my case tests). It is clear that you wanted to deprecate the support for python 2.7 . But for pip to not allow the installation on python 2.7, https://github.com/jazzband/django-formtools/blob/bffb403ceaca78563548dd01d1103373f12c80ac/setup.py#L135 needs to be: "Programming Language :: Python :: 3 :: Only",

"Programming Language :: Python referes to universal python (2 and 3), which caused PyPi to allow the installation of 'django-formtools==2.2' on python 2.7.

Same as https://github.com/jazzband/django-formtools/blob/bffb403ceaca78563548dd01d1103373f12c80ac/setup.cfg#L17 which also should be deleted to prevent mixups, also the meta information in setup.py are more important for PyPi's 'match making' I think.

This removes the undocumented get_form_list since the process of repeatedly and dynamically generating an OrderedDict of steps/forms pairs leads to infinite recursion. This is replaced with a new method process_condition_dict which directly modifies form_list in place, in a single step executed prior to dispatching to get or post. This eliminates infinite recursion since the form_list is calculated exactly once prior to any other attempts to access and process forms.

Removed test_form_condition_unstable since this is an odd test (why would a condition_dict return value suddenly change in the middle of a request/response cycle?) that was attempting to deal with invalid steps (invalid steps are better handled through actual validation, see #224).

For users who need to dynamically add forms, this can be handled by overriding process_condition_dict.

I have been struggling with this for a long time. Will you please help me on this. This is not letting me sleep for a long time. Please help. My view `def daily_report_create_view(request): district = 'Natore' if request.method == 'GET': form = DAILY_REPORT_FORM(request.POST) g1_form = G1_FORM() g2_form = G2_FORM() g3_form = G3_FORM() g4_form = G4_FORM() g5_form = G5_FORM() g6_form = G6_FORM() g7_form = G7_FORM() g8_formset = G8_FormSet(request.POST)

elif   request.method == 'POST':
    form = DAILY_REPORT_FORM(request.POST)
    # familyMemberFormeset = FamilyMemberFormSet(request.POST)
    g1_form = G1_FORM(request.POST)
    g2_form = G2_FORM(request.POST)
    g3_form = G3_FORM(request.POST)
    g4_form = G4_FORM(request.POST)
    g5_form = G5_FORM(request.POST)
    g6_form = G6_FORM(request.POST)
    g7_form = G7_FORM(request.POST)
    g8_formset = G8_FormSet(request.POST)

    if form.is_valid() and g1_form.is_valid() and g2_form.is_valid() and g3_form.is_valid() and g4_form.is_valid()\
            and g5_form.is_valid() and g6_form.is_valid() and g7_form.is_valid() and g8_formset.is_valid():

        print(g8_formset.cleaned_data)


context = {
    'form': form,
    'g1_form': g1_form,
    'g2_form': g2_form,
    'g3_form': g3_form,
    'g4_form': g4_form,
    'g5_form': g5_form,
    'g6_form': g6_form,
    'g7_form': g7_form,
    'g8_formset': g8_formset
}

return render(request, 'morningReport/report_create.html', context)`

My template: ` {{ g8_formset.management_form }} {% for link_form in g8_formset %}

        {{ link_form.as_p }}


    </div>
{% endfor %}`

Hi all, I'm trying to translate my django app, and all aspects work except for the formtools wizard, specifically the strings assigned to my multistep forms. In Urls.py I have:

named_formwizard_forms = ( (('Your Details'), FormStepOne), (('Residence Preference'), FormStepTwo), (('Immigration & Schooling'), FormStepThree), (('Mobility Expenses'), FormStepFour), (_('Living Expenses'), FormStepFive), ) urlpatterns = [ path(_('form/'), FormWizardView.as_view(named_formwizard_forms),name="form"), ] When I makemessages, the strings show up in my django.po, and while i have translated them to french, they either do not compile or there is some format I am missing in the template. Please advise.

Thanks

Hello,

I would like about new PyPI releases of django-formtools. Django 1.10 was released. 46b6839fb0063fa10ffb896ce80f7155ca7a9f6e contains fix for django 1.10 compatibility (below are stacktrace without that). 54f1ccca01e1a2d2062ad76af9c559723edd435c proves that django-formtools is django 1.10 compatibile. I think is good to release django-1.10-compatible version of django-formtools.

$ python manage.py test feder --keepdb
Using existing test database for alias 'default'...
...................E........................................................................................
======================================================================
ERROR: test_permitted_user (feder.letters.tests.test_view.ReplyPermissionTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/adas/Devel/feder/feder/letters/tests/test_view.py", line 85, in test_permitted_user
    response = self.client.get(self._get_url())
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 529, in get
    **extra)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 333, in get
    return self.generic('GET', path, secure=secure, **r)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 409, in generic
    return self.request(**r)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/test/client.py", line 494, in request
    six.reraise(*exc_info)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/exception.py", line 39, in inner
    response = get_response(request)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response
    response = self._get_response(request)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 187, in _get_response
    response = self.process_exception_by_middleware(e, request)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 185, in _get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/utils/decorators.py", line 185, in inner
    return func(*args, **kwargs)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/django/contrib/auth/decorators.py", line 23, in _wrapped_view
    return view_func(request, *args, **kwargs)
  File "/home/adas/Devel/feder/feder/letters/views.py", line 94, in __call__
    return method(request)
  File "/home/adas/.virtualenvs/feder/local/lib/python2.7/site-packages/formtools/preview.py", line 58, in preview_get
    context_instance=RequestContext(request))
TypeError: render_to_response() got an unexpected keyword argument 'context_instance'

----------------------------------------------------------------------

I looked over all the changes since the last tag and the changelog seemed correct, so I'm just optimistically placing the date in the changelog to today.

The latest release broke a documented feature.

Regardless of how this situation will be solved, I propose to improve automated testing. Here are some of my suggested changes.

It includes a currently @unittest.skip() marked test (FormTests.test_form_condition_callable) which leads to a RecursionError due to using get_cleaned_data_for_step in a condition_dict callback.

Previously, bots could and would stuff this form value with all kinds of nonsense, triggering a server error (and subsequent alert emails). Supersedes #47 and should fix #38

Please see #220, this is causing a lot of problems as a breaking change was accidentally introduced in 2.4.

It might be that there is a "better" fix in #221 or via another solution, but I think the priority should be to release 2.4.1 with this PR in and the original functionality fixed.

This would buy time to find a better solution that allows for the request of #168 to be implemented without causing the problems that the original change caused.

Thank you for this fantastic package.

This shows a possible approach we can use to fix the infinite recursion that can be triggered by referring to step data from condition_dict callables.

We have a condition_dict containing the following function:

def need_further_steps(wizard):
    data = wizard.get_cleaned_data_for_step("0") or {}
    if data.get("no_invoices_needed", False):
        return False
    return True

The call to WizardView.get_cleaned_data_for_step then calls WizardView.get_form, which used to reference self.form_list, but the following commit changes this to self.get_form_list(), which then calls the user-supplied condition_dict functions, which then calls our need_further_steps function above, which calls WizardView.get_cleaned_data_for_step, and so on ad infinitum. https://github.com/jazzband/django-formtools/commit/533a83053deab2adeb72de079e813aae78b03c1a

Perhaps our custom condition function is bad, but it doesn't seem too unreasonable?