Opened 5 years ago

Last modified 2 years ago

#15015 new New feature

Mixing read-only with ability to add new instances using a FormSet

Reported by: coleifer Owned by: nobody
Component: Forms Version: 1.2
Severity: Normal Keywords: formset
Cc: apollo13, jdunck@…, wiml@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

A little background, I've been attempting to add permission-awareness to admin inlines using a technique like the one mentioned here:
http://code.djangoproject.com/ticket/8060#comment:9

The problem occurs when I want to allow a user to be able to add new inline instances, but display the pre-existing ones as read-only. By overriding the get_readonly_fields() method in the event the user doesn't have change permissions, I'm able to make everything read-only...but this includes the formset's "extra_forms", or when the user clicks to add a new row.

Since read-only is an admin thing and is implemented in the formset-level as "exclude", it's going to be kind of tricky to tell, using just the FormSet API, which fields are actually excluded and which are just read-only. I would propose making readonly_fields an attribute of the form, just like exclude. Additionally, it makes sense to me for any 'extra_forms' on the FormSet to display all non-excluded fields as editable. Having a read-only field on a form that does not contain any data is odd.

Change History (10)

comment:1 follow-up: Changed 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

The complication here is that *forms* have no concept of readonly fields -- that's an admin-specific feature. By extension, formsets don't have any knowledge of readonly fields either. This is by design; we added readonly fields as a specific admin feature, not as a general feature of the forms library.

However, I can accept the use case; marking DDN because we need to work out the details of how to expose this as an admin feature.

comment:2 in reply to: ↑ 1 Changed 5 years ago by coleifer

Replying to russellm:

The complication here is that *forms* have no concept of readonly fields -- that's an admin-specific feature. By extension, formsets don't have any knowledge of readonly fields either. This is by design; we added readonly fields as a specific admin feature, not as a general feature of the forms library.

Totally, I'd propose moving the readonly behavior into the forms API and converting the admin from a special-case to a general one.

comment:3 follow-up: Changed 5 years ago by russellm

And I'm saying that ain't gonna happen. Leaving out readonly widgets from the forms library was a very *specific* design decision. Check the archives for the discussions on the topic.

comment:4 in reply to: ↑ 3 Changed 5 years ago by coleifer

Replying to russellm:

And I'm saying that ain't gonna happen. Leaving out readonly widgets from the forms library was a very *specific* design decision. Check the archives for the discussions on the topic.

Fair enough. I think my initial use case is still valid, basically allowing read_only fields to be specified for admin inlines, but having those read_only fields not affect adding new rows (i.e. you can't edit existing inline items but can add new ones). This jives a lot with the "can_add" vs "can_edit" permission workflow.

comment:5 Changed 4 years ago by anonymous

  • Severity set to Normal
  • Type set to New feature

comment:6 Changed 4 years ago by jdunck

  • Cc jdunck@… added

comment:7 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:8 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:9 Changed 3 years ago by wiml

  • Cc wiml@… added

comment:10 Changed 2 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted
Note: See TracTickets for help on using tickets.
Back to Top