MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

UI list views not visible in Designer

  Asked By: Mariah    Date: Aug 13    Category: MOSS    Views: 2576

In a MOSS custom list which has custom edit forms, I see "views" in the UI which
do not have a counter-part when I view the site with SPD. Where are these views
coming from?

When I click on one of these "extra" views in the "drop-down", I am taken to an
aspx page that we built that has only 4-5 java-scrip lines to shut the browser
down + a message saying we are shutting down. We use this page as a "forced user
exit" in conjunction with custom edit forms to allow users to edit only specific
list columns.



11 Answers Found

Answer #1    Answered By: Beatrice Serrano     Answered On: Aug 13

Each time you create a custom  view it generates a new .aspx page  that is stored
in the list  folder. I just created a custom list and then created a view  in the
UI. That view shows as an aspx page that was created in the list folder when
I'm in SharePoint Designer. Each custom view gets its own aspx page.

Answer #2    Answered By: Maya Lewis     Answered On: Aug 13

I have the opposite problem. I see links to pages in the UI list  view drop-down
that I do not know how got there. (Horrible English) I did not "create" any
views for these. There are no aspx files in SPD correcponsing to these views.

Answer #3    Answered By: Paola Mcmahon     Answered On: Aug 13

What links are you seeing, and was the list  created from a custom  list or from
some other type? There are some lists, like a calendar that I think have some
built-in views  that aren't actually files.

Answer #4    Answered By: Justin Mckee     Answered On: Aug 13

It is a custom list  built using a content type. The content type is used on
20-30 sites, increasing at ~10 per year. We used a content type so we could
change columns  everywhere from "one" spot. Additionally, this list has 2 custom
edit forms.

The views  I am seeing have the name of the list, but the content seems to be a
custom aspx page  I created which has only a message  and javascript to shut the
browser. As an aside, I cannot find these pages on my site  anymore. They used to
be right at the site root.

How is this for a guess: when we changed content type 1-2 months ago, the
changes did not propagate to the custom  edit forms  (the GUIDs didn't update) and
somehow this screwed up the views?

Answer #5    Answered By: Jared Bell     Answered On: Aug 13

I just posted a word doc containing 2 images of the two conflicting list  views.
Its name is screens_FinList_views_091014.

Answer #6    Answered By: Bernice Puckett     Answered On: Aug 13

Very likely. Was the content type built  in the browser or deployed as a
feature? If as a feature then doing an update to that can't be done just by
upgrading the feature.

Answer #7    Answered By: Mackenzie Lewis     Answered On: Aug 13

The content was built  with brower. There are WFs on these custom  edit forms  too.
We use this site  as a template to build new sites, and for old sites, we trusted
that the new content type would get "pushed out."

So what is the correct way to make changes to custom list  columns, custom edit
forms, and WFs on the whole mess, so that things propagate throughout a site
collection when changes are needed?

We thought that 1) templatizing a site (with content), and 2) content types at
the site collection level would solve this. Apparently not or are we seeing

Answer #8    Answered By: Kurt Gilbert     Answered On: Aug 13

This will be a long answer and I need to ask another question first. First the

1) Are you using the site  template in the same site collection where it was
built or have you moved it or loaded it to the farm level using STSADM?

2) Are the WFs you are using built  from the OOB WFs, custom  visual studio or

Here's why those questions matter.

1) Content Types built in the browser are created with a unique GUID in the
Content Type gallery. If you build an identical content type in another site
collection it will have a different GUID and therefore won't be recognized as

2) Saving a site as a template only saves the things that are built inside that
site, not Content Types built at the top level site of the site collection. If
you try to use them in a different site collection you won't get all the same
content types.

3) SPD workflows are saved as part of a Site Template, but since they rely
heavily on GUIDs they may or may not function in a site built from the Template.
Thorough testing is required.

4) Changes made to content types deployed as Features can't be updated by
updating the Feature. A custom application needs to be written to update them
using the object model. Content Types built in the UI are more forgiving, but
still not perfect, especially when it comes to views  and document templates.
You should treat content types like a record schema in a database. Changes
should be avoided whenever possible.

In answer to the question "what is the correct way to make changes to custom
list columns, custom edit  forms, and WFs". The only real answer is Plan right
up front and don't make changes. Changes to these elements don't propagate.
Custom programming is usually the only solution.

Answer #9    Answered By: Jaya Deoghar     Answered On: Aug 13

1) the site  template that we build (with content) is only used in the same site
2) WFs are all built  with only SPD. We do not use any OOBs.

Per your point #3, the WFs to manipulate the custom  edit forms  seem to be OK
except for permissions when we stamp out a new site. These have to be -re-set
manually with each "stamp out."

Answer #10    Answered By: Candi Branch     Answered On: Aug 13

The permissions setup would be expected since site  templates assume inherited
permissions and never store customized permissions, users, or groups in the
template. Since the views  are associated with the content type I suspect they
aren't being copied correctly as part of the template process.

Answer #11    Answered By: Jan Chen     Answered On: Aug 13

I don't know if this helps, but I believe I have seen this kind of behaviour
when I added a list  view web part to a page  in SharePoint Designer. Even though
the page was not stored within the list, that page seemed to get registered as a
view in the list properties, and showed up in the views  drop down for the list.
Is it possible that at some point a list view  web part was added to that "forced
user exit" custom  page then removed again? Or maybe that page was originally
created by copying a page that had a view of the list?

Didn't find what you were looking for? Find more on UI list views not visible in Designer Or get search suggestion and latest updates.