Alfresco
  1. Alfresco
  2. ALF-6565

Explorer UI allows duplication of Replication targets which in effects breaks Alfresco

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: Triage
    • Security Level: external (External user)
    • Labels:
      None
    • Environment:
    • Resource:
      External
    • Triage:
      Won't Fix

      Description

      My install is 3.4.b Community on CentOS 5.5 x86.

      Explorer UI allows one to duplicate replication job targets in Repository> Data Dictionary> Transfers> Transfer Target Groups> Default Group by using "copy/paste space" tools from the dropdown above the space browser. Effect is that on consecutive starts of Alfresco will fail due to:

      ::ERROR [org.springframework.web.context.ContextLoader] Context initialization failed
      ::org.alfresco.service.cmr.repository.DuplicateChildNodeNameException: Duplicate child name not allowed: Internal Target

      Where "Internal Target" is metadata "name" of replication target since space names are different.

      I beleive this to be a showstopper for a tinkering user (like myself) since Explorer UI, the only trivial way to fix the issue cannot be started so the user has no simple access to the repository.

      Proposed remedy:
      UI should display an error message on attempts to duplicate elements that cannot and shouldn't be duplicated (ie where metadata elements sould be unique) and disallow/abort action. Especially cases like this where the metadata itself isn't editable through UI. Upon startup (if by some odd combination of tinkering and legitimate actions user managed to create duplicates) all nodes apart from the "factory default" one should be ignored and exceptions should be logged.

        Activity

        Hide
        Mark Rogers added a comment - - edited

        This should not be a UI restriction, the enforcement needs to be at the repository level.

        And we probably need to add a copy policy.

        The target name must be unique. There's code in the Transfer service to enforce this however that is getting bypassed when creating transfer targets by other methods.

        Show
        Mark Rogers added a comment - - edited This should not be a UI restriction, the enforcement needs to be at the repository level. And we probably need to add a copy policy. The target name must be unique. There's code in the Transfer service to enforce this however that is getting bypassed when creating transfer targets by other methods.
        Hide
        Derek Hulley added a comment -

        Brian, please review investigation.

        Show
        Derek Hulley added a comment - Brian, please review investigation.
        Hide
        Brian Remmington added a comment -

        I think that the problem is simply with the implementation of the lookupTransferTarget(String) method in the TransferServiceImpl2 class. The purpose of having transfer groups was explicitly to enable transfer targets in different groups to share the same name. Currently, only the default group is directly supported (the API does not currently support creation of transfer targets in any other group).

        The assumption should be that the request is for a transfer target in the default group - that's the whole point of the default group - so the lookupTransferTarget method should be changed to use NodeService.getChildByName, using the default group folder as the parent node. It should only return null if a transfer target with the specified name does not exist in the default group. Due to the duplicate name constraint on the CONTAINS association, there will never be multiple transfer target with the same name in that group.

        Show
        Brian Remmington added a comment - I think that the problem is simply with the implementation of the lookupTransferTarget(String) method in the TransferServiceImpl2 class. The purpose of having transfer groups was explicitly to enable transfer targets in different groups to share the same name. Currently, only the default group is directly supported (the API does not currently support creation of transfer targets in any other group). The assumption should be that the request is for a transfer target in the default group - that's the whole point of the default group - so the lookupTransferTarget method should be changed to use NodeService.getChildByName, using the default group folder as the parent node. It should only return null if a transfer target with the specified name does not exist in the default group. Due to the duplicate name constraint on the CONTAINS association, there will never be multiple transfer target with the same name in that group.
        Hide
        Mark Rogers added a comment - - edited

        I thought the purpose of the groups was a way to classify different "groups" of transfer targets. Its a feature that we have in the "old" WCM.

        For example we could have a group of "live servers" or a group of "red servers", whatever makes sense to the end user. However we have not implemented the groups concept which was for another "sprint".

        Currently targets are accessed by "name" only. There's code in the Transfer Service to ensure unique names but we are bypassing it.

        Show
        Mark Rogers added a comment - - edited I thought the purpose of the groups was a way to classify different "groups" of transfer targets. Its a feature that we have in the "old" WCM. For example we could have a group of "live servers" or a group of "red servers", whatever makes sense to the end user. However we have not implemented the groups concept which was for another "sprint". Currently targets are accessed by "name" only. There's code in the Transfer Service to ensure unique names but we are bypassing it.
        Hide
        Brian Remmington added a comment -

        Yes, that's right. There's nothing to prevent two targets in different groups having the same name. The API currently only really makes use of the default group. When the caller requests the transfer target named "fish" we should interpret that as "fetch me the transfer target named 'fish' from the default transfer group". At some point we should add an operation such as "getTransferTarget(String groupName, String targetName)" which would allow the caller to use other transfer groups.

        Show
        Brian Remmington added a comment - Yes, that's right. There's nothing to prevent two targets in different groups having the same name. The API currently only really makes use of the default group. When the caller requests the transfer target named "fish" we should interpret that as "fetch me the transfer target named 'fish' from the default transfer group". At some point we should add an operation such as "getTransferTarget(String groupName, String targetName)" which would allow the caller to use other transfer groups.
        Hide
        Brian Remmington added a comment -

        Fixed on BRANCHES/DEV/V3.4-BUG-FIX @ 25931

        Show
        Brian Remmington added a comment - Fixed on BRANCHES/DEV/V3.4-BUG-FIX @ 25931
        Hide
        Steve Rigby added a comment -

        For retest in 3.4.2

        Show
        Steve Rigby added a comment - For retest in 3.4.2
        Hide
        Alfresco QA Team added a comment -

        We have performed the following steps:
        1. Created space "test" in "Company Home/Data Dictionary/Transfers/Transfer Target Groups".
        2. Using share interface, linked rule from "Company Home/Data Dictionary/Transfers/Transfer Target Groups/Default Group" space to "test" space.
        3. Created "Internal Target" space in "test" space;
        4. Edited properties for created 'Internal Target' - specified correct host, port and enabled target;
        5. Restarted Alfresco

        Result:
        no error occurred

        6. Created job using created and configured 'Internal Target' folder as target, but when running job, error occurred:
        04040078 Error executing transfer - 04040076 Failed to execute HTTP request begin to target: TransferTarget: Internal Target,host:internal,port:443 status: java.net.UnknownHostException: internal

        Note that host 'internal' and port '443' are default for the default 'Internal Target' folder from 'Default Group' folder, so default folder used as target besides specified custom 'Internal Target' from 'test' folder.

        Alfresco Enterprise 3.4.2 (build 347) RHEL5.5, Tomcat, PostgreSQL, Java 6 (all installer deployed) Client: WinXP, FF

        Show
        Alfresco QA Team added a comment - We have performed the following steps: 1. Created space "test" in "Company Home/Data Dictionary/Transfers/Transfer Target Groups". 2. Using share interface, linked rule from "Company Home/Data Dictionary/Transfers/Transfer Target Groups/Default Group" space to "test" space. 3. Created "Internal Target" space in "test" space; 4. Edited properties for created 'Internal Target' - specified correct host, port and enabled target; 5. Restarted Alfresco Result: no error occurred 6. Created job using created and configured 'Internal Target' folder as target, but when running job, error occurred: 04040078 Error executing transfer - 04040076 Failed to execute HTTP request begin to target: TransferTarget: Internal Target,host:internal,port:443 status: java.net.UnknownHostException: internal Note that host 'internal' and port '443' are default for the default 'Internal Target' folder from 'Default Group' folder, so default folder used as target besides specified custom 'Internal Target' from 'test' folder. Alfresco Enterprise 3.4.2 (build 347) RHEL5.5, Tomcat, PostgreSQL, Java 6 (all installer deployed) Client: WinXP, FF
        Hide
        Will Taylor added a comment -

        This issue has been re-triaged.
        The original issue that caused Alfresco to break on restart was addressed in 3.4.2. The residual issue from the retest on 4-May-2011 will not be fixed and so this issue is being resolved "Won't fix".

        Show
        Will Taylor added a comment - This issue has been re-triaged. The original issue that caused Alfresco to break on restart was addressed in 3.4.2. The residual issue from the retest on 4-May-2011 will not be fixed and so this issue is being resolved "Won't fix".

          People

          • Assignee:
            Closed Issues
            Reporter:
            Bojan Markovic
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 day, 4 hours
              1d 4h