I am running the latest version of Joomla and I just got the latest version of fabrik from the git repository.
The problem I am having is the order of events that happens with the new ACL and list plugins when saving a record.
I have a pretty complex form with an established workflow that worked until I updated to 3.5.2 and installed the latest git repository. My workflow is as follows;
I am using the canEditRow list plugin to evaluate the workflow of this process to set if the report is editable and by who.
I put the code in a debugger and found the problem. It seems that the new ACL check runs the list plugins on form submission. I use the canEditRow plugin not to check ACL on submission but for the list view editable setting for each record. When the plugin runs the "Sorry, but you are not authorised to edit this record" error is thrown because the check on the "yes/no" element fields are now true since the supervisor set it to be so before form submission. I.e. reports_dar___shift_completed_raw = 1 and reports_dar___report_finalized_raw now equals 1 where as before form submission it was set to 0 which allowed the supervisor edit access to the report in my check "return ($reportFinalized != 1) && ($shiftCompleted == 1);".
I am not sure where to go from here since this workflow permeates about 30 different reports and we need this level of security on the reports.
The problem I am having is the order of events that happens with the new ACL and list plugins when saving a record.
I have a pretty complex form with an established workflow that worked until I updated to 3.5.2 and installed the latest git repository. My workflow is as follows;
- An employee creates a reports. Employees can only edit their own reports until they submit them for approval. On that report is a yes/no element that specifies that their shift is completed. Once they select "Yes" they are no longer allowed to edit their own reports.
- The report is sent up the chain of command to someone in the custom Joomla Supervisor ACL group for review and editing. Supervisors can only edit employee reports "after" the employee marks the report as "Submitted = yes".
- Once the supervisor reviews and edits the employee's report they set the "Report Finalized" yes/no element to "Yes"
- Once the report is submitted and finalized it is no longer editable by anyone.
I am using the canEditRow list plugin to evaluate the workflow of this process to set if the report is editable and by who.
PHP:
$user = JFactory::getUser();
$groups = 19;
$reportFinalized = '{reports_dar___report_finalized_raw}';
$shiftCompleted = '{reports_dar___shift_completed_raw}';
if(is_array($reportFinalized)) {
$reportFinalized = $reportFinalized[0];
}
if(is_array($shiftCompleted)) {
$shiftCompleted = $shiftCompleted[0];
}
// Temp check for new ACL bug
print($reportFinalized.' = '.$shiftCompleted);
if(in_array($groups, $user->getAuthorisedGroups())) {
if ($user->id == '{reports_dar___employee_id_raw}') {
return ($reportFinalized != 1) || ($shiftCompleted != 1);
}
else {
return ($reportFinalized != 1) && ($shiftCompleted == 1);
}
}
else {
return $shiftCompleted != 1;
}
I put the code in a debugger and found the problem. It seems that the new ACL check runs the list plugins on form submission. I use the canEditRow plugin not to check ACL on submission but for the list view editable setting for each record. When the plugin runs the "Sorry, but you are not authorised to edit this record" error is thrown because the check on the "yes/no" element fields are now true since the supervisor set it to be so before form submission. I.e. reports_dar___shift_completed_raw = 1 and reports_dar___report_finalized_raw now equals 1 where as before form submission it was set to 0 which allowed the supervisor edit access to the report in my check "return ($reportFinalized != 1) && ($shiftCompleted == 1);".
I am not sure where to go from here since this workflow permeates about 30 different reports and we need this level of security on the reports.
Last edited: