You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2009/10/07 11:59:31 UTC
[jira] Created: (DIRSERVER-1416) createTimestamp operational is
accepted in an incoming entry oif theprincipal is Admi : this is not normal
createTimestamp operational is accepted in an incoming entry oif theprincipal is Admi : this is not normal
----------------------------------------------------------------------------------------------------------
Key: DIRSERVER-1416
URL: https://issues.apache.org/jira/browse/DIRSERVER-1416
Project: Directory ApacheDS
Issue Type: Bug
Affects Versions: 1.5.5
Reporter: Emmanuel Lecharny
Fix For: 2.0.0-RC1
For some unknown reason, the OperationalAttributeInterceptor which is adding the four needed OA (creatorsName, ctreateTimestamp, entryUUID, entryCSN) is checking of the createTimestamp is already present in the incoming entry, and in this case, if the principal is admin, it keep the original OA .
My personal guess is that it's probably some remanent code added when we were developping Mitosis, but I don't think it makes any more sense to keep it.
However, when we will implement the replication system, we will have to take care of entryUUID and entryCSN that will exist in the added Entry.
This has to be reviewed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRSERVER-1416) createTimestamp operational is
accepted in an incoming entry oif theprincipal is Admi : this is not normal
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kiran Ayyagari resolved DIRSERVER-1416.
---------------------------------------
Resolution: Fixed
we now allow modification of modifyTimestamp and modifiersName operational Attributes by admin user, this is needed by the replication system
http://svn.apache.org/viewvc?rev=949186&view=rev
> createTimestamp operational is accepted in an incoming entry oif theprincipal is Admi : this is not normal
> ----------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1416
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1416
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.5
> Reporter: Emmanuel Lecharny
> Assignee: Kiran Ayyagari
> Fix For: 2.0.0-RC1
>
>
> For some unknown reason, the OperationalAttributeInterceptor which is adding the four needed OA (creatorsName, ctreateTimestamp, entryUUID, entryCSN) is checking of the createTimestamp is already present in the incoming entry, and in this case, if the principal is admin, it keep the original OA .
> My personal guess is that it's probably some remanent code added when we were developping Mitosis, but I don't think it makes any more sense to keep it.
> However, when we will implement the replication system, we will have to take care of entryUUID and entryCSN that will exist in the added Entry.
> This has to be reviewed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRSERVER-1416) createTimestamp operational is
accepted in an incoming entry oif theprincipal is Admi : this is not normal
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kiran Ayyagari closed DIRSERVER-1416.
-------------------------------------
> createTimestamp operational is accepted in an incoming entry oif theprincipal is Admi : this is not normal
> ----------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1416
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1416
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.5
> Reporter: Emmanuel Lecharny
> Assignee: Kiran Ayyagari
> Fix For: 2.0.0-RC1
>
>
> For some unknown reason, the OperationalAttributeInterceptor which is adding the four needed OA (creatorsName, ctreateTimestamp, entryUUID, entryCSN) is checking of the createTimestamp is already present in the incoming entry, and in this case, if the principal is admin, it keep the original OA .
> My personal guess is that it's probably some remanent code added when we were developping Mitosis, but I don't think it makes any more sense to keep it.
> However, when we will implement the replication system, we will have to take care of entryUUID and entryCSN that will exist in the added Entry.
> This has to be reviewed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRSERVER-1416) createTimestamp operational is
accepted in an incoming entry oif theprincipal is Admi : this is not normal
Posted by "Kiran Ayyagari (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DIRSERVER-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kiran Ayyagari reassigned DIRSERVER-1416:
-----------------------------------------
Assignee: Kiran Ayyagari
> createTimestamp operational is accepted in an incoming entry oif theprincipal is Admi : this is not normal
> ----------------------------------------------------------------------------------------------------------
>
> Key: DIRSERVER-1416
> URL: https://issues.apache.org/jira/browse/DIRSERVER-1416
> Project: Directory ApacheDS
> Issue Type: Bug
> Affects Versions: 1.5.5
> Reporter: Emmanuel Lecharny
> Assignee: Kiran Ayyagari
> Fix For: 2.0.0-RC1
>
>
> For some unknown reason, the OperationalAttributeInterceptor which is adding the four needed OA (creatorsName, ctreateTimestamp, entryUUID, entryCSN) is checking of the createTimestamp is already present in the incoming entry, and in this case, if the principal is admin, it keep the original OA .
> My personal guess is that it's probably some remanent code added when we were developping Mitosis, but I don't think it makes any more sense to keep it.
> However, when we will implement the replication system, we will have to take care of entryUUID and entryCSN that will exist in the added Entry.
> This has to be reviewed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.