-
-
Notifications
You must be signed in to change notification settings - Fork 278
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
[TW-204] read-only mode #249
Comments
Migrated metadata:
|
Paul Beckingham on 2010-07-07T23:38:24Z says: Currently this is not possible. This is because most commands perform a gc (garbage collect) before displaying the tasks. The gc is run because there are tasks that need to be moved to the pending.data file, there are waiting tasks that need to be woken up, and there are recurring tasks that may need to be created. But this is a very good idea. Task could check on startup, whether it has write permission to the pending.data and completed.data files. If it does not have write permission, then certain commands could be disabled (add, done ...) and a warning could be issued. But not all commands would need to be disabled, despite the fact that gc would definitely be disabled. If I wanted to allow someone to view my tasks, I could certainly make the files readable using file permissions, and if task then played nicely with this, it would allow interesting sharing scenarios. |
Paul Beckingham on 2011-08-24T03:44:24Z says: This is almost done. It's going to be a good feature. Just wanted folks to know it isn't going to get deferred. |
Paul Beckingham on 2012-01-28T21:54:51Z says: Support is there, but it has not been completed and tested. |
David Patrick on 2013-05-04T19:41:59Z says: As more external scripts are written, all of them have access core task-write functions, but many of them don't need that capability. Things like scripts to generate output, or calendars, there's no reason for that script to write pending.data, but still no clear way to mark the data ready-only. Maybe the solution is again hook-based, and any write-hook has to check rc.readonly:yes yes? |
Paul Beckingham on 2013-05-04T19:58:28Z says: David Patrick wrote:
Good point. There is no mechanism to convey this currently. |
Scott Kostyshak on 2013-05-05T19:56:17Z says: It's not a real solution, but an external script could copy the files to a directory where you do have write permissions and then just run the command on that task directory. |
David Patrick on 2013-05-06T16:33:51Z says: Scott Kostyshak wrote:
That's an interesting idea! I would then be worried about how that copied data is reconciled with the primary data.. |
Scott Kostyshak on 2013-05-07T00:49:59Z says: David Patrick wrote:
I might be misunderstanding the original request. Why would the copied data be reconciled with the primary data? I thought the point was that the user does not have write access to the primary data and they just want to run a command on the data but not modify it. Thus, the copied data would be deleted after the command was run. |
David Patrick on 2013-05-07T04:26:52Z says: Scott Kostyshak wrote:
uhh.. yes, that makes sense Scott, and "export" is not a write command. |
Paul Beckingham on 2014-12-27T23:00:11Z says: This is already supported in the lower layers. It needs to be completed, with front end feedback. |
Duping forward to #3418. |
David Patrick on 2010-07-07T16:57:54Z says:
for scripted execution, many queries don't require write access to the files, and shouldn't have it. Would it be possible (is it already possible) to have a read-only mode that doesn't require write access to the core files?
The text was updated successfully, but these errors were encountered: