#3: Provide ways to hide advanced options from classes of users

Contents
  1. Motivation
  2. Proposal
  3. Implementation
  4. Risks
  5. Progress log
by Steve McMahon — last modified Jan 22, 2010 06:26 AM

Site admins should be able to use a configlet to control the level of complexity revealed to different classes of users.

Proposed by
Joel Burton
Seconded by
Steve McMahon
Proposal type
User interface
Assigned to release
State
completed

Motivation

As Joel Burton put it in a #plone chat:

the problem with both ploneformgen and ploneformmailer, for many people, is that they're too feature-rich for small sites/simple users, who panic at the more obscure questions ("encrypt my email? huh? tales expression--wha?")

This problem will only be aggravated if the product development is responsive to all the option requests from those with less common use cases.

Proposal

I'm mixing in implementation here, but this is a first draft.

We'd probably need to add one or more permissions to guard advanced-usage fields. A configlet could control how these map to user roles.

It's also beginning to be clear that PFG will have a variety of action adapters. As of 2006-11-05, there are at least three new ones in the works. All have use cases, and will be great additions, but this will further complicate the way the product presents.

One solution is similar to the advanced fields solution: have a permission guarding each, then use a configlet to allow admins to associate the permissions with roles.

It also may be desirable for site admins to be able to choose which action adapter(s) get created inside a new form folder.

Implementation

Following are proposed Field -> Permission mappings. This would add three new permissions: ADVANCED_USE_PERMISSION, EDIT_ADDRESSING_PERMISSION and USE_ENCRYPTION_PERMISSION. The basic idea is that users with no special permissions would see only the most straightforward options.

A configlet will make it easy for site managers to map roles to permissions (which will affect security declarations at portal root).


Form Folder

  • No Special Permission
    • Submit Button Label
    • Show Cancel Button
    • Action Adapter
    • Thanks Page
    • Form Prologue
    • Form Epilogue
  • EDIT_TALES_PERMISSION
    • Custom Success Action
    • Form Setup Script
    • After Validation Script
    • Header Injection
  • ADVANCED_USE_PERMISSION
    • Custom Form Action


Mail Adapter

  • No Special Permission
    • Subject
    • Body (prepended)
    • Body (appended)
    • Body (signature)
  • EDIT_ADDRESSING_PERMISSION
    • Recipient's full name
    • Recipient's e-mail address
    • CC Recipients
    • BCC Recipients
  • ADVANCED_USE_PERMISSION
    • Extract Recipient From
    • Extract Reply-To From
    • Extract Subject From
    • Mail-Body Type
    • HTTP Headers
    • Additional Headers
  • EDIT_TALES_PERMISSION
    • Mail-Body Template
  • USE_ENCRYPTION_PERMISSION:   
    • Key-Id


Save-Data Adapter

  • No Special Permission
    • Extra Data
    • DownloadFormat
    • Include Column Names
  • DOWNLOAD_SAVED_PERMISSION:
    • Saved Form Input


Form Fields


  • No Special Permission
    • Rows
    • Max Length
    • Size
    • Options
    • required
    • Default
  • EDIT_TALES_PERMISSION
    • Custom Validator
    • Options Vocabulary
    • Default Expression
  • ADVANCED_USE_PERMISSION
    • hidden (rationale: hidden isn't much use without a dynamic default.)



Risks

A proliferation of permissions. If we don't choose them well, it will get very complicated.

Progress log

Pending feedback, this is complete in 1.1 Alpha 1.