Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Specific user can't add/edit items in a list

  Asked By: Colin    Date: Nov 29    Category: Sharepoint    Views: 13119

Here’s one I haven’t been able to dig up on the newsgroups…

I have a new user account that’s been added to the Contributor role for a portal (I’ve also tried setting it at the specific area in question). When this user goes to add/edit a new record in a list, I get the New Item form, but with no textboxes to enter values. Never seen this… it looks EXACTLY like any other New Item form, just no textboxes.

When I login as me (where my account is an admin on the server) and try to do the same thing but I get the expected result: a normal New Item form with textboxes. I get the same intended result when I use another account which is NOT an admin on the box, but has been granted contributor rights on the portal.

When doing all this testing, I’ve done it all from the same machine using the Run As trick to try running under different user accounts (doing all this from a different machine that’s actually running SPS).

So… to me I don’t think it has anything to do with SharePoint… but instead it’s an issue with this specific user account.

Has anyone seen this behavior before? I’ve attached screenshots of what a working account sees (ExpectedBehavior.png) and what the non-working (no textboxes) account sees (UnexpectedBehavior.png).



9 Answers Found

Answer #1    Answered By: Mary Adams     Answered On: Nov 29

I had similar yesterday and it bugged the hell out of me for an hour. In
the end, it turned out to be a missing owsbroswer.js. The little left and
corner icon had been showing a "page loaded with errors" and the detail said
that "brosweris is undefined."

Anyhow, I found and replaced an owsbrowse.js and life went back to good
(after of course I deleted files in IE and iisreset). I have (am) messing
with the client side scripts, and I do recall deleting the owsbrose.js at
some point in my confusion caused by not 'deleting files' in IE after
client-side script changes.

Doesn't sound like your same issue, but this experience of mine may give you
a needed hint - this could be a client-side programming issue.

Answer #2    Answered By: Kyla Eckert     Answered On: Nov 29

You’ve got one part right: “it bugged the hell out of me for an hour”… I’m going on #3 right now…

This isn’t the same issue… I have no JS errors. Also, I’d expect to see this for all users hitting this list, not just one isolated person (and all testing  is coming from a single server).

Answer #3    Answered By: Alyssa Butler     Answered On: Nov 29

Try the &contents=2 trick  to get the list  of web parts on the page and look for the list form  web part on the page. Reset the personalization data if necessary. It’s technically possible to personalize a list page…

Answer #4    Answered By: Gopal Jamakhandi     Answered On: Nov 29

I've seen this once before but don't have any valuable insight to give

Is the Web based upon a custom site definition?
Has the SCHEMA.XML file been changed in any way?
Has the listview page in question  been unghosted?
Has the ows.js file or the owsbrowse.js file been altered?
If there a CustomJSUrl file?

If you create a new web and create a new list  does the problem persist?

Answer #5    Answered By: Ana Payne     Answered On: Nov 29

Saved the list  as a template, added  it to the gallery of a totally different portal  (same site definition, same server, same farm), created a new list based off the template, and got the exact same results.

I was having another issue  and when I saw this behavior, I thought it was the root cause… apparently not though as I was able to fix my other issue while this remains a problem. Now it’s  more of a curiosity as to why it’s happening.

Answer #6    Answered By: Laura Walker     Answered On: Nov 29

I’ve seen similar things like this. The workaround that I try first is to ensure the portal/VS URL is in the trusted sites in the local browser. Don’t ask me why…

Answer #7    Answered By: Lacey Daniels     Answered On: Nov 29

This is a puzzling one indeed. I’ve never seen it before, but here are perhaps a few things you could try.

Did you check the security permissions on the included .js files? Perhaps there is a security setting  on one of those files that would prevent just that one user  from accessing the underlying JavaScript. I don’t  expect that this would be it, because if it was, I would expect there to be either JavaScript errors (which you said you did not have) on the page or a login  prompt. But, it may be worth checking anyway.

Another thing  you could try is checking the user’s JavaScript settings under Internet Options in IE. That is one thing that could be different for that user account. The textboxes are all created by calls to JavaScript functions, so perhaps JavaScript calls are disabled?

Finally, look through the HTML source code of the page, as well as your style-sheet file for any references to ms-formbody. This class is used for all text box  fields. Perhaps there is something causing the class to be hidden.

I know none of these offer solutions, but maybe you can at least find some clues from these ideas.

Answer #8    Answered By: Megan Martin     Answered On: Nov 29

We had something similar. It happened to two different users. One was a Contributor on a Document Library but could not open a folder in that library. The other was a Contributor on antoher Document Library and could upoad a document but could not edit it.

I donb't know why but ihn both cases the browser settings Tools->Internet Options->Advanced for Disable Script Debugging (Other) was cheked. Once it was unchecked, things worked properly.

Answer #9    Answered By: Donta Kirkland     Answered On: Nov 29

The component that isn't rendering properly is a List Form Web Part. I
suspect the black box  source code embedded in it. Perhaps you could try
editing the page in FrontPage and customizing the Web Part (right click
on the Web Part and choose "Customize SharePoint List Form" from the
context menu). This gets to the heart of the displaying of fields. Make
a few changes. See the impact on the odd user's view of the page. Then
go back to the original display (right click on the Web Part and choose
"Revert SharePoint List Form" from the context menu). Again, see the
impact. Then reghost that page.

It may be a wild goose chase but you may learn something about the

Didn't find what you were looking for? Find more on Specific user can't add/edit items in a list Or get search suggestion and latest updates.