Konzept #270

Behaviour after user deleted an object?

Added by Alexander Blum over 4 years ago. Updated about 2 years ago.

Status:ErledigtStart date:
Priority:HochDue date:
Assignee:Alexander Blum% Done:

0%

Category:-Estimated time:1.00 h
Target version:Repertoire 1) Testing phase I

Description

Context: A web user deletes an object (e.g. an creation).

  • Right now the active flag is set to false.
  • Right now, other web users are presented with only active object lists (e.g. creations) for selecting relationships (e.g. derivatives).

What is the desired state after a deletion of an object by the web user?

  • If non active objects (e.g. creations) are presented to other users, we assume it to be a valid object (e.g. creation), but it is not clear, if non active objects should be claimable again
  • If a user makes an error, he probably might not want to have invalid objects (e.g. songs) to be referable. We also might not want that.
  • If we just remove the relation of the web user to the object instead of deactivating the object, this can't be considered to be "deleted" from the perspective of the web user.
  • If we don't allow users to delete objects, this might be quite irritating
  • If we add another administrative workflow, to decide, if the user deletion results in a deactivation instead of a disassociation, we might have a lot more work to do.
  • If we allow deactivation without reclaiming, someone could register and claim all unclaimed objects (added by other users, e.g. original/derivative creations, artist members, etc.) and deactivate them.

There might be more relevant issues, but let's take this as a starting point.


Related issues

Related to collecting_society - Konzept #254: Define the cascades for creative objects Erledigt
Related to collecting_society - Konzept #324: Should objects of others be editable, if you have created it? Erledigt
Related to collecting_society - Datenbank #327: Define "Commited" States Erledigt
Related to collecting_society - Datenbank #326: Is the "Active" state still needed? Erledigt
Blocks collecting_society - Webfrontend #328: Add commit interface Neu

History

#1 Updated by Alexander Blum over 4 years ago

  • Related to Konzept #254: Define the cascades for creative objects added

#2 Updated by Meik Michalke over 4 years ago

  • Assignee changed from Meik Michalke to Alexander Blum

we should not allow users to delete works as long as they are actually existing (i.e., the release/creation is valid). users can flag it so that we don't collect any rights for it, but that's about it. the only harm this does is that we could actually recognize it when it is being used, which would be our very job even if we don't represent its authors.

it would also not make a lot of sense if a user who is genuinely an author (or any other involved party) of a creation, would suddenly want to remove his/her name from it. at least i fail to see where this would be necessary. you cannot write a song, register it, and then say you don't want to have written it.

this leaves objects which are incorrect to an extent that they cannot be corrected and the user needs to completely discard them. these obviously would be objects that should not be referenced by anyone or anything and therefore wouldn't need keeping them around any longer.

my proposal: as long as an object has not been active, users can simply remove it without a trace. consequently, the very act of activation should stress that once this step was taken, data of the object in question can still be corrected, but it can't deleted without causing a dispute case.

#3 Updated by Alexander Blum over 4 years ago

  • Assignee changed from Alexander Blum to Meik Michalke

Sidenote: The core of the problem is, that we intermingle "user data" and "internal data" used for accounting some day.

my proposal: as long as an object has not been active, users can simply remove it without a trace. consequently, the very act of activation should stress that once this step was taken, data of the object in question can still be corrected, but it can't deleted without causing a dispute case.

To prevent a misunderstanding: the "deleted" flag is already used internally in tryton for "administrative" deletetions, so we defined an "active" flag to have another layer for "user" deletions.

But, if I understand you right, you propose something like a "commited" flag?

From now on, I'll differentiate between 1st order objects (the one, which is created explicitly) and 2nd order objects (other objects created for the 1st order object):

  • artist<->artist (group members)
  • artist<->creation (authors)
  • creation<->creation (originals/derivatives)

