This project has moved. For the latest updates, please go here.

Task list becomes invisible for users with lower permission levels

Feb 4, 2015 at 5:41 PM
Hello

I found this solution and I thinks its great but i have a serious issue after activating the solution. The task lists for users with lower permission levels (ex. Edit) becomes invisible. I have full control permission and for me everything is visible but for other users the solutions breaks the task list. I also noticed when editing personal views, the list also becomes invisible.

Thanks and kind regards
Coordinator
Feb 4, 2015 at 8:59 PM
Edited Feb 5, 2015 at 12:11 AM
That does not seem good! My first question is, did you implement the master page changes that were suggested in the blog post 'Why is My Form So Jumpy?' I'm kind of hoping that the answer is yes, becuase that would potentially explain a lot. Second, are you on 2010. That will potentially explain a lot too.

Basically, my first guess is that your contributors do not have access to the JavaScript files in the Style Library/SPEasyFormsAssets directory that make the whole thing work for whatever reason. If you implemented the master page changes then they hide the form. The JavaScript files show the form, but not if they can't be read by the current user. If you're on SP 2010, the Style Library defaults to enforce checkout, so module files are laid down checked out, and contributors won't be able to see them until they're checked in. If this is the case, then the easiest fix is to delete the whole Style Library/SPEasyFormsAssets folder, turn off force checkout on the Syle Library, and then reinstall the solution. The files should now come in checked in. I've only seen this particular problem on SP 2010. You could just manually check in the files too, but there are a lot of them so this would be a PITA.

Of course, if they are already checked in, contributors might not be able to see the files due to site, list, or even item permissions. Have a user navigate directly to this folder and drill down to the files to make sure they have access.

Unfortunately, I didn't do a very good job of explaining security in SPEasyForms in my manual, and have been meaning to do a blog post to cover the gap for a while now. Security in SPEasyForms is just file system security, so basically:
  • If a user cannot see the JavaScript files in the Style Library of the root site, SPEasyForms isn't going to do anything for them.
  • If a user cannot see the configuration file for a given list, SPEasyForms isn't going to do anything for them on that particular list. This file is located in the SiteAssets library on the same site as the list that was configured.
  • If a user cannot write to the configuration file for a given list, they cannot edit the SPEasyForms configuration from the settings page (or any other way as a matter of fact).
So if SPEasyForms is not working for a particular user or group of users, you generally want to do check effective permissions on the root Style Library and the SiteAssets library on the same site as the list, and also look for checked out files. Hope this helps. If not, ping me again and I'll try to work through it with you.

Joe
Marked as answer by mcsheaj on 3/19/2015 at 3:33 PM
Feb 4, 2015 at 9:50 PM
mcsheaj wrote:
Basically, my first guess is that your contributors do not have access to the JavaScript files in the Style Library/SPEasyFormsAssets directory that make the whole thing work for whatever reason. If you implemented the master page changes then they hide the form. The JavaScript files show the form, but not if they can't be read by the current user. If you're on SP 2010, the Style Library defaults to enforce checkout, so module files are laid down checked out, and contributors won't be able to see them until they're checked in. If this is the case, then the easiest fix is to delete the whole Style Library/SPEasyFormsAssets folder, turn off force checkout on the Syle Library, and then reinstall the solution. The files should now come in checked in. I've only seen this particular problem on SP 2010. You could just manually check in the files too, but there area a lot of them so this would be a PITA.
If it turns out to be the issue with SP2010 not checking in files by default in the Style Library (which based on my testing it probably is), I will share the PowerShell scripts I've written to deploy (or remove) the solution. I haven't shared them yet because I wanted to ensure they were compatible with 365 but I'll send the scripts to Joe tomorrow regardless and will just update if needed.

Casey
Feb 5, 2015 at 10:46 AM
I am using Sharepoint 2013 Foundation (german). I will try your suggestions and then I will post back.

Thanks and kind regards
Feb 27, 2015 at 8:53 AM
I think I got it now. The users who couldn't see the task list didn't have permission to the Site Library in the Homepage. I gave them permission and then everything was alright. This is a great solution but we had a small problem with conditional visibility for some fields. I set a dropdown field to hidden when a lookup field is set to empty but then the dropdown field is always hidden.
Thank you again for the solution.

Kind regards
Coordinator
Feb 27, 2015 at 5:26 PM
Excellent, and thanks for the feedback.

As for the issue with conditional visibility based on a blank lookup, it would help if I could get screenshots of your rule, new form, and list settings page. Adding attachments in this discussion board is kind of a pain, so I'm going to send you a private email that you can just respond to and add any attachments you want. If we figure out what the issue is, I'll post it back here for others who may have the same issue.

The reason I ask is there is more than one way I can see someone trying to implement that requirement, for instance I could have a rule something like:

Title; Hidden; where LookupFieldName Equals ""

But there is a problem here, at least on SharePoint online and I assume on 2013 as well (I don't have a 2013 machine in front of me at the moment). LookupFieldName never equals "" in the form. I'm not comparing the value as it is stored in SharePoint, I'm comparing the value as it is represented in the form, and a lookup has the value (None) until the user selects something.

If I change the rule to:

Title; Hidden; where LookupFieldName Equals "(None)"

it will work better.

I could also try a rule like:

Title; Hidden; where LookupFieldName Matches ""

so now, the rules engine is expecting the value to be a regular expression. With a blank regular expression pattern, this will always evaluate to true. If know regular expression syntax you should change this to something like:

Title; Hidden; where LookupFieldName Matches "^$"

and it should work better (I haven't actually tested this). ^ is beginning and $ is end, so "^$" says match a beginning and an end with nothing in between (i.e. blank).

If you loaded the AddOns package, you have even more options for doing this kind of thing because I've added numerous comparison operators including NotEquals.

The point is that without a concrete understanding of what your rule(s) and list look like, I'm kind of shooting in the dark here. a picture is worth a thousand words, and neither of us wants to type a thousand words ;)


Thanks,
Joe
Mar 2, 2015 at 11:27 AM
From: mcsheaj
Excellent, and thanks for the feedback.

As for the issue with conditional visibility based on a blank lookup, it would help if I could get screenshots of your rule, new form, and list settings page. Adding attachments in this discussion board is kind of a pain, so I'm going to send you a private email that you can just respond to and add any attachments you want. If we figure out what the issue is, I'll post it back here for others who may have the same issue.

The reason I ask is there is more than one way I can see someone trying to implement that requirement, for instance I could have a rule something like:

Title; Hidden; where LookupFieldName Equals ""

But there is a problem here, at least on SharePoint online and I assume on 2013 as well (I don't have a 2013 machine in front of me at the moment). LookupFieldName never equals "" in the form. I'm not comparing the value as it is stored in SharePoint, I'm comparing the value as it is represented in the form, and a lookup has the value (None) until the user selects something.

If I change the rule to:

Title; Hidden; where LookupFieldName Equals "(None)"

it will work better.

I could also try a rule like:

Title; Hidden; where LookupFieldName Matches ""

so now, the rules engine is expecting the value to be a regular expression. With a blank regular expression pattern, this will always evaluate to true. If know regular expression syntax you should change this to something like:

Title; Hidden; where LookupFieldName Matches "^$"

and it should work better (I haven't actually tested this). ^ is beginning and $ is end, so "^$" says match a beginning and an end with nothing in between (i.e. blank).

If you loaded the AddOns package, you have even more options for doing this kind of thing because I've added numerous comparison operators including NotEquals.

The point is that without a concrete understanding of what your rule(s) and list look like, I'm kind of shooting in the dark here. a picture is worth a thousand words, and neither of us wants to type a thousand words ;)


Thanks,
Joe
Read the full discussion online.
To add a post to this discussion, reply to this email ([email removed])
To start a new discussion for this project, email [email removed]
You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.
Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com
Mar 3, 2015 at 7:08 AM
I sent an answer per email but I can't find it in this discussion so I will make a direct reply.

Thank you for the fast answer. I tried some testing and it seems that conditional visibility has issues with accordions (in my test with columns). If all columns are in the default form then the conditional visibility works but if I put the lookup field in the first column accordion and the fields that should be hidden depending if the lookup is empty or not, in the second column accordion then conditional visibility doesn't work. I'll send you screenshots from my list. Tell me if you need more. The value (Keine) means (None).
Image1
Image2
Image3
Image4
Image5

I want to you to ask a question about an another issue that I had with the list. In the list in which we are extensively using SPeasy form, we made a lot of changes. We changed several times the column names and types and after I saved the list as a list template I made a new list from that template. The new template has still the old column names and types from the previous version of the original list despite that the list template was saved with the new column names and types. Did anyone else had similar issues. Sorry for the additional question. We are using this in a project for our biggest client until now.

Thank you again and kind regards
Coordinator
Mar 3, 2015 at 4:05 PM
My high school German is now about 30 years rusty (meaning non-existent), but even I remember keine ;). I'll take a look at the interaction between accordion and visibility rules and let you know what I find/fix.

As for your other problem, I haven't seen or heard of anything like that and I'm not actually doing anything persistent to the list or the forms. My configuration is a just a text file in the site assets folder, and I only modify the form dynamically at run time. I also only store the internal name of the field in my configuration, so you can change the display name and type and it shouldn't affect me much. Nothing I'm doing should affect saving the list as a template in any way, and SharePoint should be blissfully unaware of SPEasyForms.

Joe
Coordinator
Mar 10, 2015 at 6:15 PM
Edited Mar 10, 2015 at 9:39 PM
I have not been able to reproduce any issue with the interaction between conditional visibility and accordion. For me, conditional visibility rules based on the value of another field work the same whether both the field to be hidden and the conditional field are on the default form, on an accordion (different content areas or the same), or split (one on the default form and the other on the accordion, or vice versa).

Joe
Mar 13, 2015 at 2:39 PM
Thank you for the answer Joe

If we have problem with the conditional visibility, we'll just use the read only function. A colleague of mine was using the SPEasy Form for a list and he has run into some issues. The first is that if a field is from the beginning hidden then it CAN'T be visible, but when it is visible from beginning it CAN be hiden. This issue comes when you need to change something in a SharePoint list element via edit. Also, the second issue is that we tried to set a field in display mode to be invisible if its blank but it didn't work. If I open the list element in display mode then I can see every column even if they are set to be invisible in every mode.
Should I for these question create another thread?

Thank you again and kind regards.
Coordinator
Mar 14, 2015 at 2:35 AM
In general its best to open a new thread for each new issue. This is so others who have the same problem can find it, and the answer if its been answered. I also don't tend to look back at discussions that have been answered, but I do get an email too so I'll generally get back to you but it may take longer. And if there are two different issues in the same thread, then there are probably two different posts marked as the answer, which gets confusion. For now I've unmarked this thread as answered.

I believe the first problem from above is one that has already been fixed. I ran into it myself. Unfortunately, I wasn't disciplined so I didn't put in an issue for it and now it's hard to find exactly when it was fixed, but I believe if you download the latest AddOns package it should be working correctly. If you try it and still have a problem, let me know and I'll open an issue and work it.

I'll take a look at the second issue and see if I can reproduce it.

Joe
Coordinator
Mar 14, 2015 at 7:57 AM
Edited Mar 14, 2015 at 8:40 AM
I've been able to reproduce your second issue and opened a new issue, issue 28 - Conditional visibility rules based on the value of another field do not work on the display form, for it. I should be able to fix it in the next release of AddOns, which should come out shortly.

Joe
Coordinator
Mar 14, 2015 at 8:05 PM
I just released AddOns v2015.00.10, which should fix your second issue.

Joe
Mar 17, 2015 at 1:32 PM
Hi Joe

Thank you for the AddOn. The fix seems to be working. In my last post I forgot to mention that I had a small isue with the rules. When I change the position or hierarchy of a rule for a column then the settings for other rules of the same column vanish. In this example I tried to change the position of the rule for the lowest "highlight red" rule.
Before changing the position
After the positioning
This is not a problem for a form wich has only a few rules but we are now working on a list with over a 100 columns and most of them have several rules.

Thank you again and kind regards
Coordinator
Mar 17, 2015 at 8:27 PM
I just did a quick test and was not able to reproduce this. I'll keep playing around with this, but I may need a more exact set of steps that leads to this in order to track it down.

Joe
Mar 19, 2015 at 9:45 AM
I edited the pictures above and I marked the rule for which I changed its position from below to above every other rule. We also have run into another issue. When a field is read only then the rules for changing the colour are not working.
I am sorry if I'm making too much work for you.

Thanks and kind regards
Coordinator
Mar 19, 2015 at 1:37 PM
Not at all, you've got a big list with a lot of configuration, so you're exposing a lot of edge cases that haven't been picked up in testing by Scott and me. We kind of count on that. I'd much rather you come back and tell me the problems you're having. I expect a lot of people download once, it doesn't do something exactly the way they want, and they never come back. I'm sure anyone who goes to the trouble to release something to the community would rather be given an opportunity to address any issues, and others benefit from your findings as well.

As for your new problem, I know exactly what that is. The easiest way to do the read only fields is to hide the original row, and insert a new row with a read only value, which is what SPEasyForms does. But the highlight state handler doesn't take that into account, so when it highlights it does it to the original row (now hidden). This should be pretty easy to fix, I'll let you know when I have something.

Joe
Coordinator
Mar 19, 2015 at 8:00 PM
I recreated your scenario exactly, i.e. same field names and same rules, and got the exact same results as you when reordering. I have equally complex sets of rules that have no such difficulty, so I have no idea what the problem is yet, but at least I have something to debug.

Joe
Coordinator
Mar 19, 2015 at 10:33 PM
This turned out to be a generic problem with rules based on another field where the comparison value is specified as an empty string. It is fixed in AddOns v2014.01.12, and if you care about the details you can read issue 32: Visibility rules based on the value of another column being blank are lost when reordering visibility rules.

Joe
Apr 2, 2015 at 12:36 PM
Thanky you for your help. We have run into a problem when exporting the rules in xml form to another list made from a template from the original list. Here is the scenario:
  • in one of our first versions of the list we had a column named Helpy1
    -we have changed the column and rules several times and in our newest version the column Helpy1 and the rules with that columns were deleted
    -when exporting the xml to a list with the same columns, somehow the Helpy1 rule is still there although I deleted the column and the rules in the original list.
    Although, most rules are perfectly transfered but a read only condition is not workin as it should.
Kind regards
Coordinator
Apr 2, 2015 at 1:06 PM
I'm going to stop answering new questions in answered threads. If you want an answer, you're going to have to open a new thread ;)

Thanks,
Joe