Extend data module to support better typing of contribution

[BBGuy]

Proposed change

1) Extend data model to support different types of role types - Role Type type This will include

• Sample
• Embedded clips
• Direct contribution

2) Extend data model to support different types of right types - Right type type This will include:

• Credit
• Payment right
• Permission right

  To do:

• [ ] Agree on the data structure change
• [ ] Come up with better names
• [ ] Implement data model changes
• [ ] update functionality

  Agree on the data structure change:

Role Type type - The prototype we have came up with proved that we need the "Role Type type" as we need to be able to create new right types and still pick up related contributions without having to update code or use naming conventions - both exists in the current prototype: rules need updating with new right types, code uses role naming conventions (all roles with a name of 'sample' are related)

Right type type - This will allow us to have a top down approach of all contributions that are to do with:

• credits - who did what and where (200ms-650ms)
• Permission right - can and how the asset can be used
• Payment right - get paid for his contribution

Other approaches we can look at: having this as properties of a contribution - so we 3 three Y/N fields to each contributions - I suspect this will be less structured and we will not be able to have a top down approach

[dahacouk]

Something I'm not sure about is if we already have a way of being flexible on a right type then why not just stick with that? Is it because we need to actually treat each right type in a different way programmatically? I guess so. Hmm...

[BBGuy]

while we have the flexibility, we need to resolve two issues: 1) Role Type type for Simple workflows - we don't want someone to have to work with 5 entities each time they sample an asset to allow us to synchronize the usage of related contributions I suggest the Role Type type (this will replace the Boolean checkbook "embedded clip) - this is not a big change and I believe it is the correct approach

2) Right type type - for supporting Credits, Payment rights and Permission rights - I am less sure about this as I am not sure I fully understand how all three of those work, but if those need implementing using our contribution system we need a high level method of differentiating them. This may be used as follows: return all credits contributions to build the track view (like in version 1) Use Payment rights to show the payment breakdown report.

[iAugur]

I think we need an entity to manage the relationship between assets that controls the role/rights assignments. At the moment the role and rights are linked to the asset relationship and this will mean that you can only support a single relationship between two assets and the usage is duplicated for the separate rights. As such you then have to keep these in sync if they change on one (as we currently have it). I propose we have an entity 'Asset relationship' above Contribution and this holds the usage for all of the associated rights.

[BBGuy]

I agree however for the prototype we can get away with making this entity a secondary one (not above contributions) so all code can work without needing update, with the exception of the code needed to synchronize related contributions

[BBGuy]

Created #18 to cover the above two comments