plone/plone.schemaeditor

Provides through-the-web editing of a Zope schema/interface.

Introduction

plone.schemaeditor provides a through-the-web interface for modifying Zope 3 schemata (interfaces).

Currently there is support for:

• adding and removing fields
• editing attributes of existing fields
• reordering fields
• renaming fields
• organizing fields into fieldsets

plone.schemaeditor only handles the actual schema editing. To be useful, it requires some integration code to take care of the following pieces:

• traversing to a schema that is used as the context of the editor
• persisting schema changes across Zope restarts

See plone.app.dexterity (along with plone.dexterity and plone.supermodel) for one approach to this integration.

The following field types (from zope.schema) are currently supported:

• TextLine
• Text
• Int
• Float
• Bool
• Password
• Datetime
• Choice (with simple list of values)
• List of Choice (with simple list of values)

Third-party packages can make additional field types available by registering new IFieldFactory utilities.

Dependencies

• Zope 2
• z3c.form
• plone.z3cform

Despite the namespace, Plone is not a dependency.

Note: This package is released under a BSD license. Contributors, please do not add dependencies on GPL code.

Credits

Author:

• David Glick ([email protected])

Contributors:

• Nathan Van Gheem
• Martin Aspeli
• Alex Limi
• Ross Patterson
• Steve McMahon
• Thomas Desvenain
• et al

plone.schemaeditor's Issues

Selection of field type (while adding) does not accept click

If I add a field in schemaeditor, in the popover the selection by mouse click is broken, only by keyboard is possible.

cannot move field to other fieldset

2019-04-15 16:29:58,602 ERROR   [Zope.SiteErrorLog:250][waitress] 1555338598.6023260.8536061107307231 http://localhost:8080/Plone3/dexterity-types/Document/test/@@changefieldset
Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 142, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 295, in publish_module
  Module ZPublisher.WSGIPublisher, line 229, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZPublisher.WSGIPublisher, line 57, in call_object
  Module plone.schemaeditor.browser.field.fieldset, line 18, in change
  Module plone.schemaeditor.utils, line 51, in get_fieldset_from_index
IndexError: list index out of range

Versions:
Plone 5.2rc2
p.schemaeditor/master

Port Robot tests to use new shared test setups

plone/plone.app.robotframework#110

We're setting up a shared setup for all Plone Robot tests in plone.app.robotframework and we should thus use those in plone.app.contenttypes as well.

Adding field to fieldset introduced by other behavior not working, throwing an error

Plone 5.2, plone.schemaeditor 2.0.20.

Screenshot shows the schemaeditor for xmldirector.connector with a custom behavior adding some fields through the "guideline" fielset. Trying to add a custom field to the field throws an error.

Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 142, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 295, in publish_module
  Module ZPublisher.WSGIPublisher, line 229, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZPublisher.WSGIPublisher, line 57, in call_object
  Module plone.z3cform.layout, line 63, in __call__
  Module plone.z3cform.layout, line 47, in update
  Module plone.z3cform.fieldsets.extensible, line 65, in update
  Module plone.z3cform.patch, line 30, in GroupForm_update
  Module z3c.form.group, line 145, in update
  Module plone.app.z3cform.csrf, line 22, in execute
  Module z3c.form.action, line 98, in execute
  Module z3c.form.button, line 315, in __call__
  Module z3c.form.button, line 170, in __call__
  Module z3c.form.form, line 257, in handleAdd
  Module z3c.form.form, line 265, in createAndAdd
  Module plone.schemaeditor.browser.schema.add_field, line 83, in add
  Module plone.schemaeditor.utils, line 52, in get_fieldset_from_index
IndexError: list index out of range

> /home/ajung/sandboxes/onkopedia_buildout-plone5/eggs/plone.schemaeditor-2.0.20-py3.7.egg/plone/schemaeditor/utils.py(50)get_fieldset_from_index()
-> index = int(index or 0) - 1
(Pdb) args
schema = <SchemaClass xmldirector.connector.connector.IConnector>
index = 6
(Pdb) n
> /home/ajung/sandboxes/onkopedia_buildout-plone5/eggs/plone.schemaeditor-2.0.20-py3.7.egg/plone/schemaeditor/utils.py(51)get_fieldset_from_index()
-> fieldsets = schema.queryTaggedValue(FIELDSETS_KEY, [])
(Pdb) 
> /home/ajung/sandboxes/onkopedia_buildout-plone5/eggs/plone.schemaeditor-2.0.20-py3.7.egg/plone/schemaeditor/utils.py(52)get_fieldset_from_index()
-> return fieldsets[index] if index >= 0 else None
(Pdb) pp fieldset
*** NameError: name 'fieldset' is not defined
(Pdb) pp fieldsets
[]

confusion between Index and SearchableTextIndex

User problem

from https://community.plone.org/t/how-to-using-own-fields-in-live-search/2307/4

its not clear to users the difference between an SearchableText index and other indexes. This is probably caused by a few things

• The word index is used for search engines like google to index a whole document, not an individual field. As in the verb to index, rather than the noun. We should perhaps be using a more specific term. ie, "yes I want to index my new content type, thats obviously how I get it searchable".
• field index is probably an advanced usecase but including all of the fields in the searchabletext is likely a more common usecase. We don't offer a UI for this so users are going to assume Index is the thing they want.
• anyone used to an SQL system would think of accessing items by field values as something to do with a query. indexes are just an optimisation to make that faster so an advanced concept. Plone is abnormal that it requires an index to make that query possible.

Options

Queryable and Searchable

perhaps we could have an UI where you can enable a field to be either:

• query-able
• searchable
• query-able and searchable

Unstable robot test for delete field

The 'Delete field' test in test_fields.robot sometimes fails on Jenkins. I have seen it earlier this week, and now again.
See http://jenkins.plone.org/job/plone-5.0-python-2.7-robot/4200/robot/

Message is: "Timeout 10 seconds exceeded. The last error was: Page should not have contained element 'css=#formfield-form-widgets-phone'"

Screenshots are here: http://jenkins.plone.org/job/plone-5.0-python-2.7-robot/4200/robot/report/
But all seven screen shots of the Delete Field test are identical, as far as I see.

demo

This is a feature request. Could you provide a link to a demo in your README? I would like to see your project before investing time in trying it out myself.

Cannot access values of a RelatedChoice field

Step to reproduce.
Create 2 new types with p.schemeeditor ClassA and ClassB where ClassB has a RelationChoice field called RelatedA with allowed type ClassA.
Created folder called Ayes and some ClassA instances.
In Bees create an instance of ClassB, and you'll see you cannot select the value for the RelatedA field from the Ayes folder because you cannot transverse to the Ayes folder.
In the RelatedA definition, if select a ClassA instance as a default, I then have access to the Aye folder otherwise not.

Move translations to plone.app.locales

Being a core package it makes sense to unify the translations in a single source.

Cannot edit or delete fieldset

After adding a fieldset I noticed a typo in its title, so I wanted to edit it, but I couldn't find an "Edit" button or a view that allows me to modify it. Neither does it seem possible to delete the fieldset (and create a new one without the typo). Both is of course possible by modifying the schema XML, but there don't seem to be UI elements for either editing or deleting field sets.

I tried on Plone 5.1b3 with plone.schemaeditor 2.0.18, both using collective.easyform 2.1.0 and dexterity TTW editing (plone.app.dexterity 2.4.1).

Update markup of templates to Bootstrap 5

Due to #2967 we have to update the markup of the templates listed below.

• plone.schemaeditor.browser.field.edit.pt
• plone.schemaeditor.browser.schema.schema_listing.pt

Visual overlap in editor

Visual overlap in all Plone 5 versions:

Not possible to change field type of existing field.

User added a type with a bunch of textlines, but want to change it into text fields. This is not possible.

SchemaCache is not updated across multiple Plone instances

How to reproduce:

1. Start a ZEO cluster with 2 Plone ZEO clients
2. Add Plone Site
3. Go to first Plone instance > Site Setup > Dexterity Content-Types > Page
4. Add new fieldset and new text field and press "Done"
5. Go to the second Plone instance > Site Setup > Dexterity Content-Types > Page
6. Notice the missing custom fieldset / field

Plone version: 5.2.2

See also: https://community.plone.org/t/dynamic-schema-is-not-synced-across-zeo-clients/12923

Get rid of ZopeTestCase

Every week a job on Jenkins checks which packages still use ZopeTestCase instead of plone.testing/plone.app.testing. Apart from some code in Zope itself, and some comments and backward compatibility code in plone(.app).testing, the only real use of this is in plone.schemaeditor. It is this code:

from Testing import ZopeTestCase as ztc
..
ztc.FunctionalDocFileSuite(...)

We should rewrite this to something else, probably just importing something from doctest.
We can also get rid of Py23DocChecker and any use of six, because the master branch is for Plone 6 only.

Not possible to use/integrate schemaeditor outside autotoc tabs

Since 2.0.16 (and this commit), there is a regression in the ability to use the schema editor outside of autotoc tabs (on pages where autotoc pattern is unused).

For my purposes, this is a regression. The only way (for me) to work around this is to call require('pat-registry').patterns.autotoc.init($('<div>').appendTo('body').hide()) (add dummy element to body, init autotoc on it, then hide it) to trigger that patterns init event. Obviously this is not a problem for core use inside Dexterity types control panel, but this might affect add-ons beside my own.

@thet what was the "wait until autotoc is ready" use case? Was there an order issue affecting the Dexterity Types CP?

I wonder if there also a reasonable way to expose the ability to initialize the schema editor imperatively, but the zero-namespace IIFE the code is inside now preempts that? Exporting a namespace from a return value of the IIFE seems a reasonable compromise?

moving field to other fieldset is broken

Traceback (innermost last):
  Module ZPublisher.WSGIPublisher, line 167, in transaction_pubevents
  Module ZPublisher.WSGIPublisher, line 376, in publish_module
  Module ZPublisher.WSGIPublisher, line 271, in publish
  Module ZPublisher.mapply, line 85, in mapply
  Module ZPublisher.WSGIPublisher, line 68, in call_object
  Module plone.schemaeditor.browser.field.fieldset, line 18, in change
  Module plone.schemaeditor.utils, line 56, in get_fieldset_from_index
IndexError: list index out of range

Unable to save defaults

Action: goto control panel / schema editor / select a content type, click the Fields tab, click the 'Save defaults' button ->

Traceback (innermost last):
  Module ZPublisher.Publish, line 138, in publish
  Module ZPublisher.mapply, line 77, in mapply
  Module ZPublisher.Publish, line 48, in call_object
  Module plone.z3cform.layout, line 63, in __call__
  Module plone.z3cform.layout, line 47, in update
  Module plone.z3cform.fieldsets.extensible, line 65, in update
  Module plone.z3cform.patch, line 30, in GroupForm_update
  Module z3c.form.group, line 145, in update
  Module plone.app.z3cform.csrf, line 22, in execute
  Module z3c.form.action, line 98, in execute
  Module z3c.form.button, line 315, in __call__
  Module z3c.form.button, line 170, in __call__
  Module plone.schemaeditor.browser.schema.listing, line 118, in handleSaveDefaults
  Module zope.interface.interface, line 422, in getDescriptionFor
KeyError: 'IDublinCore.creators'

no need to actually change any default value to reproduce.
apply to any Plone 5 version

changing code of plone/schemaeditor/browser/schema/listing.py so:

--- listing.py.ori	2017-12-25 22:07:47.977042000 +0000
+++ listing.py	2018-01-24 16:57:25.448722032 +0000
@@ -114,8 +114,11 @@
             self.status = self.formErrorsMessage
             return
 
+        allowed = [wid.field.getName() for wid in self._iterateOverWidgets()
+            if wid.field.interface is self.context.schema]
         for fname, value in data.items():
-            self.context.schema[fname].default = value
+            if fname in allowed:
+                self.context.schema[fname].default = value
         notify(SchemaModifiedEvent(self.context))
 
         # update widgets to take the new defaults into account

allows to set defaults to fields using the UI (it always worked in Xml view)

After creating fieldset its not possible to add fields to it.

