Map errors to error codes and hyper link to relivent doc

[bmfmancini]

Hey Guys

Just a thought how about assigning errors to error codes i.e poller exceed error code 123 with a hyperlink to the github/cacti doc for the relevant issue?

just map out the codes then a folder in the doc repo for codes then the respective docs could match up with the error code if it exists great if not then someone can create it

[netniV]

I do not believe that is a bad idea.

[bmfmancini]

I am by no means a good php dev but if I came up with the error codes and made a pull request for a folder in the doc repo and started with the docs would that help?

On Wed., Feb. 5, 2020, 4:55 p.m. Mark Brugnoli-Vinten, < [email protected]> wrote:

I do not believe that is a bad idea.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/cacti/issues/3238?email_source=notifications&email_token=ADGEXTG6B23MZXUBGWGO73DRBMYUPA5CNFSM4KQQ3KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5ECGY#issuecomment-582631707, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTD44SUTLWLMKWIXH6TRBMYUPANCNFSM4KQQ3KYQ .

[netniV]

We would need to look at how we want the error codes to be coded. Especially as there is a mixture of errors that may go from core to plugins

[bmfmancini]

True

Need some planning on this

On Wed., Feb. 5, 2020, 6:16 p.m. Mark Brugnoli-Vinten, < [email protected]> wrote:

We would need to look at how we want the error codes to be coded. Especially as there is a mixture of errors that may go from core to plugins

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/cacti/issues/3238?email_source=notifications&email_token=ADGEXTEDTPX5EY53S2IHXFDRBNCDJA5CNFSM4KQQ3KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5KXJA#issuecomment-582658980, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTDSK654RW4H3FTJ6C3RBNCDJANCNFSM4KQQ3KYQ .

[cigamit]

Yea, we have currently at least five methods of generating GUI errors:

1. raise_message(number);
2. raise_message('hash', 'message', message_level);
3. display_custom_error_message() and auth_display_custom_error_message()
4. Some freaky session variables that are set by the plugins injecting into the global message array on next page load (real old stuff)
5. Total random cacti_log() just about everywhere.

@netniV did a fantastic job at enabling 2., which has allowed us to get lazy with having a global message array, that could be augmented with links.

So, the easy way would be to simply:

1. extend the message array to include a 'url' index, and that URL could provide the user a link to follow. Good start.
2. The raise_message() function call could add a 4th parameter to do the same
3. We would have to migrate the plugins to use the simple raise_message() function call instead of what they are doing today.
4. But the Cacti log. That seems too much work. But I could be wrong.

Anyway scraping that data together for a first pass would not be too difficult.

[cigamit]

Note in recommendation 1) we would have to allow that link to be relative based upon some setting, like point to GitHub (default), or your local replica via setting for people in dark locations.

[bmfmancini]

Maybe then the error docs are included in the core repo as well?

I don't Think it would add to much to the size of the repo

On Wed., Feb. 5, 2020, 7:56 p.m. Jimmy Conner, [email protected] wrote:

Note in recommendation 1) we would have to allow that link to be relative based upon some setting, like point to GitHub (default), or your local replica via setting for people in dark locations.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Cacti/cacti/issues/3238?email_source=notifications&email_token=ADGEXTHVND22ZW2XOQWWRLLRBNN2TA5CNFSM4KQQ3KY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEK5RDHQ#issuecomment-582685086, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADGEXTDG33ZVYBY5G7DI76LRBNN2TANCNFSM4KQQ3KYQ .

[cigamit]

Currently, if you go into the file include/global_arrays.php, there is a message array. I would propose augmenting that array as a first step. Noting the some of the messages are pretty generic like 'Good boy, the save worked'.

Here are a few examples of how that might change. This is just a light proposal right now:

$messages  = array(
    1 => array(
        'message' => __('Save Successful.'),
        'level' => MESSAGE_LEVEL_INFO
    ),
    ...
);

That's the current structure, we could do as little as:

$messages  = array(
    1 => array(
        'message' => __('Save Successful.'),
        'level' => MESSAGE_LEVEL_INFO
        'url' => some_url_to_doco.html
    ),
    ...
);

It would also be nice to put all these messages in a database table and have the plugins register there error messages through a hook.

Both the $message array and the $nav array cause a lot of code bloat. It would be nice to ditch them both.

[netniV]

Currently, if you go into the file include/global_arrays.php, there is a message array. I would propose augmenting that array as a first step. Noting the some of the messages are pretty generic like 'Good boy, the save worked'.

Here are a few examples of how that might change. This is just a light proposal right now:

$messages  = array(
    1 => array(
        'message' => __('Save Successful.'),
        'level' => MESSAGE_LEVEL_INFO
    ),
    ...
);

That's the current structure, we could do as little as:

$messages  = array(
    1 => array(
        'message' => __('Save Successful.'),
        'level' => MESSAGE_LEVEL_INFO
        'url' => some_url_to_doco.html
    ),
    ...
);

That is what I envisaged, though also maybe adding CE-1024 (cacti error) or CI/CW/CD for info, warning, debug.

cigamit wrote: It would also be nice to put all these messages in a database table and have the plugins register there error messages through a hook.

Both the $message array and the $nav array cause a lot of code bloat. It would be nice to ditch them both.

I think that should be created as a 1.3 enhancement and is a pretty good idea. The only issue I can see with moving it to the DB, is we would lose the translations of the messages, so we need a way to also include those with the translation software.

Sean Mancini wrote: Maybe then the error docs are included in the core repo as well?

As they are part of the documentation repo, they would be automatically included with the packaging system anyway as it's converted into HTML. If people are using github as a source, they would need to have an MD parser for the documentation (which I have a server acting that way) so that would be linked directly to the docs repo.

[bmfmancini]

Ok great!

I am excited to help out on this one ! Please let me know the error code mapping I will start making the docs

[bmfmancini]

Hey Guys

Since I have much more free time on my hands I would like to pick this back up

I can do the documentation side of things just need someone to do the code side of it we would also need a consensus on error codes.

BTW I hope everyone is healthy in safe in these crazy times

[TheWitness]

There was enough discussion on this one to move it up in priority. After 1.2.23.