Similar to pull request #1121 and issue #749, the ID needs to be in group_by to solve this error in /admin/logs/search
>Error: [PDOException] SQLSTATE[42000]: Syntax error or access violation: 1055 Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'Log.id' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by
- index now shows the model that the log entry concerns
- added model to the search parameters
- this allows for searches such as new users added (Model:User - action:add)
- fixed a bug with the log search where going back to the first page of results would return you to the search form
Merge and upgrade of several new features
Conflicts:
VERSION.json
app/Controller/ShadowAttributesController.php
app/Controller/TagsController.php
app/Model/AppModel.php
app/Model/Event.php
app/Plugin/SysLogLogable/Model/Behavior/SysLogLogableBehavior.php
- Added logging of failed login attempts
- Added (optional) logging of successful authentications
- admin setting that has to be enabled
- will log all API calls (both HTTP method and target url)
- optional logging of user IP address for all logs
- each log entry created while this setting is enabled will log the IP address of the client
- disabling it also hides the IPs from the interface
- added new IP field for the log search (only if enabled)
- The log search incorrectly set the search terms for empty fields, meaning that any log entries that had unfilled columns, such as it is the case with admin_email would never return results
- the event changes that a proposal creation creates are also logged (such as disarming the proposal email lock) -> this should not be shown in this log view.
- contributors shown on the event view (list of the organisation logos of users that have contributed through proposals)
- these link to the event history containing only entries from their organisation
- changes to the activity heatmap
- heatmap now dynamically changes the range on the graph based on the obtained values
- performance improved
- buttons to move back or forward in time on the calendar
- Attributes:
- warning for the user if he/she has selected the attribute category "targeting-data" or "attribution" as these could contain classified information
- UI improvements across most attribute and shadowattribute input views
- Updated cal-heatmap to the newest version
- View Event history now shows the logo of the org whose action triggered the log entry
- View Event History now shows different fields than before
- Proposals now logged
- Accepting / Discarding a proposal now doesn't create junk edit / delete entries as before.
- Creators of an event can now see all of the log entries altering an event in the event history log. This includes deleted events.
- ADMIN org removed.
- Siteadmins are now identified by the perm_site_admin flag
- Siteadmins can now be of any organisation
- editing the regexp / whitelist rules can now be done by a special user with the perm_regexp_access in his/her role
- Executing a mass replace of attribute values based on the regexp rules cannot be initiated by a regexp/whitelist user, only by a site admin
- If the login page is reached without any users / roles defined they are automatically created (perviously it was only the user that was created)
- Org admins are restricted from assigning perm_site_admin, perm_sync and perm_regexp_access roles to users. This can only be done by a site admin.
- until now checkAction was used to check permissions of a user
- but since all of the role permissions are checked beforefilter in
appcontroller and saved into a public array, doing a lookup of the
array saves an SQL call for each permission check.
- uses the logs to generate a list of actions affecting the selected
event and all of its attributes
- view is very minimalistic, not to show anything restricted
- Orgs can propose new attributes or changes to existing attributes for
events that they do not own
- publishing users of the owner organisation can see, accept or discard
them
- Reworked the access control
- minor fixes
- Admins cannot manually change anyone's authkey, they need to generate a
new one via the reset link
- Some pages could be accessed by changing the url - fixed (though needs
further testing)
- Edited a change in the manual that may have been confusing
- Some changes to the way ACL is set up - still needs more work
After added feedback on entered search terms for search attributes
and search logs, this now also works for LogsController::index()
and next and previous page.
Signed-off-by: Noud de Brouwer <noud4@home.nl>
-Analaysis levels setable for events as per milestone item 94
-Password change forced as per milestone item 109
-Added feedback on entered search terms for search attributes
-fixed the authentication issue
-some minor fixes