[Cleanup] Remove Provisioningxxx fall-back commands and other fixes

[tonhuisman]

Features:

• [Cleanup] Remove ProvisionXXX fall-back commands, as all is handled via Provision,<subcommand>
• [Provisioning] Add handling of DevSecurity.dat that was still missing
• [Provisioning] Update documentation
• [Rules] Replace confusing = by : in logging
• [Events] Restore EVENT: xxx in logging for BUILD_NO_DEBUG builds (t.b.d.) From this forum thread
• [Rules] Restore ACT : xxx in logging for BUILD_NO_DEBUG builds.

[chromoxdor]

Logging is back to almost normal. The only thing that got worse is that now Logentry,... also has a duplicate :)
I am not sure if I understood your message in the forum correctly, but what I got is that deduplication is not really possible?

[TD-er]

I did have a look at it with Ton and we came to the conclusion that this isn't something that can be dealt with "quickly".

When rewriting all the log stuff, I also added coloring as you may have noticed.
This also includes some red marking for console entries like what you input and what gets replied.
The "LogEntry" is a special case as it is something you really don't want to miss when debugging rules.
However, the LogEntry also has a log level, which has its own coloring.

So what I did was, I added a LOG_LEVEL_NONE to show the console interactions to be able to color them.
And in order to actually see the logentry stuff, the log is also added as this log level.

In hindsight, this may have been a wrong design choice and it would have been better to set a bit to mark which log entries should be also marked to be easily recognizable.

As you can see, this is a bit more than simply not duplicating the logentry lines as you may want to grab attention.

The struct holding the log entry is now tightly packed to 32 bits. We can take 1 bit of the log line size, which is still more than enough for any log entry. But it should be something to think about it a bit more as maybe this also affects other things we log.

So we're going to fix this, bit for bit :)

[TD-er]

Oh and there are a few other things I have planned for the log.
Right now you only have log levels to 'filter' on, but I want to add some info like whether it is a plugin log, controller log, etc. so you can just set it to debug levels and only see what is interesting while programming.
And maybe later we can also show logs of a task in the task page and controller related info on the controller page, etc.

[chromoxdor]

Oh and there are a few other things I have planned for the log.

When we are at it. :) I always wanted to make a FR but it never came to it, so I do it now here.
I always dreamt about a "filter field" in the web log which filters the entries by the phrase you enter in the field. What do you think?

[TD-er]

Oh and there are a few other things I have planned for the log.

When we are at it. :) I always wanted to make a FR but it never came to it, so I do it now here. I always dreamt about a "filter field" in the web log which filters the entries by the phrase you enter in the field. What do you think?

Well that's something that could be done at browser level.
Thus JavaScript -> Something someone else should do as I can hardly read JS, let alone write it...

[chromoxdor]

Well that's something that could be done at browser level.
Thus JavaScript -> Something someone else should do as I can hardly read JS, let alone write it...

True... could be a task for the one-eyed among the blind :)