Statements and questions:

  • After commiting an object, a dispute request is
    • triggered by
      • a deletion
      • a change of artist<->creaton
      • a change of creation<->creation
      • a change of license
      • removing a creation<->release relation
    • is not triggered by
      • a change of artist<->artist
      • adding a creation<->release relation
  • The commit of a release implies the commit of the release<->creation relations (name, license for the release).
  • The commit of a release implies the commit of creations?
  • The commit of an artist does not imply the commit of releases/creations.
  • After commiting an object, should the attributes of a 1st order object still be editable (e.g. name, label, etc.)?
  • Should it be possible, to create and commit an object in one step?
  • Should "2nd level objects" be auto commited?

I think, the complexity of the concept is obvious and needs more elaboration.

And still, if the user would delete an object before commiting, only the "active" or "deleted" flag would be set to false - no deletion is better for database integritiy. Also, the uploaded content could be archived already before a commit. If the user deletes the object, I don't want to touch the archive.

#4 Updated by Meik Michalke over 4 years ago

  • Assignee changed from Meik Michalke to Alexander Blum

thanks for explaining the difference, i think i get it now -- it's all about terminology ;-)

"committing" is exactly what i meant.

The commit of a release implies the commit of creations?

yes.

After commiting an object, should the attributes of a 1st order object still be editable (e.g. name, label, etc.)?

if it's a release i guess it wouldn't hurt, as we do dedection on creation basis, right? but creations should not be renameable without a dispute if others related to that creation already.

Should it be possible, to create and commit an object in one step?

no, i guess that will cause too many disputes because people don't get the implications. committing an object should be a conscious act on its own.

Should "2nd level objects" be auto commited?

that is the abstract case of the first question, isn't it? if so, yes.

#5 Updated by Alexander Blum over 4 years ago

  • Related to Konzept #324: Should objects of others be editable, if you have created it? added

#6 Updated by Alexander Blum over 4 years ago

  • Assignee changed from Alexander Blum to Meik Michalke

Should "2nd level objects" be auto commited?

that is the abstract case of the first question, isn't it? if so, yes.

What first question?

Maybe the related problem #324 helps to understand the question better.

#7 Updated by Alexander Blum over 4 years ago

#8 Updated by Alexander Blum over 4 years ago

  • Related to Datenbank #326: Is the "Active" state still needed? added

#9 Updated by Alexander Blum over 4 years ago

#10 Updated by Meik Michalke over 4 years ago

  • Assignee changed from Meik Michalke to Alexander Blum

What first question?

than one:

The commit of a release implies the commit of creations?

#11 Updated by Alexander Blum over 4 years ago

#12 Updated by Alexander Blum over 4 years ago

#13 Updated by Alexander Blum over 4 years ago

  • Assignee changed from Alexander Blum to Meik Michalke

Should "2nd level objects" be auto commited?
that is the abstract case of the first question, isn't it? if so, yes.

No, it's a special case, as the propagation of the commit flag would be on objects of others, see #324

#14 Updated by Meik Michalke over 4 years ago

  • Assignee changed from Meik Michalke to Alexander Blum

should be answered by #324, right?

#15 Updated by Alexander Blum over 4 years ago

  • Assignee changed from Alexander Blum to Meik Michalke

I assume auto committing of 2nd level "foreign" objects to be the only reasonable choice, as the reason for the commit mechanism is to provide stability for the user data and particularly for relations of objects. I also added cascading behavior, if a "parent" object was not commited, but deactivated: If there's no other relation to the foreign object, it is deactivated as well.

The commit of an artist does not imply the commit of releases/creations.

I'd change that, as I'll try to stick to easy rules ('maxium recursion' in this case). There might be cases, in which a web user might want to commit all releases by commiting the artist. If the reassurance screen ("Do you really want to ...") of a commit of an artist provides the information about the implication, then it should be ok.

#16 Updated by Meik Michalke over 4 years ago

  • Assignee changed from Meik Michalke to Alexander Blum

ok.

#17 Updated by Alexander Blum over 4 years ago

  • Status changed from Feedback to Erledigt

#18 Updated by Alexander Blum about 2 years ago

  • Target version changed from 1) Testing phase I to Repertoire 1) Testing phase I

#19 Updated by Alexander Blum about 2 years ago

  • Project changed from repertoire to collecting_society

Also available in: Atom PDF