[phpldapadmin] [ phpldapadmin-Bugs-2875788 ] Editing an OU prompts to select a template

Bugs item #2875788, was opened at 2009-10-09 17:45
Message generated for change (Comment added) made by cpicton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=2875788&group_id=61828

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: 1.2.x
Status: Closed
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Joshua Kinard (kumba)
Assigned to: Nobody/Anonymous (nobody)
Summary: Editing an OU prompts to select a template

Initial Comment:
I think this is a bug, but the behavior described below of PLA 1.2.0.4 could be intentional.  Attached to this are several LDIF Files to re-create a basic ldap tree named ACME (using X.500 notation), as well as a few images from my working setup,

What I am running into is that under PLA 1.2.0.4, if I have o=acme, and three sub ou's, ou=users, ou=groups, ou=posixgroups, and I attempt to click on any of them to add children entries, PLA will prompt me to select a template to edit the OU with.  PLA 1.1.0.7 used to automatically determine the Template (or it used no template at all).  By allowing one to choose a template, PLA 1.2.0.4 is opening the door for erroneous user behavior by allowing users to pick the wrong template, and then editing attributes of the selected object and potentially damaging their tree by having the object converted to the object described in the template chosen.

If this behavior is intentional, then I think what PLA 1.2.0.4 (or later) needs to do is only display templates that match the primary objectClass of the object being edited, otherwise it should fallback to PLA 1.1.0.7's default behavior of "No Template" and let you edit the attributes directly per the defined objectClasses and the LDAP schema.

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

Comment By: Chris Picton (cpicton)
Date: 2009-12-09 15:28

Message:
Thanks for the clarification, however, I see the following behaviour change
from the older version: 1.1.0.5

1.1.0.5
If only a single template matched (apart from default), use that matching
template
If no template match, use default
If more than one template match, display only matching templates, not
default


1.2.0.4 (disable_default_template = false)
If only a single template matched (apart from default), display choice of
template or default
If no templates match, display choice of only default,
If more than one template match, display matching templates, including
default

1.2.0.4 (disable_default_template = true)
If only a single template matched (apart from default), use template
If no templates match, node cannot be edited
If more than one template match, display matching templates

The older behaviour seems more intuitive to me.

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

Comment By: Deon George (wurley)
Date: 2009-12-09 14:58

Message:
The "default" template is an AVAILABLE template. So in your case, you have
2 AVAILABLE templates, and you are asked which one to use.

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

Comment By: Chris Picton (cpicton)
Date: 2009-12-09 14:57

Message:
In my case, only one template matches, but I still get prompted to select a
template, either 'Sudo Policy' or default

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

Comment By: Deon George (wurley)
Date: 2009-12-09 14:17

Message:
OK, a further point of clarification.

The "regexp" parameter in a template, determine if the template is
AVAILABLE for a container. IE: If the container matches the regexp, the
template is AVAILABLE to be be used. If the container does not match the
regexp, the template is DISABLED for the container.

So, if there is only 1 AVAILABLE template, it is selected automatically.
If there are more than 1 AVAILABLE templates, you'll be asked "which one do
you want to use". If this is not the behaviour you are seeing, then repen
this bug.

You can simulate this behaviour many ways - the easiest - is to set
appearance,custom_templates_only and appearance,disable_default_template
and make sure your templates are named custom_x. Then your only two defined
templates will be evaluated when editing an entry and the regexp condition
will determine if/when they can be used.



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

Comment By: Chris Picton (cpicton)
Date: 2009-12-09 12:15

Message:
I have to agree with Joshua here.

I have been running 1.1.0.5, and I had created two custom templates (in my
modification/ directory, I have only ecnuser.xml and sudoPolicy.xml)

When I select a sudo policy in my tree, the regexp in sudoPolicy.xml
matches (<regexp>^cn=.*,ou=Sudoers,o=.*</regexp>), and It automatically
uses the correct editing template, I don't have to choose.  Same with
ecnuser.  The regexp I have defined in the xml matches the DN on the users
in ldap, and the correct template is chosen automatically.

With 1.2.0.4, it always asks me which template to use.

I am looking for a behaviour where, for specific paths in my ldap tree,
specific templates are always used to edit those nodes (as it was in
1.1.0.5)

Your comments would be appreciated.

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

Comment By: Deon George (wurley)
Date: 2009-10-10 06:34

Message:
Joshua, I dont see what your bug is (ie: what you are describing is not how
PLA works) - so few points of clarification:

* PLA 1.1.0.7 did not automatically determine the editing template - the
only supplied EDITING template was disabled by default, and thus edits used
to, by default, use the default template.

* When you edit an entry, you can govern which template should be used to
edit that entry, including the default. If you edit an object with an
objectClass=account with a template that was configured for example "posix
groups", then PLA will attempt to change the entry when you submit to a
posix group entry. (If is likely to fail, if you are changing structural
objectclasses as a result).) If you have "submit confirmation" configured,
you can optionally "skip" the objectClass modificaitons and the resulting
must attributes, if you dont want the change to go ahead (or you can
cancel).

* If you want to control that a template can only be uesd to edit specific
entries, you can control that with a regexp in the template definition. For
example, only allow the OU template to be used to edit entries that start
with ou=

* When creating a child entry (from an entry that was rendered with the
default template, or a selected template), PLA will ask you what template
you want to use when creating the child. This does not modify the parent
entry. So, it is perfectly normal to have an "OU" template to define what
attributes an "OU" object should have (and use that to edit the OU entry),
and it is perfectly normal for an OU parent to create entries that are for
example, not OU.

A last point of clarification, the templates provided are "SAMPLES" - that
work for me and are quite generic. You can disable the use of the supplied
templates, and/or enforce the usage of just your own.

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

Comment By: Joshua Kinard (kumba)
Date: 2009-10-09 18:01

Message:
Also:

phpLDAPAdmin Version: Affected: 1.2.0.4; Not Affected: 1.1.0.7
LDAP Server: OpenLDAP 2.4.11-1 from Debian Lenny 5.0
HTTP Server: Lighttpd 1.4.19-5 from Debian Lenny 5.0
PHP Version: php5-cgi-5.2.5.dfsg from Debian Lenny 5.0
OS: Debian Lenny 5.0 (Kernel: 2.6.26-2-xen-amd64)

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=498546&aid=2875788&group_id=61828

------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
______________________________________
phpLDAPadmin development mailing list.
To unsbuscribe: https://lists.sourceforge.net/lists/listinfo/phpldapadmin-devel
http://phpldapadmin.sourceforge.net/