Uploaded image for project: 'Alfresco'
  1. Alfresco
  2. ALF-6565

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

    Details

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

      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.

        Attachments

          Activity

          Hide
          bremmington 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
          bremmington 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
          bremmington Brian Remmington added a comment -

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

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

          For retest in 3.4.2

          Show
          srigby Steve Rigby added a comment - For retest in 3.4.2
          Hide
          alfrescoqa 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
          alfrescoqa 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
          wtaylor Will Taylor [X] (Inactive) 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
          wtaylor Will Taylor [X] (Inactive) 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:
              closedissues Closed Issues
              Reporter:
              bmarkovic Bojan Markovic (Inactive)
            • 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