1. Create fieldset using the UI
2. Click on fieldset.
3. Click add field

-> Field is created at default fieldset

Also I do not see any option to move a field to a fieldset.

Can get the "Fields" vocabulary via plone.restapi

GET http://localhost:8080/Plone/@vocabularies/Fields

2020-05-27 20:27:57,382 ERROR   [waitress:356][waitress] Exception while serving /Plone/@vocabularies/Fields                                                                                  
Traceback (most recent call last):                                                                                                                                                            
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/waitress-1.4.2-py3.8.egg/waitress/channel.py", line 349, in service                                                                        
    task.service()                                                                                                                                                                            
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/waitress-1.4.2-py3.8.egg/waitress/task.py", line 169, in service                                                                           
    self.execute()                                                                                                                                                                            
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/waitress-1.4.2-py3.8.egg/waitress/task.py", line 439, in execute                                                                           
    app_iter = self.channel.server.application(environ, start_response)                                                                                                                       
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/Paste-3.1.1-py3.8.egg/paste/translogger.py", line 69, in __call__                                                                          
    return self.application(environ, replacement_start_response)                                                                                                                              
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/Zope-4.1.3-py3.8.egg/ZPublisher/httpexceptions.py", line 30, in __call__                                                                   
    return self.application(environ, start_response)                                                                                                                                          
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/Zope-4.1.3-py3.8.egg/ZPublisher/WSGIPublisher.py", line 338, in publish_module                                                             
    response = _publish(request, new_mod_info)                                                                                                                                                
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/Zope-4.1.3-py3.8.egg/ZPublisher/WSGIPublisher.py", line 248, in publish                                                                    
    result = mapply(obj,                                                                                                                                                                      
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/Zope-4.1.3-py3.8.egg/ZPublisher/mapply.py", line 85, in mapply                                                                             
    return debug(object, args, context)
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/Zope-4.1.3-py3.8.egg/ZPublisher/WSGIPublisher.py", line 62, in call_object
    return obj(*args)
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/plone.rest-1.6.0-py3.8.egg/plone/rest/service.py", line 22, in __call__
    return self.render()
  File "/joint/backend/eea-dx-cpanel-metadata/src/plone/restapi/services/__init__.py", line 21, in render
    content = self.reply()
  File "/joint/backend/eea-dx-cpanel-metadata/src/plone/restapi/services/vocabularies/get.py", line 48, in reply
    vocabulary = factory(self.context)
  File "/joint/backend/eea-dx-cpanel-metadata/eggs/plone.schemaeditor-2.1.0-py3.8.egg/plone/schemaeditor/fields.py", line 62, in FieldsVocabularyFactory
    if context.allowedFields is not None:
AttributeError: 'RequestContainer' object has no attribute 'allowedFields'

Schema editor action buttons get disabled when required fields are in the listing.

Due to pat-validation the browser validator disables schema editor action buttons when a required field is blurred.

proposed solution

disable default form validation completely for schema listing.

implementation

Set form validation depending on ignoreRequiredOnExtract = False/True

"Save defaults" broken/misleading

When I add a required field and then click the "Save Defaults" button, I get a validation error. The "required" setting should however only hold for filling in the form when in its intended use, not for editing the schema.

In addition, users may mistake the "Save Defaults" button for a general "Save" button because they may not be aware that modifications through drag & drop are saved on-the-fly. (I know I tried clicking it to make sure my changes would be saved.) When they click the button and receive the above validation error (or any other error) they will start trying to find out what they did wrong and fixing it. As the default fieldset will be open, they won't even see what field caused the error, which will confuse and mislead them as everything is actually already saved and nothing else is to be done. This could be mitigated by an additional button, maybe labelled "Done" instead of "Save" because it doesn't really save anything, that takes the user out of the field editing view and back to the context URL.

Editing a field should notify FieldModifiedEvent

https://github.com/plone/plone.schemaeditor/blob/master/plone/schemaeditor/browser/field/edit.py#L175

Currently editing a field notifies the SchemaModifiedEvent. But this doesn't pass the field information to a subscriber.

notify(FieldModifiedEvent(self.context.__parent__, self.field)) should be used here instead