Loading...
 
Features / Usability

Features / Usability


User Reports not inserting proper User

posts: 42

We have a cron job set up to send out user reports for all pages/structures/file uploads.

When a page is edited the proper user who edited the page is entered into the report. However, when a page is removed or added into a structure, if an admin created the structure, that admin is reported as having done the adding/removing. This is incorrect.

How can this be changed or altered in the preferences or filesystem so that the user who actually does the adding/removing/editing is in the report, instead of the admin?

An example of an email report is attached. Duta8181 is the admin user and all others are regular users.

posts: 42

Update:

Inside the file
~/lib/core/Reports/Send/EmailBuilder/WikiPageChanged.php
the output table is populated properly using the code:

$output = tr(
"%0 edited the wikipage %1 (this history, all history)",
"{$change'data''editUser'}",
"{$change'data''pageName'}",
"\"{$base_url}tiki-pagehistory.php?page={$change'data''pageName'}&diff_style=sidediff&compare=Compare&newver=$newVersion&oldver={$change'data''oldVer'}\"",
"\"{$base_url}tiki-pagehistory.php?page={$change'data''pageName'}&diff_style=sidediff&compare=Compare&newver=0&oldver={$change'data''oldVer'}\""
);

BUT inside the other email building files such as
~/lib/core/Reports/Send/EmailBuilder/StructureAdd.php
the out put table looks like:

$output = tr(
"%0 added %1 wiki page to a structure",
"{$change'user'}", //added editUser
"{$change'data''name'}"
);

and is not populating the table with the proper user inside the '%0' variable. What is the difference here?

posts: 42

I've noticed that the reports tend to get hung up inside the tiki_user_reports_cache sometimes as well. I checked the database using phpMyAdmin, and the cache just gets filled with changes or updates that it wants to send out in reports but can't for some reason and just halts the reporting completely. The only way I've found to get reports to start sending again is to clear the whole cache. The reports will start sending again for a couple days and then just stop, and begin filling up the cache.

Anyone know what could be causing the reports to get hung up like this?


posts: 42
Has anyone else had any trouble with the reports feature for watches? Or with the cron job not triggering at the proper regular intervals? I'm not sure if this is an issue with the timestamp in the database, or with the code itself. Any help is appreciated.

Upcoming Events

1)  18 Apr 2024 14:00 GMT-0000
Tiki Roundtable Meeting
2)  16 May 2024 14:00 GMT-0000
Tiki Roundtable Meeting
3)  20 Jun 2024 14:00 GMT-0000
Tiki Roundtable Meeting
4)  18 Jul 2024 14:00 GMT-0000
Tiki Roundtable Meeting
5)  15 Aug 2024 14:00 GMT-0000
Tiki Roundtable Meeting
6)  19 Sep 2024 14:00 GMT-0000
Tiki Roundtable Meeting
7) 
Tiki birthday
8)  17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting
9)  21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting
10)  19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting