I'm currently looking for a new job, preferably in the Asia-Pacific region but I would consider other regions as well. If you are hiring or have any leads, I would appreciate if you would drop me a message via the
contact form, e-mail (daniel(at)spoodoo.com),
Twitter, or
LinkedIn.
Daniel
-
MichelGuest
StickyHeaders is not working when the users only have read access, only in quick edit mode.
If i add the user to the owners groups it works like a charm, the file is published and approved.
MichelGuest
FYI: But in the list has edit permissions
ClintGuest
Exact same issue here, as soon as I grant “Edit” permission the problem is fixed, but then users can break (and already have broken) stuff.
ClaytonGuest
Same issue here with users that have Contribute permissions.
StickyHeaders is working fine for all users in regular mode, however it’s only working in grid/quick edit mode for users with Full Control.
ClaytonGuest
Hey guys,
I’m unsure of the ramifications of this fix, so use at your own risk, but I’ve resolved this issue by changing line 89 (in version 3.1.1) to:
this.sticky = this.webpart.find(“tr.ms-vhltr:visible”).first();
I noticed the issue seemed to stem from this.sticky being undefined for users without full control on the site. this.init also seems to run twice for these users for a reason still unknown to me, but changing the .find selector to “tr.ms-vhltr:visible” seems to allow the second this.init run to retain/set the value.
Hope this helps someone, at least until Daniel Stoelzner can make a proper fix!
Hey Clayton, good find!
This issue has been resolved in v3.2.0
As you pointed out, there are two locations where the following selector was used: “tr:has(>th[class^=ms-vh]):visible”. In Datasheet view and when the user has less than Edit-permissions then the order of classes in some DOM elements seems to be different.
Changing both selectors to “tr:has(>th[class*=ms-vh]):visible” fixed the problem.