Reassess `handleCreatorForObject` method

[stefandesu]

Currently, jskos-server overwrites the creator and contributor fields of all incoming entities with its own logic. There are several issues with that, however:

• contributor should always be adjustable from the outside (I think)
• Possibly it might be necessary for creator to be adjustable as well and contain multiple people (currently, it will always contain only the identity of the person performing the request)
• It conflicts with the logic we determined for #99.

Maybe, instead of completely overwriting those two fields, the method should check if certain expected things are given (like that the identity performing the request is part of either creator or contributor, and that it should definitely be in creator for POST requests, for example), but keep the changes that were performed.

What do you think, @nichtich?

[stefandesu]

Also don't forget to adjust the tests if this functionality is changed. 🙈

[nichtich]

Currently, jskos-server overwrites the creator and contributor fields of all incoming entities with its own logic.

I thought it only adds values to creator or contributor but this is not fully clear from the application of handleCreatorForObject in bodyParser. In any case we have three sources of creator/contributor data to be merged:

• existing entity
• payload entity
• authenticated account

Furthermore the logic required for #99 for editing concordances and the logic for editing concept schemes is not the same. I need to think about the other entity types first but just adding another if-branch for concordances may be easier.

[stefandesu]

My question is if it's possible to simplify and unify this logic. Do we even need to adjust the fields or can we trust the client that what they are sending is intended? Of course there need to be a few hardcoded rules, like that there needs to be at least one creator, and if there's no creator field on a POST request, that the authenticated account is added there. But other than that, I think it should be fine just removing the rest of the logic. Maybe I'm missing something though.

[nichtich]

I'll try to summarize editing editing and how it should affect creator and contributor:

Creation of entities:

• Take contributor from payload
• If anonymous==true remove creator from payload
• elsif auth==true use authenticated account as creator of payload
• else don't modify creator of payload

Thus a newly created entity can have arbitrary contributor and

• no creator for anonymous==true
• otherwise
  • arbitrary creator for auth==false
  • exactly one, authenticated user as creator for auth==true

Update of entities:

• Take contributor from payload
• If anonymous=true remove creator from payload and existing entity
• elsif auth==false take creator from payload to existing entity
• else
  • if crossuser==false use authenticated account as creator of payload
  • else (crosssuer editing)
  • if payload contains non-empty creator, use it to update the existing entity
  • otherwise keep creator from existing entity and add authenticated account to contributor unless it is already listed in creator or contributor of the existing entity

Thus modification of entities

• takes contributor from payload (but may add the authenticated account under certain conditions)
• does not include any creator if anonymous==true
• otherwise can set arbitrary creator if auth==false
• otherwise sets exactly one, authenticated user as creator if crossuser==false
• otherwise (crossuser editing) can set arbitrary but non-empty creator. If the client does not wish to do so, creator and contributor are adjusted automatically.

[nichtich]

Note that we have two use cases for crossuser editing by authenticated users:

• In bartoc.org any user listed in identities can modify vocabulary records, no matter if listed as contributor/creator or not (crossUser=true but limited to selected identities)
• In coli-conc concordance registry only some users will be allowed to create concordances (because they will be listed via identities) but all users will be able to modify concordances iff they are listed as contributor/creator (crossUser=true without identities)

The logic described in my previous comment is not about whether an action is allowed but how to set fields creator/contributor, if the action is allowed, so I think both use cases are possible by different combination of configuration of identities and crossuers (?) Originally we introduced crossuers to allow editing everything by any user, do we still need this?

[stefandesu]

I like that we are narrowing in on a solution that works with the existing system. There's just one thing that I can't fit into your solution: How do we deal with editing mappings that belong to a concordance? This needs to be handled as an exception in any case because we always need to check the creator/contributor of the concordance. I'm also not sure whether it makes sense to override the creator if an entity is updated (and the creator override is not part of the updated payload). Although, this only happens for crossUser==false and it that case, in theory, creator should already include the authenticated account.

One more thing: With your solution, a contributor of a concordance is able to change concordance metadata as well, right? This is in conflict to what we discussed in #99, unfortunately.

[nichtich]

One more thing: With your solution, a contributor of a concordance is able to change concordance metadata as well, right? This is in conflict to what we discussed in #99, unfortunately.

No, this issue is only about how the creator and contributor field can be modified. Checking whether an account can modify a record at all, is on another level. I'll try to summarize the other questions in another post

[stefandesu]

I started implementation in branch issue-153. The tests haven't been adjusted yet.

[stefandesu]

I have now implemented the changes, but with a few modifications that I thought made more sense:

• If anonymous==true, both creator and contributor will be removed from payload. However, existing values will not be removed. (Thus anonymous is only for future changes and does not affect existing entities.)
• If auth==true, the creator will not be adjusted, except for URI changes (i.e. we know that it's the authenticated user's entity and we update the main URI and name used in the creator field).
• There is no differentiation for crossUser. For auth==true, the authenticated user will always be added to contributor if they are not already in either creator or contributor.

My reasoning for this was that the creator of an entity shouldn't actually change, even if it was updated by another user, because that other user is not the creator. However, I concur that it might be necessary to allow changes in creator, for example to give another user rights to edit a particular entity. Right now, I don't think we have a use case for this though.