Konzept #756

Foreign object handling?

Added by Alexander Blum almost 3 years ago. Updated about 2 years ago.

Status:ErledigtStart date:
Priority:NormalDue date:
Assignee:Meik Michalke% Done:

100%

Category:-
Target version:Repertoire 2) Testing phase II

Description

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

Related issues

Related to collecting_society - Userfeedback #778: Künstler Mitglieder hinzufügen Neu
Related to collecting_society - Datenbank #854: Add Group Checkbox to Foreign Artist Abgewiesen
Related to collecting_society - Webfrontend #855: add ajax request for edit permission for foreing artists Neu
Related to collecting_society - Webfrontend #860: Rework foreign objects as duplicates only Neu
Related to collecting_society - Webfrontend #859: Make group mandatory for foreign artists Neu

History

#1 Updated by Thomas Mielke almost 3 years ago

Concerning "Question: How to handle foreign artists with same email?":

How about making parts of the email address unreadable?:
thomas.mielke@c3s.cc -> tho****lke@c*s.cc
mielket@gmx.de -> mi
*et@g*x.de

This way, the email address would become unusable for dataminers

#2 Updated by Thomas Mielke almost 3 years ago

#3 Updated by Thomas Mielke over 2 years ago

  • Related to Datenbank #854: Add Group Checkbox to Foreign Artist added

#4 Updated by Thomas Mielke over 2 years ago

  • Related to Webfrontend #855: add ajax request for edit permission for foreing artists added

#5 Updated by Alexander Blum over 2 years ago

  • Status changed from Neu to Erledigt
  • % Done changed from 0 to 100
  • Note: Foreign creations don't have a release date

Ok

  • Question: How to handle foreign artists with same email?

Duplicates

  • Problem: Unknown group for artists of foreign creations

Make group mandatory

  • Note/Problem: Adding artists, created via foreign creations, as members require email

Duplicate + Ajax Request for edit permission

  • Problem: Who is allowed to edit foreign artists?

Duplicats only! Deduplication only on claiming. Email must be provided on adding = creation of a duplicate. Duplicates must reference the source to ease deduplication and to be able to easily show only one entry of all duplicats in add list.

#6 Updated by Alexander Blum over 2 years ago

#7 Updated by Alexander Blum over 2 years ago

#8 Updated by Alexander Blum about 2 years ago

  • Target version changed from 2) Testing phase II to Repertoire 2) Testing phase II

#9 Updated by Alexander Blum about 2 years ago

  • Project changed from repertoire to collecting_society

Also available in: Atom PDF