[SHA-318] [List] For a model, view a list of of existing custom Types and Property Groups Created: 08-Jul-14  Updated: 17-Jul-20  Resolved: 05-Mar-15

Status: Done
Project: Share Application
Component/s: Share Application
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Critical
Reporter: Mike Farman Assignee: Closed Bugs (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: 0 minutes Remaining Estimate: Not Specified
Σ Time Spent: 3 days, 40 minutes Time Spent: Not Specified
Σ Original Estimate: 1 day, 7 hours Original Estimate: Not Specified

Issue Links:
Depends on SHA-199 [Create] Create a new page for managi... Done
Depended on by SHA-317 [Create] Create a new Property Group Done
SHA-399 Implement REST API authentication fro... Sub-task Done Closed Bugs  
SHA-406 UX design of Types & Property Groups ... Sub-task Done Closed Bugs  
SHA-408 Create Aikau Types & Property Groups ... Sub-task Done Closed Bugs  
SHA-402 Update Property Groups page to show l... Sub-task Done Closed Bugs  
SHA-403 Update Share PO, add tests for list o... Sub-task Done Closed Bugs  
SHA-569 Update Share po to resolve 'Manage Ty... Sub-task Done Closed Bugs  
Epic Link: Custom Model Management
Sprint: CMM Sprint 1, CMM Sprint 2, CMM Sprint 3
Story Points: 3


User Story:

"As a Model Manager I can view a list of existing Property Groups so that I can review them as a starting point to adding more, deploying them or deleting them"


  • Assuming that Property Groups as simply Aspects that have been added as dynamic models to the Data Dictionary, We need to decide whether or not to display "system" Aspects (e.g. the file system XML files) or not - it may not actually be possible to distinguish between them.
  • Options for distinguishing between system aspects, dynamic models and Property Groups are:
    1. When any document is added to the Data Dictionary/Models folder, there is a folder rule that will automatically set the node type to be "cm:dictionaryModel" we could add an additional property to this type that indicates whether or not the node has been created as a Property Group or not (and then set this property when creating the Property Group)
    2. Use a single namespace for all Property Groups (e.g. "sys:" something) and then work on the assumption that any Aspects defined in that namespace are Property Groups
    3. Create a "Property Group" type and then (after the folder rule has been applied) change the type again to be the new type.
    4. Use of Public API requires entire entity structure to be defined so ACE-2182 will define the model that all subsequent REST methods will use - this is part of the reason for the large user story sizing

Comment by David Draper [X] (Inactive) [ 31-Oct-14 ]

We could possibly manage this in a similar way in which we handle the "default" facets in the search manager at the moment. If we treat XML scripted aspects as "system property groups" (or some similar name) then it could be possible to still disable/enable them (as that could potentially still be a viable requirement).

If we end up rendering both Property Groups and XML Aspects in the same list of "things" to apply to a Node, then there would probably be an expectation to also manage them in the same list as well. It should be possible to view all aspects/property groups in the same manager list... we could always have an "include system property groups" check box in the same way as we have an "include system groups" in the Groups manager page.

Comment by David Draper [X] (Inactive) [ 04-Nov-14 ]

The list of Property Groups should appear in the page that we create for managing Property Groups

Comment by Bindu Wavell (Inactive) [ 24-Nov-14 ]

I'm trying to reverse engineer what a property group is from comments on the recent product management office hours with Richard Esplin and the stories that are publicly available via JIRA. This seems like something where Alfresco will provide tools for creating custom aspects via UI tooling. It would be good to see stories that call out who will use these features and why they are important (I have some use cases in mind, I wonder what product management is thinking here.) Anyway I noticed the list of ways of distinguishing system vs dynamic vs property group aspects in this ticket and it occurred to me. Why not just have a base aspect that all property groups inherit from?

Comment by David Draper [X] (Inactive) [ 24-Nov-14 ]

Bindu Wavell It's important to realise a couple of things here:

  1. Just because a user story is defined in JIRA, it doesn't mean that it's going to be worked on
  2. Also, just because a user story does exist in JIRA, doesn't mean that there aren't other user stories that haven't been created in JIRA yet that might get worked on first

So we may yet create more user stories around Property Groups.... we're using Agile so we could be creating new stories right up until the last sprint, so don't expect there to be a comprehensive set now. We're also taking an iterative approach to development, and these stories relate to a first pass based on what we can easily achieve now.... so what gets implemented for this user story may yet get replaced by a later story (e.g. if we decided to make more in-depth model changes or updates to how the Repository handles the model)

In terms of your specific question.... that might be one approach, however - just inheriting from a base Aspect class doesn't prevent bootstrapped classes from also extending that class, sure - it might be a silly thing to do, but it wouldn't guarantee an Aspect was a Property Group.... anyway, we have more questions than answers at the moment I think

Comment by Bindu Wavell (Inactive) [ 24-Nov-14 ]

@ddraper, completely get all of your caveats.

There were really two points in my comment. First was that there are a bunch of stories about an epic called "Property Groups" but there does not seem to be a definition of what these are, what business problems they are intended to solve, etc.

As I was attempting to infer internal discussions/thinking based on public stories... ugh (better than nothing.) I saw this list of ways of flagging information on an aspect. I had not seen anything that would indicate that a Property Group (whatever that is) is something that should not be defined through bootstrapping. So my second point was that you have a way of flagging aspects now via inheritance...

Comment by Christine Thompson [X] (Inactive) [ 22-Apr-15 ]

Setting Fix Version for first release

Generated at Sat Feb 27 10:16:34 GMT 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.