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

Directo: directos.request empty for credit invoices #344

Closed
vohmar opened this issue Jan 18, 2017 · 5 comments · Fixed by #1520
Closed

Directo: directos.request empty for credit invoices #344

vohmar opened this issue Jan 18, 2017 · 5 comments · Fixed by #1520
Assignees
Labels
Milestone

Comments

@vohmar
Copy link
Contributor

vohmar commented Jan 18, 2017

registry saves the XML sent to directo in the directos.request column. It has values only for monthly invoices, for credit loading invoices it is empty.

@vohmar vohmar added the bug label Jan 18, 2017
@artur-intech
Copy link
Contributor

Why Directo requests are saved?

@vohmar
Copy link
Contributor Author

vohmar commented May 9, 2017

we also have log everything policy (we log every request coming in or going out from the registry). This is mainly for debugging, problem solving and proving what was sent out from the registry in case there is some doubt.

@artur-intech artur-intech self-assigned this Oct 31, 2017
@artur-intech
Copy link
Contributor

@vohmar FYI: It is actually vice-versa: monthly invoice requests are not saved

@artur-intech
Copy link
Contributor

@vohmar What do you think, if instead of that "directos" and any other possible table we create some single audit log table and collect there everything that is really important for us to log (who did what and when)?

We could store, for example:

  • Who/what initiated the action: user email, name, IP; background job name
  • Time when the event has occured
  • Human-readable description

Communication with third-party services like Directo and Äriregister might also be logged there.

  • some simple UI for all that

Worth noting: I don't suggest this as a replacement for application log (Rails.logger, syslog as a backend on prod). That part remains as is for now. It is more like a high-level audit log. Some kind of activity log.
Whereas application log will continue acting as a kind of exception catcher.
Both "epp_logs" and "repp_logs" are actually about the same: it is kind of audit log (I haven't done deep analysis or those tables, so please correct me if I am wrong).

I don't think creating a new storage (=table) for every new thing that needs to leave some trail is a good idea.

@vohmar
Copy link
Contributor Author

vohmar commented Nov 15, 2017

lets continue with directos for now and come back to this question with "papertrail"/"log and versioning" refactoring. There are two separate types of "logs" - versioning and action logs. These should be handled together if we change anything.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants