[
https://issues.apache.org/jira/browse/DIRSTUDIO-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006896#comment-13006896
]
Emmanuel Lecharny commented on DIRSTUDIO-729:
---------------------------------------------
To be more specific, not *all* the OpAttrs are modifiable by the user. Most of
them aren't : see RFC 4512, par 3.4.
The EntryCSN OpAttr for instance has no reason to be injected by a user - even
the administrator -, except by the Syncrepl user. That means we have to deal
with this kind of attribute carefully.
It raises another aspect : if we forbid the admin to inject entries with such
attributes into the server, then do we correctly administrate those OpAttrs
when we proceed operations *inside* the server ? (keep in mind that we switch
to the admin user in such case).
Not really simple.
Anyway, from the Studio POV, copying the OpAttrs when creating a new entry
seems to be the wrong thing to do, regardless of how the servers handle such
OpAttrs.
> Issue when creating an entry copying an existing one
> ----------------------------------------------------
>
> Key: DIRSTUDIO-729
> URL: https://issues.apache.org/jira/browse/DIRSTUDIO-729
> Project: Directory Studio
> Issue Type: Bug
> Components: studio-ldapbrowser
> Affects Versions: 1.5.3
> Reporter: Emmanuel Lecharny
> Fix For: 2.0.0
>
>
> When creating a new entry, copying it from an existing entry, we get an error
> :
> [LDAP: error code 19 - entryCSN : no user modification allowed]
> The connection has been set to require the OperationalAttributes to be read
> when fetching entries. I'm wondering if the problem is not a side effect :
> the copied entry gets all its OpAttrs copied too, when they should not.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
