Closed stefandesu closed 2 years ago
Also don't forget to adjust the tests if this functionality is changed. 🙈
Currently, jskos-server overwrites the
creator
andcontributor
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:
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.
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.
I'll try to summarize editing editing and how it should affect creator
and contributor
:
Creation of entities:
contributor
from payloadanonymous==true
remove creator
from payloadauth==true
use authenticated account as creator
of payloadcreator
of payloadThus a newly created entity can have arbitrary contributor
and
creator
for anonymous==true
creator
for auth==false
creator
for auth==true
Update of entities:
contributor
from payloadanonymous=true
remove creator
from payload and existing entityauth==false
take creator
from payload to existing entitycrossuser==false
use authenticated account as creator
of payloadcreator
, use it to update the existing entitycreator
from existing entity and add authenticated account to contributor
unless it is already listed in creator
or contributor
of the existing entityThus modification of entities
contributor
from payload (but may add the authenticated account under certain conditions)creator
if anonymous==true
creator
if auth==false
creator
if crossuser==false
creator
. If the client does not wish to do so, creator
and contributor
are adjusted automatically.Note that we have two use cases for crossuser editing by authenticated users:
identities
can modify vocabulary records, no matter if listed as contributor/creator or not (crossUser=true
but limited to selected identities
)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?
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.
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
I started implementation in branch issue-153
. The tests haven't been adjusted yet.
I have now implemented the changes, but with a few modifications that I thought made more sense:
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.)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).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.
Currently, jskos-server overwrites the
creator
andcontributor
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)creator
to be adjustable as well and contain multiple people (currently, it will always contain only the identity of the person performing the request)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
orcontributor
, and that it should definitely be increator
for POST requests, for example), but keep the changes that were performed.What do you think, @nichtich?