-
Notifications
You must be signed in to change notification settings - Fork 0
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
Content management interface #28
Comments
For reference, the ODA content management wiki page |
What past experience triggered us to create the role of content manager? In what ways does the content manager role overlap with what HQC does? Some of the tasks in the wiki might be outsourced from LARD, but then we need to establish where these needs should be met. (For example products, and granting access to restricted data.) Remigrating data will hopefully be unnecessary with LARD? Can we have a list of examples of changes content managers expect to make, ideally as exhaustive as possible? I very much agree with the sentiment that we should have an interface and not allow direct SQL access. For ODA, I had a mind to extend the ODA viewer to support such tasks, but at the same time being aware that I was not the ideal person for making a very stable operational service. The |
Follow on from my conversation with Vegar:
Vegar
Hei Ingrid. Håper ferien har vært bra, og at du har fått ladet batteriene tilstrekkelig til å ta fatt på en herlig høst. Jeg fikk et spørsmål fra Elinah i går, som lurte på hva slags kompetanse ho trenger som innholdsfaglig ansvarlig for PODA. Denne rollen er en geofaglig rolle, men det vil være ønskelig at de kan ha direkte editeringstilgang til databasen. Det gjelder Elinah, Ingri, Hildegunn og Ketil og jeg ønsker at de skal bruke samme verktøy og rutiner. Fint om du kan være med på å beskrive hva som må være på plass forå få til dette. Det vil avlaste deg som teknisk systemforvalter av PODA.
Ingrid
Hello. That's a good question.
If, as you say, they will have "direct editing access" then the answer is easy, they need to learn SQL, specifically PostgreSQL. However I don't think anyone should have direct access. For data integrity and provenance reasons we should keep a record of manual changes, and direct access would enable people to bypass or corrupt this record. For an example of this you can look at stinfosys, where people frequently forget (or "forget" if they're trying to cover up their own past mistake) to update the
updatedat
andupdatedby
columns. Additionally, direct access would mean they could accidentally mess with partitions, indexes, and constraints, which could seriously compromise the production database in a way that would be difficult to recover from. I don't think we should leave that possibility open.Given that, we will have to design a safe interface for them, and we will do our best to make it fit them, so ideally they shouldn't have to learn some new technology. For this though, we will need some more information. Specifically:
What past experience triggered us to create the role of content manager?
In what ways does the content manager role overlap with what HQC does?
In what ways is it different?
Can we have a list of examples of changes content managers expect to make, ideally as exhaustive as possible?
The text was updated successfully, but these errors were encountered: