To delete:

• The line https://github.com/Pegasus8/PiWorker/blob/75d2e69ce78c0cd250a2f7abfa0f85fd7991a93d/processment/configs/configModel.go#L34 is don't needed due to a dynamic generation of the tokens (per user and time [expiration]).
• And the line https://github.com/Pegasus8/PiWorker/blob/75d2e69ce78c0cd250a2f7abfa0f85fd7991a93d/processment/configs/configModel.go#L47 is don't needed too due the usage of user and password.

To modify:

• The WebUI needs user and password to auth so this line need be modified:
• https://github.com/Pegasus8/PiWorker/blob/75d2e69ce78c0cd250a2f7abfa0f85fd7991a93d/processment/configs/configModel.go#L46
  Instead of that use RequireAuth bool 'json:"require-auth"'

To-do list

• Standard model

• Stats collector

• Stats storage (#10)

• Stats reading from storage

When displaying existing tasks created by the user (in the Management view) it is necessary to use two APIs (at least):

• One that obtains the information of the elements (triggers and actions)
• Another that obtains user data

The difference between the two is the next: the API that grants the information of the elements has only that, information, which is used to guide the user in the creation of the tasks (among other things), while the API that returns the data of the user only provides the data. Both are complementary to each other, since you cannot display loose parameters on the WebUI, because the user would not understand where each one comes from.

What is needed: fetch the data of the API that provides the info at the start of the WebUI, and when needed fetch the data of the API that provides the user data.

There is no sense in having both separated. Must provide the functionality of execute actions on some predefined time.

Discriminate tasks by their state.

Must provide logs of: tasks (of each separately) and global logs.

Related with #2.

Must be by using a channel. This channel whould be instantiated on main() and sended as an arg to the server and the loop of statistics.
Usage: the statistics loop will be responsible of sent the statistics by the channel to the websockets active connections.

Into the structures Action and Trigger. I apparently got confused with the structure that stores the user's data.

Before delete it, check if can be useful in a future.

For a complete management, the content of the variables must be able to be established from the WebUI.

Necessary to have a historical record of the statistics.

For less usage and better management of resources.
Current situation: the user data file is readed multiple times by different functions. Maybe this does not consume much resources but is not the best choice.
What I want: only one variable what contains the user data and use this variable on all the functions by using pointers. How to update the data of this variable? Easy, on the loop of the engine.

Before start the server, it's needed check if the files server.key and server.crt exists (theorically are generated on the install script's execution). If the files are found, then start it using TLS.

More detailed docs inside the code.

Right now, the way that PiWorker manages the types of chained results is a bit inconsitent. The package reflect does not fit to much with the needed types to manage the content.

As global solution the best I can do is make a package with the content of all the posible types (like I already do it with uservariables package).

If https are confirmed, http requests must be redirected to https to prevent the user of an error.

For an automatic formatting of the content.

Right now is a mess: a lot of local variables, redundant code everywhere, etc.

Improvements highly needed:

• Sintetize code, the repeated code (like args parsing) must be on one function and used from there on the required places.
• Prevent the usage of variables outside of the definition of each element (like IDs), to keep more ordenated the package.

I think that probably the best solution for creation of new elements is using a python script or something like that, which would prevent typo errors or things of that kind.

Inconsistency between the columns "Args" and "Logs". Both should have the same size, and in the case of logs, must have a scroll.
Can be solved inside the PR #29 but isn't a priority for now.

This can carry some issues on the processing.

When the configs file already exists, the content of it must be readed and placed into the CurrentConfigs variable.
For some reason, when the method ReadFromFile() is executed, the content of the file is readed correctly, but not saved into the CurrentConfigs var. The value of this variable remain null.
As I see, the bug is on the method itself.

Description

Dynamic processing engine. It's the responsible for executing tasks and actions of the most optimal way.

To-do list

• Data reading on every round of loop. Reason: keep working with fresh data. Can be optimized but isn't a priority
• Usage of pointers for lowest usage of memory possible (carefully)
• Execution queue: when a task is on process of execution (triggered) keep it on a queue, out of the rest of active tasks for prevention of multiple execution. Change the state when the task starts the execution and when the execution ends (usage of on-execution state).
• Actions execution on another goroutine
• Chained actions (tasks) (#12)
• Ignore tasks with the state completed, inactive and on-execution

Instead of have the backend inside the ./webui/ directory, it must be inside a new folder called backend. The new directory would be: ./webui/backend/*.
To-do before merge of p.r. #29

The issue is if there are multiple tasks using the same trigger, due to that allways the trigger is using the same variable as reference (previousFileSize), it will be constantly activated. Obviusly, the problem here is these shared variable which has no sense.

How to solve the issue?

I think the best way to do this is saving the last size of the objective file on a file (with the name of the task which is running it), and once the file is created, on every check only read the content of the file with the previous size, if the numbers variate, the trigger is activated and the content of the file updated.

After task execution, the state of that task returns to the original so that never will have a different state because if an action changes the state it will be overwritten at the end.

The received expiration date is not correctly. Appears to be a bug on the server side.

I'm not secure if it happen, needs test.

Triggers with the possible problem:

• Variation of a File's Size
• Every X Time

The mistake here is the continous execution of an action while the condition of the trigger in question continues on the same satate. For example, if a task has as the trigger ByDate the actions will be executed over and over until the day changes.

Instead of them appears an empty string.

Actions's list

TODO

An action can give arguments to the next action.

• Type of the arguments returned: ?
• How to communicate between actions: by using channels

Set the order of the actions (UserAction.Order) according to the order of the list in the WebUI (#29) (when the task is created).

There is no reason for having both. Must be only one trigger where the date and the hour will be chosen directly.
Additionally must have a prevention of past dates selection.

Check if the files generated by PiWorker have the correct permissions.

Bad implementation:

UserData{
   []UserTasks{
      UserTasks{
         UserTask{}
      }
   }
}

This works fine but is very ugly and have no sense.

Not implemented by default (#15) due to conflicts with the way the triggers are executed. It will be implemented in the future but it is not a priority.

Right now PiWorker only stops when it's forced to do it, which is not correct. The best way to do it is handling the signals syscall.SIGINT and syscall.SIGTERM provided by the system to shutdown correctly.

A good project to understand and learn how to manage this is AGHome.

Related with issue #42.

This is a bug on the WebUI.
Actually that field stores the name of the argument instead of the ID.
(In P.R. #69)

Check if can be optimized in general. Maybe can be optimized at the end of actions execution, when the updated state of the task in question is obtained (caused by the fix of #19).

For some reason when the user is selecting args for one action, on the new task dialog, this args are cloned on posterior actions (of the same type).
I think that this problem is because both objects are referencing to the same space on memory.

Triggers's list

• By hour
• By date
• Raspberry's temperature
• Every x time
• Variation of a file's size
• New file on a directory

Packr can be used to compile the VueJS and index.html files and summarize all to only one executable file.

This is needed because the password itself is not stored, instead is stored the hash. So, if the user lost it, there is no way to recover it.
The best way to do this is by using flags.

Must be "PiWorker" instead of "piworker"
File ./processment/data/backupData.go - Lines:

• https://github.com/Pegasus8/PiWorker/blob/75d2e69ce78c0cd250a2f7abfa0f85fd7991a93d/processment/data/backupData.go#L7
• https://github.com/Pegasus8/PiWorker/blob/75d2e69ce78c0cd250a2f7abfa0f85fd7991a93d/processment/data/backupData.go#L8

To-do list

• Design
• Visual development
  • General development
  • Compatibility
    • Add normalize.css
    • Add modernizr.js
    • Bootstrap
• Live statistics
  • WebSocket
  • Web elements update
  • Animations on update
• Login (#3)
• General animations

The PiWorker.service file must be generated and placed (on /etc/systemd/system/) from the executable itself.
Maybe can add a flag like the next one: PiWorker --service install. Another adjacent flags can be:

• PiWorker --service delete
• PiWorker --service start
• PiWorker --service stop

With this we will have the advantage of being able to execute the installation from the installation script itself (after download of resources and dependencies, of course).

Related with P.R. #41.