taskGNU remotecontrol - Tasks: task #13423, transactionhistory.php - DIFF

 
 

You are not allowed to post comments on this tracker with your current authentication level.

task #13423: transactionhistory.php - DIFF

Submitter:  Stephen H. Dawson DSL <shdawson>
Submitted:  Sun 14 Dec 2014 09:21:49 PM UTC
   
 
Should Start On:  Sun 14 Dec 2014 05:00:00 AM UTC Should be Finished on:  Wed 20 May 2015 12:00:00 AM UTC
Category:  User Interface Priority:  5 - Normal
Item Group:  Operation Status:  Done
Privacy:  Public Assigned to:  shdawson
Open/Closed:  Closed Fixed Release:  2.0
Percent Complete:  100% Planned Release:  2.0

Jump to the original submission

Sat 23 Apr 2016 04:21:30 PM UTC, comment #13: 

This task is only for housekeeping.

I bear witness and certify I have personally tested these changes made to GNU remotecontrol. I affirm the changes made to the code:
-achieve the functionality of the stated requirements;
-succeed during operation; and
-cause no anxiety.

I approve this code.


Thank you to everyone for working on this modification.


Respectfully,
SHD//
Stephen H. Dawson

Stephen H. Dawson DSL <shdawson>
Group administrator
Sun 10 May 2015 01:10:39 PM UTC, comment #12: 

Thank you for the PDF. This is an excellent explanation of the work.

-SHD

Stephen H. Dawson DSL <shdawson>
Group administrator
Sun 10 May 2015 04:23:35 AM UTC, comment #11: 

Presentation and description of transactionhistory.php (the name of the web page logs.php within the document is only a hypothetical situation).

[The previous post failed to send the document]

Thank you,
Vinícius Madureira.

