Trying to limit field access throuhg workflow

[Guido1982]

I'm trying to limit access to a dropdown through a workflow. I've setup the workflow so that it checks for the status I don't want changed by unauthorized people first. So " if status is 'do not change' " triggers a task. That task then checks against the role of the last user that last modified (so the person that just modified the status) and if the role is not the desired one I set the status back to 'do not change'. But no luck. Is this even possible?

[joebordes]

I understand that you want to block just that field, not the whole record. If that is the case I think this can't be done yet.

We don't have field level conditional editing (yet, we are very close both with mappings and validations) and through the workflows you don't have access to the previous value, just the fact that the value has changed, but you don't know what the previous value was so you can't compare with "don't change".

The easiest way to do this is to add a validation to your module:
http://corebos.org/documentation/doku.ph...validation

[Guido1982]

Yes, even more complicated: I want to block changing that field when it has a certain value, except for certain users.

But I see the validation examples and I like what I see. I'll study these and see if I can make something that fills my needs.

[joebordes]

You will be able to accomplish this with the validation. You have access to all the information on screen and in the database in the validation script, even the user launching the save.

[Guido1982]

Will study this as soon as I have a chance, because I think I can meet a lot of earlier demands this way, before I knew this was possible.

---

So basically, I could setup a field validation that checks the current_user (if he / she belongs to a certain group or profile), then check the value of the 'status' field and alert something like "you are nor permitted to change the status to this value" for anyone who is not in the correct group / profile?

---

Hmm, I now have a file called "SalesOrderValidation.php" that looks like this:

PHP Code:

<?php

global $log,$currentModule,$adb,$current_user;

$screen_values = json_decode($_REQUEST['structure'],true);

$q = "SELECT vtiger_groups.groupname FROM vtiger_groups INNER JOIN vtiger_users2group ON vtiger_groups.groupid = vtiger_users2group.groupid WHERE vtiger_users2group.userid = ?";
$p = array($current_user->id);
$r = $adb->pquery($q, $p);

$groups = array();

while ($groupname = $adb->fetch_array($r)) {
    $groups[] = $groupname;
}

$q = "SELECT sostatus FROM vtiger_salesorder WHERE salesorderid = ?";
$p = array(vtlib_purify($screen_values['record']));
$r = $adb->pquery($q, $p);
$current_status = $adb->query_result($r, 0, 'sostatus');

if (!in_array('Administratie', $groups) && $current_status == 'Wacht op betaling') {
    echo 'You are not allowed to change the status from \'Wacht op betaling\'';
    die();
}

echo '%%%OK%%%'; 


With dummy value and through the Ajax action I can test, and it works.. But not in the actual application. I am able to save the record, even though the current value is "Wacht op betaling" and I'm not in the group.

[joebordes]

Check the ajax calls in the javascript console, make sure the validation script is being called and look at the returned result

[Guido1982]

Will do and report back

[Guido1982]

Every change triggers a call to "index.php?module=Utilities&action=UtilitiesAjax&file=ExecuteFunctions&functiontocall=ValidationExists&valmodule=SalesOrder". But no actual result. No message in the console aswell.. Don't know what's going on. Filename is "SalesOrderValidation.php", code is as in previous post, but no dice...

EDIT
Interesting fact. Clicking the link in the console just returns the word "no". Did the same in Accounts, that returned "yes".

[Guido1982]

My validation suddenly started to work! I think it was a caching issue. That has tripped me before...

---

One catch: When you try to change the status my custom validation does not allow certain groups to change, and then cancel (because you were not allowed to), you're not able to change any other field. If you start out by editing a field (let's say an address) you're fine. But once you've tried to change a non-allowed field the screen value changes and stays like that, so after that you'd have to reload the page to be able to change the address again. Here's the code:

PHP Code:

<?php

global $log,$currentModule,$adb,$current_user;

$screen_values = json_decode($_REQUEST['structure'],true);

$q = "SELECT vtiger_groups.groupname FROM vtiger_groups INNER JOIN vtiger_users2group ON vtiger_groups.groupid = vtiger_users2group.groupid WHERE vtiger_users2group.userid = ?";
$p = array($current_user->id);
$r = $adb->pquery($q, $p);

$groups = array();

while ($groupname = $adb->fetch_array($r)) {
 $groups[] = $groupname['groupname'];
}

$q = "SELECT sostatus FROM vtiger_salesorder WHERE salesorderid = ?";
$p = array(vtlib_purify($screen_values['record']));
$r = $adb->pquery($q, $p);
$current_status = $adb->query_result($r, 0, 'sostatus');

if (!in_array('Debitoradministration', $groups) && $current_status == 'Waiting for payment' && $screen_values['sostatus'] != 'Waiting for payment') {
 echo 'You are not allowed to change the status from \'Waiting for payment\'';
 die();
}

echo '%%%OK%%%'; 


Field value and groupname are translated into english for clarity. I also checked this by using the JS console:

Code:

document.getElementById("txtbox_sostatus").value;

 Returns "Approved" (in this case, because I tried changing the order status to that). If the value in JS memory would be set to the actual screenvalue (so what you see) when a user clicks 'cancel' this behaviour would not happen.

[joebordes]

We don't have the previous value when the validation is launched. I mean, the user changes the value in the input or select, then the value is sent for validation and we can check the previous value in the database, but in the browser the value has been lost. When the error message arrives the validation won't let you save but it can't change the value back because it just isn't there.
Obviously we could program a different behaviour but we would have to save all the previous values somewhere.... at least.

Am I understanding you correctly?