AnsweredAssumed Answered

Integrity check on Association Source Mandatory wrong?

Question asked by mastro on Mar 1, 2012
Hi,

I was trying to understand better how associations works and I did some testing with different association definition (specifically by playing with the source and target mandatory field).

So…

Think of an association like this:

<type name="test:associated">
   <parent>cm:content</parent>
</type>
<type name="test:associator">
   <parent>cm:content</parent>
   <associations>
      <association name="test:association">
         <source>
            <mandatory>true</mandatory>
            <many>false</many>
         </source>
         <target>
            <class>test:associated</class>
            <mandatory>true</mandatory>
            <many>false</many>
         </target>
      </association>
   </associations>
</type>

I used Share to test, and so I defined this in the share-config-custom.xml:

<config
   evaluator="string-compare"
   condition="DocumentLibrary">
   <types>
      <type name="cm:content">
         <subtype name="test:associated" />
         <subtype name="test:associator" />
      </type>
   </types>
</config>


Target mandatory not granted on changeType:
  1. Create content X

  2. Make it of type test:associator

  3. Alfresco doesn't require me to choose the associated content, and I think it should.


Target mandatory not granted on delete target:
  1. Create content A

  2. Make it of type associated

  3. Create content X

  4. Make it of type test:associator

  5. Edit X properties and select A

  6. Save

  7. Delete A

  8. Success (???)

  9. Edit X

  10. Association with A is still there :/

  11. You can even save again
I think alfresco shouldn't allow me to delete A if it is associated with to X, or at least ask for confirmation or open up X to allow me defining another Associated content.

Source mandatory not granted on delete source (this is a real mess):
  1. Create content A

  2. Make it of type associated

  3. Create content X

  4. Make it of type test:associator

  5. Edit X properties and select A

  6. Save

  7. Delete X

  8. Success (may be fine)

  9. Create content Y

  10. Make it of type test:associator

  11. Edit Y properties and select A

  12. FAIL <— A is already associated to X (which is gone)
I really don't think this is the expected behavior…

I didn't opened a bug because I may miss something and want to share my test with you…
What do you think?

I thought I could rely on alfresco for data consistency and integrity checks but apparently I'll have to check them when exporting data through my services…

For example will CMIS join with those kind of association works? Will they fail?

Outcomes