Currently, required form fields must be considered in
several places:

 - the hidden "@required" input field
 - the th elements

It would be possible to define the required fields
(e.g. in the opening <form> tag), and then reuse this
information

 - to automatically highlight the labels for the fields
 - to hand over the info to roundup (like it is already
done), and
 - to check for empty fields with Javascript before
sending the request, putting the focus to the first
field which lacked a required value.

Patch following :-)

Logged In: YES 
user_id=6405

The @required field would still be needed as some users 
don't have Javascript turned on (yes, I know, in this day 
and age...)

Logged In: YES 
user_id=805804

Of course, the @required field will have to stay, because
some bad guys could switch Javascript off ;-)

This is for convenience only, avoiding network request which
will fail anyway.

Logged In: YES 
user_id=1080231

Sorry for meddling in, but why not specifying which
properties are required in the scheme definition file?
Defining required properties in HTML looks nice, but it
doesn't prevent creating issue's with too less filled in
properties via the mail gateway. Currently auditors are
required to prevent that issues are created via the mailgw
that do miss some required properties. These auditors are
also triggered when submitting an issue form, meaning the
@required HTML specification doesn't really make sense
anymore, because the properties are checked twice.
So why not do something like we do to define the key
property. In other words something like:
   issue.required("title", "priority")
and then let some general code check for the presence of
these properties before any auditor is executed. This way we
are able to catch the missing properties in both the
submitted issue forms and the submitted emails.

Regards,
Marlon

Logged In: YES 
user_id=34818

Marlon writes:
> Sorry for meddling in, but why not specifying which
> properties are required in the scheme definition file?
Good idea, I'd put it into the individual attribute as an
optional parameter (in schema.py), e.g.

 name = String (required = True)

it can then be used for checking that all required
attributes are present and for generating appropriate
javascript. A side-effect of the setkey method should
probably be to set the required-flag for the key attribute.

-- Ralf

Logged In: YES 
user_id=805804

>  name = String (required = True)

I agree it's a good idea to have a 'required' flag for
database fields. There could be a table method which returns
the list/tuple of required fields; this could be used to
fill the 'required' variable I introduced in my patch.

However, in our setup we're less picky when issues are
created via mail (by a customer) than when created TTW (by
tech people, and with immediate response, guaranteed to
reach the acting user). Thus IMO it's a good thing to be
able to add some more fields to the list in the page
template. And I think the fields enforced via Javascript
should be enforced by the server side, too.

My patch introduced the 'required' variable; a later patch
could introduce the method which fills it based on the
schema data (which could take the additional fields as
arguments, returning a duplicate-free list of field names).

Logged In: YES 
user_id=805804

page.html with th_label macro checked in; user.item.html
uses this already.

In the current 1.5.1 the required parameter looks like it is supported
for all properties and there is a:


      def get_required_props(self, propnames = []):
        """Return a dict of property names mapping to property objects.
        All properties that have the "required" flag set will be
        returned in addition to all properties in the propnames
        parameter.
        """
 
in roundup/hyperdb.py::Class

So that could be of use here as well to get the default list of
properties. I wonder if we also need to extend this to allow an array of
properties that should be removed:

      def get_required_props(self, propnames = [], filter = []):

where the props listed in filter will not be returned.
This could be useful if used for detectors.