Open pvgenuchten opened 9 years ago
Sounds like a good fix, I suppose this can occur if an 'admin' user joins a survey that already has a coordinator?
Paul, two paths to resolution here:
(i) Make the "survey designer" button blank for the person not having access to edit the survey (which is how you've described the issue above).
However, the survey metadata can still be edited by admin rights, and/or multiple coordinators which is inconsistent. Also, we would then need to address the problems where the coordinator needs to change due to the person leaving, etc.
(ii) Keep the access as is, i.e. admin and multiple coordinators can change the survey, but "move" the survey form into the "new" coordinator's area in PCAPI.
This will require a specific call to PCAPI to action. However, as discussed last week a minimum of a delete call to PCAPI needs to be introduced anyway to deal with the issue of changing a survey from Public to Private.
Ideally we need: (i) Survey changes ownership: move (copy then delete) the survey from one user to the other. (could be some issues with security here?) (ii) Survey is made public: copy the survey to the public area. (currently the form has to be re-saved). (iii) Survey is made private: delete the survey from the public area.
On 25 August 2015 at 12:12, sebastianclarke notifications@github.com wrote:
Sounds like a good fix, I suppose this can occur if an 'admin' user joins a survey that already has a coordinator?
— Reply to this email directly or view it on GitHub https://github.com/cobweb-eu/cobweb/issues/171#issuecomment-134556423.
Disallowing metadata modifications for users that are not the owner of a record is a structural change in geonetwork that i'm not in favour of. Which leaves us with a situation that, in case there are 2 coordinators on a survey, those coordinators can both modify the metadata, but only the one that created the survey-form can update the survey-form.
On each of the events you mention it's possible to hook a process to, so pcapi can be notified of such changes and act. A challange may be a case that over time events may not get picked up (due to errors or component offline) and the two systems will not be in sync anymore. Maybe good to set up some validating service that checks if both systems are still in sync.
I think that our problem here is a different one. Thinking of it, our problem is that everyone wants to be an administrator, instead of a coordinator.
A coordinator is a user that is a "local" administrator inside a group. If that group only have a "local" administrator, no other coordinator can modify the survey.
Example: User A is a coordinator. User B is a coordinator. User C is an administrator. B creates a survey S on a new group. At this point, A has no privileges over S. A can participate on S, but A is not a coordinator on S, so A cannot edit S. C, instead, as administrator of the portal is like god. He can edit S. But, in doing this, he is breaking the survey on the PCAPI side.
Being an administrator instead of a coordinator is a great power. With great power comes great responsibility. If our administrators can't understand that they have privileges to break things, then they shouldn't be administators.
So the question is the same as on basecamp: Do we need more than one coordinator on the same survey/group? Do we need to change a survey from A to B? If that's the case, we need some kind of endpoint on PCAPI where we can call and warn PCAPI of the change of coordinator or of the eventuality of having more than one coordinator.
Above situation can occur if multiple users in a group have the coordinator role. Although we mentioned in the docs a group should only have 1 coordinator, apparantly the situation with multiple coordinators is occuring. PCAPI only allows the survey-creator to update a survey. Suggestion is to show the "modify survey" button only if the user is the owner of the metadata, in geonetwork this is the user that created the metadata.