An alternative way to build the URL is like so:
domain/sites/sitecollection/lists/listname/editform.aspx?ID=1234
How do you do this with different content types however, if you want to open a certain form? Adding &Cotentype= @ the end does not always work for me...
This is how I build the links as well. It seems the most straightforward when explaining it to other users.
I keep it simple and have them use:
newform.aspx - New Items
dispform.aspx?ID= - open form in display mode.
editform.aspx?ID= - open form in edit mode.
Great post Cassy Freeman! I always find it interesting how others view and tackle the same "issues" but using different tools and approaches
Jesse,
That works in some situations, but my situation is one where there are different roles in the process, so i have 1 form for each of those roles. The forms are sepearte by content type. So have 3 different views, each with a different hyperlink to the form that is relavant to that role. So the hyperlink has the content type id in it. The problem is, this seems to mess up from time to time...
nick davis -
I could see that happening. Are you using Nintex Forms? Have you tried hiding sections based on user group membership?
I use this in a few forms where approvers or managment are given "extra" fields based on what user groups they are in. This allows me to hide/show sections all in the same form and the end user doesn't see or feel any differences.
Here is an example of what I did with out project managers and their managers:
Project Manager View:
Portfolio Management View (the users that actually approve if a project is a go or no go):
All I did is hide a section of the form like so:
Again, all this does is hide or show a section based on group membership. This requires that the user roles (in your case) are reflected properly in SharePoint User groups.
nick davis use the ContentTypeID query string. You can find your Content Type ID from the Content Type settings page in the URL.
I use this method too:
{Common:WebUrl}/Lists/{Common:ListName}/DispForm.aspx?ID={ItemProperty:ID}
{Common:WebUrl}/Lists/{Common:ListName}/EditForm.aspx?ID={ItemProperty:ID}
However I've hit a wall when I rename the list where the list display name changes but the list URL does not.
For example, I create a list called "MyList" then rename the list to "My List". The URL for the list is "MyList" but the display name for the list is "My List".
Now when I use the Nintex Common:ListName property in the URL it uses the lists display name instead of the system name, e.g.:
{Common:ListName} equals "My List" not "MyList" therefore {Common:WebUrl}/Lists/{Common:ListName}/ points to an incorrect URL.
Mitch
EDIT: The solution is to use the Inline Function Replace to remove the space from the URL:
{Common:WebUrl}/Lists/fn-Replace({Common:ListName}, ,)
This is really helpful! Being able to send somebody directly to the edit form is great.
Make sure you don't send links to Edit forms to users who only have Read access, because they'll get Access Denied.
Good day,
I created a Variable and added the String specified by Cassie but I am not very clever with this at all. The link does not work. Can you provide me with more info please. I must be doing something wrong.
many thanks
The easier thing to do is paste this exact line:
{Common:WebUrl}/Lists/{Common:ListName}/EditForm.aspx?ID={ItemProperty:ID}
It will set the correct values for you.
As mentioned above, the user must have edit rights for the link to work. Also if you re-name the list that can cause a problem.
Thanks John busy Publishing the Workflow and the name of the list won't change.
I found my problem, the SharePoint List should not have any spaces in the NAME.
Thanks again for everybody's help.
Have a super day!
We did it with a one hacky regex to the "ContextItemURL".
@cmikhaiel_e That isn't hacky at all! (the fact that we have to do this at all is a little hacky) Yours is the best solution here in my opinion as it's fully portable and you don't have to worry about spaces, etc... Thanks!
Thanks, that is much better than just constructing the string in the notification text. Doing the latter required me to edit the HTML to clear out some garbage text, and that of course leaves a maintenance problem for the future. Thanks again, Stan.