## WeBWorK Problems

### Re: Editing problems in a local library

by Alex Jordan -
Number of replies: 0

Oh, I didn't realize that symlinks used in this way would still allow users to edit. The difference with these files and OPL files is permissions, but you would not want to change permissions to prevent editing from the regular course, or else the the files would be unwriteable in the library course too.

The code controlling this is:
https://github.com/openwebwork/webwork2/blob/488d48e77d5672a4dab61ab7e359dc09fd247d38/lib/WeBWorK/ContentGenerator/Instructor/PGProblemEditor.pm#L373

and it's just based on whether the www-data user can write to that file.

Hmm, then it seems that precisely what you asked for can't be done right now. For what it's worth, I do our library management the following more complicated way:

1. Our local library is a git repo inside the libraries/ folder (so parallel to webwork-open-linbrary)
2. For each instructor who might do edits to the core library they have a dedicated course. (For you, maybe you are the only such instructor.)
3. In each of those special courses, there is a folder that is a copy of that repository.
4. If instructor X wants to edit a core library problem, they edit it within their development course. Then they notify me.
5. I sign into the server, navigate to their library folder, and run git diff to examine their edits or additions. If it's all good, I commit their edits. (And it's all set up to credit the commit to that instructor.)
6. Then I run a script that pushes each of their course git repos the the core repo, and then pushes back from the core repo out to each of thosthee instructor repos.
It ha s lag from when they make an edit to when they see that edit live in their own courses. But also there is a bit of quality control since my eyes go over the diff.