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

[TW-204] read-only mode #249

Closed
taskwarrior opened this issue Feb 12, 2018 · 12 comments
Closed

[TW-204] read-only mode #249

taskwarrior opened this issue Feb 12, 2018 · 12 comments
Labels
type:enhancement New feature or request
Milestone

Comments

@taskwarrior
Copy link

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?

@taskwarrior taskwarrior added this to the Backlog milestone Feb 12, 2018
@taskwarrior taskwarrior added the type:enhancement New feature or request label Feb 12, 2018
@taskwarrior
Copy link
Author

Migrated metadata:

Created: 2010-07-07T16:57:54Z
Modified: 2017-01-16T17:03:20Z

@taskwarrior
Copy link
Author

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.

@taskwarrior
Copy link
Author

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.

@taskwarrior
Copy link
Author

Paul Beckingham on 2012-01-28T21:54:51Z says:

Support is there, but it has not been completed and tested.

@taskwarrior
Copy link
Author

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?

@taskwarrior
Copy link
Author

Paul Beckingham on 2013-05-04T19:58:28Z says:

David Patrick wrote:

Maybe the solution is again hook-based, and any write-hook has to check rc.readonly:yes

yes?

Good point. There is no mechanism to convey this currently.

@taskwarrior
Copy link
Author

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.

@taskwarrior
Copy link
Author

David Patrick on 2013-05-06T16:33:51Z says:

Scott Kostyshak wrote:

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.

That's an interesting idea! I would then be worried about how that copied data is reconciled with the primary data..

@taskwarrior
Copy link
Author

Scott Kostyshak on 2013-05-07T00:49:59Z says:

David Patrick wrote:

Scott Kostyshak wrote:

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.

That's an interesting idea! I would then be worried about how that copied data is reconciled with the primary data..

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.

@taskwarrior
Copy link
Author

David Patrick on 2013-05-07T04:26:52Z says:

Scott Kostyshak 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.

uhh.. yes, that makes sense Scott, and "export" is not a write command.

@taskwarrior
Copy link
Author

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.

@djmitche
Copy link
Collaborator

Duping forward to #3418.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants