collecting_society

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.

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.

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.

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.

What first question?

than one:

The commit of a release implies the commit of creations?

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

should be answered by #324, right?

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.

ok.