<p>To completely automatically install taskwarrior with a single click, this repo should first automatically install wsl and then compile the <code>autoInstallTaskwarrior.jar</code> file from source code.</p>

This automatically removes requirement for the user to trust me without the user having to do anything extra.

      <p>Perform test that verifies the background sorting script of the multi-device setup, on the server device.<br>

Test it directly after installation, and delete/purge the tasks used to test the sorting script.

In case of backup restoration, perform sorting test before importing backups.

      <p>Develop a better understanding of the consequences for the security of your taskwarrior data, and your device in general based on the design choices made in the implementation of the automatic installation.</p>

Key topics in this perspective are:

• The current certificate trust setting is not set to strict as recommended on: https://gitpitch.com/GothenburgBitFactory/taskserver-setup#/14/7
• What is the consequence of not using Let's Encrypt as listed on: https://gitpitch.com/GothenburgBitFactory/taskserver-setup#/13/4
• The current certificate validation procedure in light of: https://gitpitch.com/GothenburgBitFactory/taskserver-setup#/9/2

      <p>When the user sets the estimated duration, use the previous estimated durations, compare those to the actual measured durations in timewarrior, and update the new estimated duration accordingly using a bayesian update <a rel="nofollow" href="https://arxiv.org/pdf/0901.1342.pdf">https://arxiv.org/pdf/0901.1342.pdf</a>.</p>

