[ALF-11982] Enable category manager to handle custom classifications / custom category types Created: 10-Dec-11  Updated: 13-Mar-17  Resolved: 13-Mar-17

Status: Closed
Project: Alfresco
Component/s: Admin Console (Share)
Affects Version/s: 4.0.b Community, Community Edition 201512 EA
Fix Version/s: None
Security Level: external (External user)

Type: Contribution Priority: Major
Reporter: Axel Faust Assignee: Closed Issues
Resolution: Won't Fix Votes: 9
Labels: CommunityPainPoints
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File customCategoryEnhancementSample.patch     Text File customCategoryEnhancements.patch    
Issue Links:
is duplicated by ALF-18681 FormService doesn't allow to specify ... Closed
relates to REPO-426 REST API - Categories Open
is related to by REPO-2197 Allow custom metadata on categories Done
Date of First Response:


The Share category manager currently only handles standard categories from the cm:generalclassifiable classification. This is very limiting for applications that require custom classifications or additional metadata associated with categories. The attached patch file enhances the category manager (and some related components of Share / the repository) to allow management and usage of custom classifications and custom category types.

Changes made by the patch:

  • allow forms to supply a destination child-association when creating nodes (implementing a TODO in the current code base)
  • add a web script to the repository tier that lists the available classification aspects
  • enhance the Share category manager to handle multiple classification aspects
  • enhance the Share category manager to use forms for category management (creation / modification)
  • provide a configuration option to hide certain classification aspects in the category manager
  • provide a configuration option to specify wether a form should be used to modify the categories of a certain classification and what type of category should be created
  • enhance the picker children web script on the repository tier to specify wether an element "is a category"
  • patch the object-finder component in the web framework, replacing a hard type check with an evaluation of the new "is a category" property to handle category subtypes

The second patch file provides a sample model, bootstrap view, Share configuration and Spring Surf extension to work with the enhancements made by this contribution.

Please note: The last two items in the change list have previously been submitted to Alfresco Support as ACT #15024-37043 in the context of a customer project unrelated to this contribution.

Comment by Axel Faust [ 10-Dec-11 ]

Attached patch files for contribution and sample model/configuration.

Comment by Axel Faust [ 10-Dec-11 ]

A more detailed account can be found at http://axel-faust.de/?p=30&lang=en

Comment by Richard Esplin [X] (Inactive) [ 22-Jan-16 ]

This issue was reported against an old version of Alfresco Community Edition.

Alfresco 5.1 is nearing release, and contains many improvements that address old problems. We are closing old issues so that we can better prioritize our efforts.

If you verify that the issue still exists in an Early Access release of Alfresco 5.1, please reopen the issue. If you have any trouble reopening the issue, then leave a comment or email us at community@alfresco.com so that we can assist.

Thank you for collaborating with us on improving Alfresco.

Comment by Richard Esplin [X] (Inactive) [ 22-Jan-16 ]

Axel says this issue still applies to 5.1, and it has a patch we should consider. So I'm reopening it.

Comment by Richard Esplin [X] (Inactive) [ 22-Jan-16 ]

John Knowles [X]: This is a Share enhancement request with a patch attached for old versions of Alfresco. This use case should be considered as we look to "aikau-ify" these parts of Share.

Comment by Richard Esplin [X] (Inactive) [ 13-Mar-17 ]

This patch touches both the repository and Share to address a deficiency that has existed for some time. We won't be addressing this problem in the current implementation because we are instead focusing on creating a versioned REST API to meet this use case (see REPO-426).

We can't accept the patch as-is because the proposed changes are to code that is insufficiently tested, and investing in creating new tests for this area will significantly increase the amount of work needed.

Once the new REST API is available, we will work on exposing it in the interface.

Generated at Fri Apr 23 12:23:32 BST 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.