(file #33970)

Vinícius Madureira <whitenightmare>
Group Member
Sun 10 May 2015 04:19:54 AM UTC, comment #10: 

Presentation and description of transactionhistory.php (the name of the web page logs.php within the document is only a hypothetical situation).

Vinícius Madureira <whitenightmare>
Group Member
Fri 08 May 2015 01:19:45 PM UTC, comment #9: 

A thought.

Think about doing a simple and advanced transactionhistory page layout. Same physical page, but toggling between the two display modes.

That may get us to effectively combining the field separation we have now with the field aggregation you are going for.


Kindly,
SHD

Stephen H. Dawson DSL <shdawson>
Group administrator
Fri 08 May 2015 12:18:56 PM UTC, comment #8: 

Thank you. Looking good.

Please post:

show tables;

-and-

describe transactionlog;


Probably to a TXT file would be easier. There is an option at the bottom to attach a file.

The icon at the top...Erros should be Errors.

If you can, please line the 3 icons up horizontally. (Or, at least they are not in my browser.)

I am concerned too much is put into the description field. As long as it is separate in the table, that is good. Then, we look at the the filtering to see how that works.

Also, I recommend clicking one of the 3 icons at the top will filter by that icon. That would be nice and fast for user interaction.


Thanks,
SHD

Stephen H. Dawson DSL <shdawson>
Group administrator
Fri 08 May 2015 07:18:34 AM UTC, comment #7: 

Team,

The working model is hosted in URL:
http://gnurc.viniciusmadureira.com

I didn't put the filters for each column yet, because I wished you test it before. Also the table is not working with AJAX (though I already have done the code  in PHP and jQuery) because I'll need a stored procedure (or something like) that captures data from all the log tables (who can help me please leave a message).

Thank you!!!

Vinicius Madureira

Vinícius Madureira <whitenightmare>
Group Member
Wed 06 May 2015 09:59:31 PM UTC, comment #6: 

Team,


I have merged previous email comments from John (below) into this posting, and will add my comments. Let's work here in the task going forward, versus working in emailing. It seems much more efficient, if everyone is willing to do so.

http://svn.savannah.gnu.org/viewvc/branches/development/wnm/prototype.png?root=remotecontrol&sortby=date&view=markup
This is looking great.

http://commons.wikimedia.org/wiki/File:GNU_remotecontrol_-_Transaction_History.png
I asked Vinicius to add filtering to each field, as we have now.

http://www.gnu.org/software/remotecontrol/manual/remotecontrol.html#transactionhistory_002ephp
This page is nothing more than a read of the activity that successfully completed with GNU remotecontrol. It is a reality check of success. We are now talking about adding more functionality. The intent of this php page is for the non-technical person to see what successfully happened with GNU remotecontrol. The management of the physical data in the schema tables is best suited for a database administrator, to chop up and store in other tables, by date range or device ID or whatever they see is best. This reduced record count will help keep transactionhistory.php loading faster.

From there, we can further help by adding other filtering options. Perhaps loading by date range, or even loading by limiting records to a particular record count. Also, perhaps flagging records the user does not want to see anymore. Not sure, but something that will keep the database from juggling too many records, causing the php page to take forever to load.

From there, it seems like we need more user feedback to know what they prefer for features and functionality.


***********************************************************************
Previous emailing from John ...

https://www.progclub.org/wiki/GNUrc#v2_exception_log_table
I've rewritten the default exception handler (the code that processes unhandled exceptions, i.e. "errors"). It uses a new table, v2_exception_log.



http://svn.savannah.gnu.org/viewvc/branches/development/jj5-mvc/src/1-lib/98-handlers.php?root=remotecontrol&view=markup
The error handling code recursively logs all exceptions in the chain.

http://svn.savannah.gnu.org/viewvc/branches/development/dbscripts/gnurc-schema.sql?annotate=237&root=remotecontrol#l167
So the old error log is phased out and no longer used. The old schema is here.

http://svn.savannah.gnu.org/viewvc/branches/development/dbscripts/gnurc-schema.sql?annotate=237&root=remotecontrol#l30
The new schema is here.

https://www.gnurc.com/dev/jj5-mvc/admin-list-exception.php
Error reporting is now provided here (not part of transactionhistory.php).



An "exception details" report is not done, yet.
***********************************************************************

I am of the belief the more thermostats a user has in their list on index.php, the less likely they will use GNU remotecontrol. The larger the count of thermostats seems more likely to use unattended sever side automation to hit the database and files which comprise GNU remotecontrol, which will be further facilitated by Model-View-Controller.

The last thing I believe anyone wants is to have GNU remotecontrol blamed by a finance officer, for not being able to access data they spent time and money to capture of what successfully happened with GNU remotecontrol. This scenario can easily occur with a GNU remotecontrol user who clicks a button or hyperlink to delete records and claims ignorance of understanding. If we leave physical record management with the database administrator, that responsibility is completely encapsulated in their role as DBA. This also puts the ODBC and big data aspects on the DBA, to facilitate other applications having access now to the data itself.

Therefore, I must believe we are only talking about filtering what to show in transactionhistory.php.

https://www.gnurc.com/dev/jj5-mvc/admin-list-exception.php?lang=en-US
This looks good. However, I am not sure if it is well suited to be a part of transactionhistory.php. Play with some ideas and see where they lead.


RECOMMENDATIONS:
-Please play with some ideas of buttons or hyperlinks to filter record search and let's see what you come up with. This could result in user settings of what they want to see when the load transactionhistory.php, so think about where to store that user data. Server side is my preference, so wherever the log in at ... we give what they want to see each time. Sharing you ideas via a screen snip is better than nothing. It is certainly not necessary to get a working page to show an idea. Least cost to illustrate an idea, in time and effort, is good.

-A theme sounds good. Let's target this for version 2.1, not for version 2.0.

-Exporting from withing this page, well...does not sound good to me. Let's leave this as a database administrator effort, with the ability for a business analyst to hit the tables with something like ODBC into a spreadsheet or big data rolls with loads of analysis.


Good? Please post comments, for team input and productivity.


Kindly,
Stephen

Stephen H. Dawson DSL <shdawson>
Group administrator
Wed 06 May 2015 09:48:10 PM UTC, comment #5: 

About log theme it's quiet to do, but I'll need a specification of how to do it (anyway, I'll make and put it in Savannah folder and the group gives up is OK).

About saving I mean export (in a SQL format, for example). Apologize for the inappropriate expression.

Vinícius Madureira <whitenightmare>
Group Member
Wed 06 May 2015 03:05:57 AM UTC, comment #4: 

I am ok with the color visualization of logs, however, we would need to a configuration page or setup page for users to define the color - log theme.

For the save/remove button, there is no need because the data have been always saved. To avoid to much message over time, we can arrange the reocord by some other buttons, like logs within today, logs within a week, logs within a month, etc.

Wensheng XIE <wxie>
Group Member
Tue 05 May 2015 02:37:43 AM UTC, comment #3: 

I'm finalizing the table code that loads the fields of transaction history, however there are issues that I wonder if there is the approval of the group.

Rather than making a log table for each type: "Error", "Transaction" and "Exception", we could use a screen only for such logs, where each type of log message is represented by a color (e.g. error - Red; transaction - blue; exception - yellow) and the table can be filtered by means of a button. In addition, we could merge the fields of each type mentioned above and make a table with only three fields:

Type (the type of message);
Description (where the data is merged);
Time (the timestamp of the message!);

Thus, it followed the pattern of logs of most systems, where there is a description of the event and your date, simplifying data visualization for users (such log system would look like the front-end browsers consoles or messages captured by IDE's where a code is compiled - with exception to the date).

So simplify both access to logs as access to information from the logs.

Finally, maybe we could put a button to save/remove the message (or a certain type of message log), because it can get quite large over time - this option would be used only by an administrator user, which could also delete such messages to decrease the volume from the database.

I await feedback friends!!!

Vinícius Madureira <whitenightmare>
Group Member
Mon 20 Apr 2015 03:48:42 PM UTC, comment #2: 

It may be better to go with only displaying records where OLD does not equal NEW. This will require displaying record count above the table, so the user knows if there are zero records found. Further, this could be setup for using a button or hyperlink to set the preference when loading transactionhistory.php, so the user is not burdened to click this option every time.

Think about it.

Thank You,
-SHD

Stephen H. Dawson DSL <shdawson>
Group administrator
Sun 19 Apr 2015 08:07:32 PM UTC, comment #1: 

Vinícius,


Sending to your, for your review and commentary.


Thank You,
SHD

Stephen H. Dawson DSL <shdawson>
Group administrator
Sun 14 Dec 2014 09:21:49 PM UTC, original submission:  

Adding functionally to the display of the data in the table.


FUNCTIONALLY 1:
IF Old Value field does not equal New Value field,
THEN a different display color of the New Value field.


FUNCTIONALLY 2:
A hyperlink, somewhere above the Old Value and New Value fields, to only display rows where Old Value field does not equal New Value field. Need to also be able to return row display to display all rows. Probably a toggle between these two modes of the hyperlink.

DIFF

ALL

...or, something like this. Alternatively, use the existing Clear Search hyperlink.

The existing search fields, in each column, need to continue working if the DIFF link is clicked. This would provide further filtering, on the rows where Old Value field does not equal New Value field.

There is value in having a URL of only showing DIFF. This is similar to a hyperlink on index.php having the sort value, once sorting preference is set. The benefit is having the user not being required to go to transactionhistory.php, then click the DIFF hyperlink, but having a direct URL for reviewing differences between Old Value and New Value fields on the transactionhistory.php page.

Stephen H. Dawson DSL <shdawson>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #33970:  showTables.pdf added by whitenightmare (1000KiB - application/pdf)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by wxie (Posted a comment)
  • -email is unavailable- added by whitenightmare (Posted a comment)
  • -email is unavailable- added by shdawson (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-04-23 shdawson StatusIn Progress Done
        Assigned towhitenightmare shdawson
        Open/ClosedOpen Closed
        Fixed ReleaseNone 2.0
        Percent Complete10% 100%
    2015-05-10 whitenightmare Attached File- Added showTables.pdf, #33970
    2015-05-05 whitenightmare Should be Finished on2015-03-14 2015-05-20
    2015-04-20 shdawson StatusAssign Resource In Progress
    2015-04-19 shdawson Assigned toNone whitenightmare
    2014-12-14 shdawson Should be Finished on2014-12-14 2015-03-14

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code