Hello,
I've got the following problem:
For a system I would like to have custom routing to another form-set.
I have a Sharepoint List where I store the name of the employee which is called "name". The list is filtered by "Created by" - therefore every user can only see his own entries.
BUT: We have some central-non personalized AD-accounts for some specific PCs and I now want to prevent the users to edit items of other users on a list, when they use a central account.
For example: CentralAccount has two entries in the list where at one time the Row "Name" is filled with "Name A" and one row is filled with "Name B".
That means:
If the PreferredName of the User is not the same as the content of the sharepoint row "Name", then formset xy should be loaded. If it is both the same, then the default edit-Formset should be loaded.
Is that possible? If not, I would also be okay with having a warning and hiding some grids when the above mentioned requirement isn't met to prevent the users from editing specific items - would that be possible?
Many thanks in advance.
Hello @JonHebbe,
How are you getting the preferred name of the user if they are logged in using central-non personalized AD-accounts?
As far as I know, the account name will be the same using the same AD account.
Short example for better understanding:
We have a Sharepoint List with a name field which is a text field - no person field.
The list view is getting filtered by the created by field.
Person A: is logged in on his personal account and is called John Doe - he puts in an entry to the list where he puts "John Doe" into the name field. Created by is "John Doe".
Person B: is logged in on a central account "CentralAcc" and is called James Butler - he puts in an entry to the list where he puts "James Butler" into the name field. But created by is "CentralAcc".
Person C: is in the next shift after Person B and logged in on the central account "CentralAcc" and is called Anna Doe - she puts in an entry to the list where she puts "Anna Doe" into the name field. But created by is "CentralAcc".
Person A can only see the entry of John Doe because it's filtered by created by. He should be able to edit the entry with all the fields I specificy within plumsail editForm.
(PreferredName = John Doe and Sharepoint List Name field = John Doe-> PreferredName = Sharepoint List Name Field)
Person B and C can now see the entries of James Butler and Anna Doe because it's filtered by created by and they are using the central account (PreferredName = CentralAcc but Sharepoint List Name field = James Butler -> PreferredName =/= Sharepoint List Name Field)
But: they shouldn't be able to see specific fields in the plumsail editForm.
I hope it's relatable what i mean 
Hello @JonHebbe,
That is clear, thank you!
But how do you identify who is on the shift and using the account now?
Hey @mnikitina,
I can't identify who is working on the central account - that's the problem and that's why I want to lock central accounts globally from editing items in that specific list.
I can't do that manually with Sharepoint permissions as it would be way too much management overhead for that specific use case.
That's why my idea was to identify if the preferred name of the account is identical to the name which is in the text field of the sharepoint list, and if not, hide specific grids or buttons within plumsail forms.
If that's not possible I may have to consider another way of doing that.
Short example:
Preferred name would be "Administrator" but Name in list would be "John Doe" -> hide specific grid in Plumsail.
Hello @JonHebbe,
The only option that came to my mind is to set up routing for this specific accounts.
For instance, route users to a a form with a single line text field and ask them to enter their name. If the name doesn't match to Sharepoint List Name Field show the warning, otherwise redirect to the edit form.
But you must be sure that users are honest and will input the real names.
I figured it out now.
Basically what i did is the following: when saving an item to said list, I also save the name of the user as text. I created another row which is called "preferredName".
In Plumsail JS for that specific EditForm I do the following:
function updateCurrentUserInfo() {
pnp.sp.profiles.myProperties.get().then(function(result) {
var props = result.UserProfileProperties;
console.log(props);
for (var i = 0; i < props.length; i++) {
switch (props[i].Key) {
case 'PreferredName':
console.log(props[i].Value);
fd.field('PreferredName').value = props[i].Value;
break;
}
}
});
}
fd.spRendered(function(){
$('.warning').hide();
updateCurrentUserInfo();
});
Then I have an OnClick action on the save button, which checks if the preferredName from the User properties matches to the saved name of the list. If that's true, a value is set and the form is saved. Else, the user will get a grid shown which is called "warning" and the form is not saved because it can't be assured that the user which created the entry is sitting in front of the computer.
if(fd.field('PreferredName').value == fd.field('Name').value){
console.log("Namen stimmen überein");
if (confirm('Bist du sicher, dass du diesen Antrag stornieren möchtest?')) {
fd.field('Stornieren').value = true;
return fd.save();
}
}
else{
console.log("Namen stimmen nicht überein");
$('.warning').show();
}
That's doing exactly what I wanted - but thanks for your help and input!
1 Like