collecting_society

While implementing the concept of Specification#Foreign-objects, some problems showed up which we need to address.

Just to remember:

• Foreign artist
  • used in members, contributions
  • fields: name, email
• Foreign creation
  • used in tracks or originals
  • fields: artist, title

Issues:

• Note: Foreign creations don't have a release date
  • so we cannot do any filtering, like for orignials: showing only those creations with an earlier release date
• Question: How to handle foreign artists with same email?
  • if several web user specify a foreign artist (contributor or member) with the same email, one could assume, that they refer to the same party
  • So we could append the artist to the same party
  • But then all those web users would be able to change the email for all others (as the email is saved in the party and it's the same entity)
  • Do we want that or do we need to have several parties with the same email?
• Problem: Unknown group for artists of foreign creations
  • Currently, the attribute "group" of artists is a boolean field
  • This field is used for filtering/validation of selection lists (e.g. only solo artists for contributions or members)
  • Foreign creations create artists without knowledge, if it is a group or not (defaults to solo right now)
  • We could change the field type of "group" to selection (group, solo, unknown)
    • Would need time, as this is very basic and used a lot
    • Those artists would then either not be selectable for others, which makes them kind of individual only objects
    • Or it would be selectable for both types, which could result in incorrect data sets
• Note/Problem: Adding artists, created via foreign creations, as members require email
  • Right now, if someone adds a foreign artist X, which was created via a foreign creation, e.g. as a member of artist Y
    • they are not allowed to edit member X (as there is no ajax request for edit permissions)
    • they are able to save the artist Y
  • The next time, they edit the artist Y
    • they are able to edit the member X (as the server checked the edit permission and told the gui, it is editable)
    • they are not able to save the artist Y, as the email needs to be specified (as no email was provided for foreign creation artists)
    • so they need to provide the email then
  • We might introduce those ajax calls to enhance the gui (if there's enough time)
  • But do we want that behaviour, that the email needs to be provided for added artists?
• Problem: Who is allowed to edit foreign artists?
  • When a foreign artist X is created, we track the creator
  • If it's a member of artist Y / contributor of a creation of artist Y, I assume, all administrators of artist X should be allowed to edit member / contributor X?
  • This is not straight forward, as the entity creator is the party of the current web user and right now, there's no memory of the object for which the foreign object was created in the first place
  • So could we just say, all members are allowed to edit?
  • This entry is selectable by all other web users, so this would mean, that anyone might edit this artist Y, if added as member / contributor.
  • This also means, that all foreign emails might be leaked (DSGVO, etc).
  • But if it's a valid member of more than one artist, why should the artist administrators of the other artists not be able to edit (which implies name and email)
  • But then again, one artist administrator could change the name/email for all others, which might irritate those others
  • I'm not sure, what would be best here