(Also if automatic scheduling is implemented, give warning if user appears to not be able to make task deadline #7 .)

Check whether all files required for backup restoration are present before initiating the restoration.

      <p>Between <code>lines = readLines(backlogPath, backlogFileName);</code> and method <code>CreateFiles.writeFileContent</code>, the user has the time to enter taskwarrior commands that should imply changes in file <code>backlog.data</code>.</p>

However currently the changes made in that timeframe are lost, since after the delay between reading the backlog.data file and writing the modifications to it, the modifications are written to backlog.data, even though the modifcations did not yet take those user commands into account.

Two solutions could be:

• Temporarily block access to the backlog.data file while modifications are being computed.
• Deleting/temporarily renaming the backlog.data file, reading it, computing the modifications, scan if there exists such a backlogfile:
  1. if there does not exist such a backlog.data file:
     1. a Write the modifications to it,
  2. if there does:
     2.a Delete/temporarily move that new backlog.data file, copy it's lines (except for the tw uuid) and append them to the bottom of the modified backlog.data and again check if there exists such a backlog.data file (step 1): (where the modifications and the new lines from the new backlog.data file are written together in 1.a)

If there does, just repeat step 2. until the user did not enter any taskwarrior commands that modify the backlog.data file in between modification processing time.

Todo: Find out what happends if the user command changing backlog.data and sorting read backlog.data action are extremely close together, e.g. that the user changes are still being written while the custom sorting read backlog.data action is being sent already. (And vice versa). To determine if there can occur any loss in user modifications in the very slim chance of simultaneous occurrence.

      <p>Currently the methods <code>getInternalBackupScriptPath</code> and <code>setInternalBackupScriptPath</code> of class/object <code>InstallData</code> are still used to manually/hardCode the file names and destination folders in the class <code>HardCoded</code>.  That is currently doubly hardCoded, they should only be set with the <code>Resource</code> object instead of separate lines:</p>

installData.setInternalBackupScriptPath("src/main/resources/" + installData.getPackageName() + "/"); // TODO:
																												// change
																												// usage
																												// to
																												// Resource
																												// object

Furthermore, the installData.getInternalBackupScriptPath are currently still used throughout the project, even though this information should be asked (with a switch statement based on filename) from the Resource object (which is inside InstallData).

So TODO:

1. Remove the separate hardcodings of the resource files named:
   JavaServerSort.jar and autoBackup.sh.
2. Change the getters for their data (name, source path, destination directory) from the current InstallData object to the Resource object inside InstallData.

Look at #83 before fixing this.
As explained in: https://groups.google.com/forum/#!searchin/taskwarrior-user/brutus%7Csort:date/taskwarrior-user/dsOzdYSKaM4/h0SwTFvjBwAJ

What about a config setting?

Have a look at https://taskwarrior.org/docs/hooks2.html, and you'll see a hook is passed the location of the .taskrc file as an argument. So you could search that file for your setting.

This also works from CLI:

[:~] $ task _show | grep custom.value
custom.value=10.3

However, I'm not sure you can call the task binary directly from inside a hook, you'll have to try that and see if anything freaks out.

      <p>Use the (heartrate) data of fitness trackers and compare it to the maximum urgency throughout time, to visualize correlations/patterns. This could provide a better insight in how your behavioral changes, such as:</p>

1. Better planning (leading to lower {avg} maximum urgencies)
2. Different task completion strategies (leading to lower {avg} maximum urgencies)
3. Etc.

correlate to your resting/avg heart rate and or undesired heart-rate fluctuations/peaks.

      <p>Currently errors in the input values of the arguments to the <code>AutoInstallTaskwarrior.jar</code> are checked only during running of <code>AutoInstallTaskwarrior.jar</code>. However, before that can run, the wsl needs to be downloaded and installed, java needs to be installed in the wsl, that all in all takes about 10 minutes.</p>

One does not want to make the user wait 10 minutes only to find out the user did not enter commands that can be processed correctly/(entered erroneous configuration settings). Hence you want to check immediately upon asking what kind of taskwarrior configuration the user wants (guided, closed questions), whether the responses can be processed correctly.

And request improved user answers (with suggestive feedback) directly, so that once the installation is underway, the user can go and do something else (unattended installation).

TODO:

1. Decide on which script type/programming language the installation setup.<extenstion> is written.
2. Write all required user questions (from AskUserInput.initialiseQuestionsPreInstall()).
3. Implement immediate user answer validity, and ask improved input if required.

      <p>Currently the user must copy a url from a terminal, open a browser and copy the url and press enter before it can grant taskwarrior access to google calendar synchronisation. This can be automated by:</p>

1. Create
   name: firstGcalSync.sh
   location: Taskwarrior-installation\AutoInstallTaskwarrior\src\main\resources\autoinstalltaskwarrior/
   how: Using java class CreateFiles.java of project AutoInstallTaskwarrior.
   When: during the installation/execution of AutoInstallTaskwarrior.jar
   Content:

#!/bin/bash
cd /home/testlinuxname/maintenance/gCal/
sudo /home/testlinuxname/maintenance/gCal/tw_gcal_sync --gcal-calendar "TW Reminders" --taskwarrior-tag remindme

where testlinuxname is replaced with the variable linux user name.

2. then after having installed taskwarrior, install tw_gcal_sync.

3. Then find:
   name:GCalSide.py
   location:/home//maintenance/gCal/taskw_gcal_sync/`

4. Then find the line: creds = flow.run_local_server() (around line 188) and put the following code above it:

file = open("url.txt","w")
file.write(flow.authorization_url()[0])
file.close()

5. Then copy:
   name:firstGCalSync.sh
   location: Taskwarrior-installation\AutoInstallTaskwarrior\src\main\resources\autoinstalltaskwarrior/ to the place dependending on protocol to make code run once at startup.

6. Then, start a background loop script with powershell start process that
   Content:

First check if `url.txt` exists, if it does/is found:
copy the url that is in it,
Modify the url by putting the (hardcoded) http redirect url in in it 8080
then pass the url to powershell
In powershell find the favorite browser
open the url in the browser.
Then start checking whether the url.txt is deleted. If it takes longer than 2 minutes, restart the ask command, as the user might have accidentally closed the wsl popup window.  and restart checking for the run.txt file

TODO: Determine whether you can run the command inside powershell, automatically open the browser in the background, this way, you don't run the risk of the user accidentally closing the popup window. It is just the background process that is a limiting factor.

7. Then run the vbs that opens an external shell that boots the wsl for the first time, and hence runs the firstGcalSync.sh.
   Name: tbd
   location: tbd
   Content:

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "wsl"
'Dim objIE

' Create an IE object

'Set objIE = CreateObject( "InternetExplorer.Application" )

'objIE.Navigate "about:blank"

' Wait till IE is ready
WScript.Sleep 6000
'WshShell.SendKeys "/home/testlinuxname/maintenance/gCal/./askSync.sh > /mnt/c/temp/output.txt"

'WshShell.SendKeys "/home/testlinuxname/maintenance/gCal/./askSync.sh >> /mnt/c/temp/output.txt"

WshShell.SendKeys "/home/testlinuxname/maintenance/gCal/./askSync.sh"
WshShell.SendKeys "{ENTER}"
' Create an IE object

'Set objIE = CreateObject( "InternetExplorer.Application" )

'objIE.Navigate "about:blank"

' Wait till IE is ready
WScript.Sleep 6000
'WshShell.SendKeys "^(c)"

'WshShell.SendKeys "exit"

'WshShell.SendKeys "{ENTER}"

'WshShell.SendKeys "exit"

'WshShell.SendKeys "{ENTER}"

Without the abruption, that waits, until the user has granted permission. Once the user has granted permission, delete the url.txt file

      <p><strong>Problem</strong><br>

Currently the creation date/time of tasks is set and fixed to 20170714T024000Z. That yields a list of 2000+ tasks in 2019, since the customSortServer script takes almost a second per task, the integration test duration is currently over half an hour, which is too long.

Solution
Read the current date and time, and make the task 2 days before the current date and time, this means only 2 recurrent child tasks are created, which yields faster integration tests.
To convert the date/time you can use the "HelperScript.java".

When running a cronjob, it can be difficult to pass all the arguments to the javaServerSort.jar file. As a solution, you can either:

1. Put all the arguments between "" quotation marks to put them in a single string element, as currently is the case in the way the args are read.
2. Put them all separately after the java -jar JavaServerSort.jar -argName0 -argValue0 -argName1 -argValue1.. command.
3. After the arguments are passed to the JavaServerSort.jar file the first time, create a config file that contains the arguments which is checked for existence, before checking the incoming input arguments.

      <p>Currently in method <code>Main.assignCustomSortToTw</code> the customSort parameter is set to taskwarrior (and hence <code>pending.data</code> and <code>backlog.data</code>). However, this is done with one command per task, limiting the speed at 137 tasks/minute. To improve the speed of setting the cSort parameter:</p>

1. Write the cSort value to the pending.data file directly. (do not modify the modification date)
2. Write the cSort value to the backlog.data file directly. (do not modify the modification date)

By not modifying the modification date, the actual user actions are preserved, and the automatic sorting procedure is not tracked in the backlog.data. This way, the task undo function actually undo-es the last manual user action, which is what the user expects to happen, instead of modifying a relatively irrelevant cSort parameter.

Note:
A contributor/developer of the taskwarrior software recommends AGAINST modifying the pending.data and backlog.data files directly in this discussion: https://groups.google.com/forum/#!topic/taskwarrior-user/uD18qnlAgCg.

There are two alternative solutions suggested:

1. Instead of numbering the task custom sort order, make the task point towards the next task, this way, you don't have to modify e.g. 800 tasks if you just need to swap 1 task from the end of the row to the start of the row (cause all 800 tasks inbetween should have their cSort value incremented by 1 {and this increment would clutter the backlog.data file.}).
2. Instead of numbering the tasks 1 to n (where n=number of tasks), distribute them uniformly in the cSort value space, e.g. if it is an integer in range [-123.456.789,123.456.789] distribute it uniformly over that range, that way, if you want to swap a block you again uniformly distribute that block between the space of the tasks where it should go to, etc etc. This allows the other numbers to stay in their place, (because they don't have to increment with the number of tasks of that block that got before them in row). This way the list-reorderings are semi-O(1).

I think these are awesome solutions, yet I have the following issues with my current known possibilities of implementing them:

Regarding solution 1:

• I have not yet determined how those points/that linked list would be read by taskwarrior to generate a custom report in an instant, (without actually again needing the list of numbers indicating their order, which taskwarrior can sort.) So in essence this issue requires me to determine whether taskwarrior can sort on next and previous tw uuid/id references.

Regarding solution 2:

• I have not yet specified how to detect a conflict where the tasks do not fit between the tasks where it should fit to, e.g. if the task in slot 17 should go between task slots 15 and 16. This should be checked before every re-ordering, and if it occurs all tasks should be re-distributed over the integer space again.

Regarding both solutions:

• They both still store every change in the order of the custom sort of each task. It is very nice to have the tasks sorted in that custom order, but the values of the custom sort parameter are completely irrelevant to the user. Since the change is stored in backlog, chances are large that when the user wants to undo his/her/it's last action, that it will be undoing a change in the customSort value of a random task, when they actually expected to undo their last known action. This hinders the user, and I think it should not occur, therefore I do not think there should be a record of the changes of the customSort order in the backlog.data and pending.data files. However to prevent any errors/inconsistencies I do think the actual values should be present in the backlog.data since they (currently still) have to be present in the pending.data to allow taskwarrior to sort them on the cSort parameter.

Hence my solution is to write the cSort parameter and it's value directly to the backlog.data and pending.data without changing the modified date or adding an extra entry in them. This way, if the user does "undo" it will actually undo the last manual user action.

I have 2 problems with my compromise:

1. I dislike asking advice and then thinking: "ah, okey that's nice but I'm not going to do it", especially not if it's from such a qualitative source. I currently see the following patterns in this behavior:
   1.a I am stubborn pushing my own way, which leads to sub-optimal performance.
   1.b I got attached to my code/work and wrongly biased against changing/abandoning it.
   1.c I did not formulate my question correct, complete and accurate, leading to a technically correct answer that does not actually (enable me to) solve my problem.
   1.d I am too lazy and biased to think in terms of how I can implement the suggested solutions without violating the backlog.data constraint mentioned above (regarding the user task undo command).
   1.e I am too lazy to think about approaches that accomplish the goal of generating a list that sorts tasks on: project, no project/urgency and urgency if it is above a specific threshold, without violating the above mentioned issues.
   1.f The expert was incomplete/wrong (unlikely).
2. Manipulating the backlog without using the task command interface means it can produce errors as some parts of the taskwarrior code or hooks might require a consistency in the backlog.data and pending.data files that is violated by not modifying the modified parameter on the moments the tasks (cSort parameter) are(is) modified.

Assuming the renewed TW-install requires WSL (which seems plausible):

The user currently still must manually click>Control panel>turn windows features on and off>enable Windows Subsystems for linux(WSL) reboot, and open/run the setup.exe.

Automate the "enable wsl services" after the setup.exe has asked the user for input, and continue the installation. (E.g. by creating a windows run once at startup task).

      <p>I personally would find it interesting to see if there are any effects measurable due to receiving a more human/intuitive feedback (<a rel="nofollow" href="https://player.vimeo.com/video/128835008">https://player.vimeo.com/video/128835008</a>) on your:</p>

1. performance
2. procrastination
3. task completion strategies
4. etc.

By feedback visualization in a more conversational form instead of written text (and already very informative graphs). I could imagine this could be combined with positive reinforcement^ etc. to convert behavior to accomplish ones individual goals at a higher rate than current plain text/visual graphs do.

^ TODO: Document behavioral research to indicate which reward strategies are scientifically substantiated/proven:

1. up to what extend
2. In which scenarios
3. and what their issues are
   and determine a strategy/list of strategies from which the user can chose.

      <p>Use the (sleeping) data of fitness trackers (such as fitbit) and compare it to the maximum urgency throughout time, to visualize correlations/patterns. This could provide a better insight in how your behavioral changes, such as:</p>

Better planning (leading to lower {avg} maximum urgencies)
Different task completion strategies (leading to lower {avg} maximum urgencies)
Etc.
correlate to your sleep quality.

      <p>Concerning file: <code>/resources/autoBackup.sh</code><br>

Currently the backup procedure checks whether the backup destination folder has been modified in the last minute, to check whether the backup procedure should make a new folder for the backup command, or whether it should put the backup files in the already existing folder.

If the backup takes longer than a minute, this mechanism will check the wrong folder to determine whether it should create a new folder or put it in the already existing project, that would spread a single backup over multiple folders. this is undesired.

Hence the backup procedure needs to be adapted.
Either it must automatically backup every task change (with the exception of customSort changes), or it should backup every x minutes and make a separate backup folder for its backups that also includes the time without spreading the backups to multiple folders.

      <p>A task sync init should only be executed once, the first time you sync taskwarrior.</p>

Currently, line 168-173 of ModifyFiles.java of method createLinesBashrc ensures the bashrc file checks if a boolean file that indicates it is the first time sync exists.

If the boolean file named getInitBool does NOT exists, it does treats it as not the first sync initiation. That means the getInitBool must remain existant until the end of time, or taskwarrior usage to prevent an unwanted task sync init.

It is safer to create that getInitBool file at the end of the tw installation (if it is a server/host installation), and to reverse that check, so that it just does a task sync init once at the first run, if that file exists, and then deletes the file.

      <p>Ask the user if the user wants to set a file limit, and if yes, set a curve that determines what the time interval is to keep backups, (E.g. higher density near near future, than to past.)</p>

The non-linear distribution is because the difference between 5 years ago, and 5 years and 1 day ago is less important than the difference between today and yesterday for (most) humans. So you don't want to keep track of every small change long ago if your backup size is limited.

Hence to apply the distribution over a varying amount of time, delete backups as time goes along (such that you approximate the chosen distribution closer with every distribution).

TODO: Determine whether this distribution pursuit actually approaches the distribution.

      <ol>

Initially the user would have to manually install WSL, then open WSL, run 2 commands to install java and then run the installation .jar. However when issue #11 is fixed, the installation will be performed from/starting in Windows, so it should be possible to also install taskwarrior on android through adb from Windows.

However initially I tried to do it from java in Linux, this is the attempt:
Initial attempt to install taskwarrior on android phone from wsl ubuntu:
source: http://sonntam.github.io/build-adb/

cd ~ mkdir android cd android
sudo apt-get install git build-essential libncurses5-dev git clone
https://android.googlesource.com/platform/system/core.git system/core git
clone https://android.googlesource.com/platform/build.git git clone
https://android.googlesource.com/platform/external/zlib.git external/zlib git
clone https://android.googlesource.com/platform/bionic.git git clone
https://android.googlesource.com/platform/external/stlport.git
external/stlport git clone
https://android.googlesource.com/platform/external/libcxx.git external/libcxx
git clone https://android.googlesource.com/platform/external/openssl.git

External/openssl Problem: requires python version of windows to be identical.
(which requires users to enter additional commands outside the WSL, or reboot
their entire pc)

This difficulty is overcome by installing taskwarrior from Windows in stead of WSL because the python version for adb does work in Windows (because it does not need the Windows python version to equal the Linux python version).

      <p>Currently files belonging to the <code>tw_gcal_sync</code> repository modifications are put inside maintenance, because the <code>gCal</code> folder needs to be empty when the repository is cloned into it.  Then they are moved into <code>/gcal/taskw_gcal_sync</code> after the repository is cloned. If there is a separate folder named <code>repository</code> made inside folder <code>gCal</code>, then <code>askSync.sh</code><br>

,insertCode.sh,customLocalServer.py can be copied into gCal which generates less clutter inside folder maintenance.

Moving askSync has an effect on the automated url opening, as some of the comands to get the url (e.g. insertCode or .. inherit the current/working directory in which the askSync is located.) *This most likely also holds for the first sync command in AskSync."

      <p>Ask user to give range of working hours.<br>

Ask user to plan in free time.

Ask user which calendars take priority in conflicting scheduling with taskwarrior.

Then automatically schedule tasks with gcal sync according to the (bayesian update) estimated duration of the tasks.

(Find opensource scheduling software that takes into account traveling with e.g. bike car public transport, spaceshuttle etc.)

      <p>Currently, the <code>cSort</code> attribute (UDA) of all tasks are modified if a single task is put on top of the list, (that task gets <code>cSort=1</code> and all other task <code>csorts</code> get incremented by 1). File backlog.data stores all versions of a task, so if a task is created or changed, that task is added at the end of backlog.data. Hence, the <code>cSort</code> index storing inflates the backlog to over 34 mb, 24000 lines with 800 tasks within a few hours.</p>

As a symptom-remedy, I scan the backlog for tasks that only contain a modification of cSort, and then merge the two:

• The first of the two tasks in backlog (based on modification date) gets copied, but it's cSort is updated/changed with the cSort of the last modified task.

This ensures the backlog still only contains the actual manual changes of the user, in chronological order, but with the most recent cSort value such that it does correspond with the most recent task custom sort order.

Problem:
Modifying the backlog.data file directly is considered bad protocol according to experienced taskwarrior users:
https://groups.google.com/forum/#!topic/taskwarrior-user/uD18qnlAgCg

Solutions given:

1. The solution that was suggested to me was to not number the tasks 1..n tasks, but to spread them uniformly over the whole range of integer values allowed by taskwarrior. Then if you need to put the last task to the 2nd place, you put it exactly between the first and second value. This way you do not need to update the entire second to last task.
   E.g.:
   In stead of csorts: 1,2,3,4,5>1,3,4,5,2 write it as: 1,100,200,300,400,500>1,50,100,200,300,400,500

2. If you are mostly swapping blocks instead of single tasks, don't write the position of the task in cSort, but write the task id or uuid that points to the next task, in cSort. This way you need to only modify 2 or 4 tasks if you want to move a block of 100 tasks.

One should think what happends if the integer spaces between certain tasks are filled in applying the former, and what happends if a task gets purged in the latter. Preferably test these scenarios.

      <p>Create an installation data log that does not include the certificate key generation, nor ansi-random art.<br>

Do not include sensitive data.

This facilitates troubleshooting.

      <p>If you import a backup of a few months old, that had a few (10+) daily recurrent tasks, there are a lot of tasks in taskwarrior. Even so much that it can be difficult to gain oversight and delete/complete the correct tasks.</p>

Therefore you could built a quick scanner that deletes all but the last 1 or 2 or n of the recurrent tasks if their amount is over m child tasks.

      <p>Currently a minimal replicate of the original "HardCoded" object is re-created inside the job that scans for emergence of the url.txt to automate asking permission to sync with google calendar.</p>

This means there is code duplication, and it implies a 4th location in which (duplicate) hardCoded data is stored. That is undesirable.

Therefore, pass the HardCoded object to the background job rather than recreating it.

Source: https://stackoverflow.com/questions/15382728/passing-native-object-to-background-jobs
Example:

# live object to be passed in a job and changed there
$liveObject = @{ data = 42}
job script
$script = {

param($p1)

$p1.data # some output (42)

$p1.data = 3.14 # change the live object data

}
create and start the job
$p = [PowerShell]::Create()

$null = $p.AddScript($script).AddArgument($liveObject)

$job = $p.BeginInvoke()
wait for it to complete
$done = $job.AsyncWaitHandle.WaitOne()
get the output, this line prints 42
$p.EndInvoke($job)
show the changed live object (data = 3.14)
$liveObject

      <p>After completion of a functioning single click installation of the complete setup, build a version of the project into an installable Windows Store app using: <a href="https://github.com/microsoft/WSL-DistroLauncher">https://github.com/microsoft/WSL-DistroLauncher</a>.</p>

Include user experiences.

      <p>##Problem##<br>

In order to clone the gCal sync process to folder /home/<linux username>/maintenance/gCal/, the gCal folder must be created, howerver, a file called gCal is created with the content of the customLocalServer.py.

##Prediction##
Probably because changing a hardCoded name to a variable name returned a null value instead of a correct value, which reduced the target path to end in gCal instead of gCal/customLocalServer.py. That would mean the copy of customLocalServer.py would be renamed to a file named gCal.

##Prediction analysis##
However, a thought and a combination of thought and observation contradict this prediction:

1. I think the customLocalServer.py was not hardCoded in the first place, and I think that has been the only change since this problem has arisen.
2. I think the customLocalServer.py is only exported/copied once (unless it is moved afterwards from maintenance to maintenance/gCal/taskw_gcal_sync to allow an empty gCal folder for cloning the repo), that would mean that the exporting of customLocalServer.py failed but it has not failed, the file is exported correctly.

      <p>Powershell automatically recommended to store the String that temporarily stores the password during installation, in a differrent type than String.  It is a good exercise to implement, additionally try to find out how this new type can be passed securely to the Java <code>.jar</code> as argument.</p>

(Note, do not generate a false sense of security just by changing the type, since it still has to be passed to the .jar file which currently still happens as a String type.)

Primary goal

Build a CLI with a yes-no prompt that allows the user to specify its preferred array of hook-scripts to be installed with Taskwarrior. (Allow for overriding/specifying the hook-script combo based on command-line arguments).

Secondary goal

Ensure the users can simply click in a list which hooks they want to automatically install in their taskwarrior setup.

• Determine how step 2 can be achieved "best". Look into current hook script installation procedures on; https://taskwarrior.org/tools/

Ubuntu

TBD what an appropriate installation GUI would/could be.

Windows

This is preferably done in combination with the wix installer (normal installation with GUI), but another/web GUI would be possible too. There are three goals in this issue:

Mac

TBD what an appropriate installation GUI would/could be.

Ternary goal (timewise, not prioritywise) goal

Make it as simple as possible for hook creators to add their hook to the auto installation setup, by creating a flexible format that can execute:

• python
• powershell
• jar
• etc.

scripts that are created/included by the developers to install the hooks.

      <p>Currently the following 3 files contain the hardcoded data:</p>

1. /AutoInstallTaskwarrior/src/main/java/autoinstalltaskwarrior/HardCoded.java
2. /Taskwarrior-installation/CustomSortServer/src/main/java/customsortserver/HardCoded.java
3. /AutoInstallTaskwarrior/TaskwarriorInstaller.ps1 (class HardCoded)

Write this data into a single file called HardCodedData.txt and write 2 parsers:

1. A java parser
2. A powershell parser

that absorbs the relevant data from the from the HardCodedData.txt file into their respective files.

This reduces probabillities of errors due to incorrect bookkeeping by not having to update the hardCoded data in 3 places as currently is required, but in only 1.

      <p>To test the security of the setup, first verify the sync functions properly, then modify 1 letter in the certificates and check if the sync worked.</p>

Test for scenarios:

1. Change in host:
   1.1 Modify a single character in: ca.cert.pem
   1.1 Modify a single character in: .cert.pem
   1.1 Modify a single character in: ,key.pem
2. Change in client
   2.1 Modify a single character in: ca.cert.pem
   2.1 Modify a single character in: .cert.pem
   2.1 Modify a single character in: ,key.pem

And report the results here and in a general text describing the weaknesses in the security of the current implementation of this installation procedure of taskwarrior.

      <p>(One of )the goal(s) of taskwarrior is to lower the maximum urgency you experience in your life. This could perhaps be stressreducing.</p>

That means, that if one is successfull in doing so, the urgency threshold would become too high over time (as the max urgency would sink below the urgency threshold). This would render the customSort overview less usefull/useless.

A solution to this problem can be to set the urgency threshold as a fraction of the maximum urgency instead of as absolute number. This means you will get the most urgent tasks at the bottom as long as they are above the urgency threshold (which has become dynamic).

Implementation:
0. Ask user to set the urgency threshold as a percentage of the maximum found urgency of all tasks.

1. In customSort update the absolute treshold value before every sort, based on this percentage and the max urgency.
2. (Also update the absolute value of the urgency threshold in the task config if it still exists).

      <p>Currently taskwarrior version 2.5.2 is installed through apt-get. Instead, ensure taskwarrior 2.6 is downloaded and built/compiled from source during the installation process.</p>

This introduces the task purge command to the setup, to allow one to delete a task such that it is not just moved to completed, but actually removed.

      <p>Put a <code>twInstallConfig.txt</code> file in <code>/home/&lt;linux username&gt;/maintenance/</code> that contains the configuration settings of the installation.</p>

Then make a script that scans all the folders/users in /home/ and inspects whether it contains that twInstallConfig.txt file in ../maintenance/. If it is found, read:
the username that contains the taskwarrior installation, and the direct path to the pending.data etc. files.

Preferably build the updates such that they can be added onto, rather than overwritten to, the current tw installation.

However, if need be, and a new installation is required for some reason:

1. Ask permission of the user,
2. Tell the user to make a backup of additional files that were added to the wsl beyond this tw install.
3. Make a backup of the pending.data etc. file
4. lxrun /uninstall /full /y uninstall the wsl.
5. Re-Install the new updated tw setup.

      <p>It can be a bit of a challenge, especially for unrooted phones, to copy the 3 certificates of the host into the correct target destination on your phone. And it can be considered a hassle to have to copy and paste those files from one pc to another if you want to install it on a client.</p>

This can be made simpler, by automatically setting up a temporary ftp server on the host pc that requires a username and password to send the 3 certificates through an encrypted connection to the extra device.

The installation bash installation scripts might be a bit intimidating. A solution to this may be to package them into a "normal" installation window with a clickable Graphical User Interface (GUI). From my brief research, it seems that WIX is a practical tool to create such setup.exe files.

This also facilitates making a checkbooks of all the plugins/hooks/hook scripts that are built to enhance taskwarrior.

      <p>In order install taskwarrior in the user account of the username, sudo rights are (currently) required. This means the user would be prompted for the linux user password during installation. This is conflicting with the requirement of 1 click installation.</p>

So either, taskwarrior could be installed to root, to prevent the user password asked (since nothing will be shielded by a password, since the root has access to everything). The reasons are not yet crystal, but it is not desirable to have the user do everything in root. For example it could be more easy to break the parent/actual device without any protection.

Hence the user will be asked to create a password for the WSL Ubuntu account. This password is asked in a powershell script. Preferably:

1. The password is not stored on the hdd, but only kept in memory temporarily.
2. The password is passed directly to the compiled .jar file through an api/as argument
   2.1 E.g. as arg to Main.
3. Currently I don't see any possiblity/advantage of hashing that password since it needs to be replicated when prompted for during the execution of the .jar file. Hashing only allows checking whether something equals (the MD5 checksum) of the original password.
4. Currently I don't see any possibility/advantage of salting the password, as salting is applied to make brute forcing hashes with common password dictionaries (rainbow tables) more difficult by adding (random) characters to increase the password length.

So any advice on benefits and methods to implementing point 3. and 4. are more than welcome!

Otherwise, make sure the setup.ps1 script passes the userpassword directly to the AutoInstallTaskwarrior.jar script. And document the security implications of this strategy:

1. How can the password be intercepted?
2. What are the consequences if it is?