Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Organisation Data Management Flag #374

Closed
adriancollier opened this issue Nov 13, 2013 · 5 comments
Closed

Organisation Data Management Flag #374

adriancollier opened this issue Nov 13, 2013 · 5 comments

Comments

@adriancollier
Copy link
Contributor

We need a way to distinguish in RSR between Organisations that are managing their own Content for their Organisations, and those that have content that can be overwritten by other Partners via an API for example.

The easiest way to determine this is to add a FLAG to the rsr_organisation table indicating that the Organisation has taken reponsibility for the Maintenance of the Organisation.

If this FLAG is TRUE then the content should not be modified by the API. This however should continue to be editable within the Admin.

@adriancollier
Copy link
Contributor Author

In addition to this Flag, we also need a Controller Identifier linking to the Organisaiton that has taken Control of the Organisation record.

This should enable Updating of the Organisation information via the API.

It should not be possible for an alternative Organisation to be able to edit or modify the contents of the record if they are not marked as the Controller Organisation.

We should allow the Organisation to still be updated via the Admin, but we should display a Confirmation box saying:

"This Record is being maintained by CORDAID. Please ensure you inform contact@cordaid.org of any changes to the data."

We should look to extend this functionality to our Network Organisation as time goes on to allow for them to Control the records of their Field and other Partners. We will look into rolling out further changes in this direction later on.

@zzgvh
Copy link
Contributor

zzgvh commented Nov 20, 2013

A day or two. Haven't thought through all details of this. Also wanna consider network partners.

zzgvh added a commit that referenced this issue Mar 3, 2014
by another organisation

Add links to the managing organisation and email of the contact.

Use support@akvo.org as fallback email if there is none for the
managing organisation.

Use the Django admin styling to highlight the message.
zzgvh added a commit that referenced this issue Mar 5, 2014
When feature branches were merged the migrations were not aligned, resulting in a mess.
zzgvh added a commit that referenced this issue Mar 5, 2014
Add new migrations for features #374 #381 #436 and #445
@stellanl
Copy link
Contributor

stellanl commented Mar 5, 2014

The API part of this issue has not been implemented yet. Should it still go in the release?

@adriancollier
Copy link
Contributor Author

no - we should edit the release notes to explain what we have developed

@adriancollier
Copy link
Contributor Author

As with #381 this has been done and checked, but we still need to do some more work on the API side, which we'll create a new issue for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

3 participants