I use a flat document list for certain document types and I want to give my users a possiblity to jump to the parent folder of this document.
Is there a column that contains this information? I couldn't find one.
No, there isn't a column or UI affordance for the parent folder in either a document library or the document library web part, nor is there a way to create a calculated field (without creating a totally custom field in code) - MSFT intended people to use the breadcrumbs I suppose. There are plenty of third party web parts out there for sale that provide this functionality (sort of) -but I haven't found one yet that I would recommend.
Is it something like this you are looking for?
As I couldn't find an easy solution for my problem, I just coded that field type myself.
Indeed, there is nothing OOTB that provides this information. At best, you can 'guess' the parent folder by getting the second-to-last segment of the FileRef column (the file's own URL):
▼ this one
/web/web/list/folder/folder/file.ext
Of course, that only works when you can have a reasonable expectation the file will actually be at least one folder deep. We have some limited cases where this works.
Related
I have this requirement:
We have a journalarticle and we wish to have sections which have content for internal and external users for the application.
We are able to hide the content from rendering by implementing custom template on web content display and using a simple custom-field for a user which helps us to classify it.
Having said that when we search something as an external user, the search portlet is able to fetch an article where the search text is a part of internal user content, and due to the above mentioned template the content is not visible.
In short, from the user's perspective the resultant article does not match the searched term.
I wish to seek some pointer to check whether there is a mechanism to ensure that when an external user searches something then we only search the dynamic-element of the doc which matches the user type?
We have thousands of such articles and create multiple copy of the same article does not seems viable solution.. so any pointers would be a great help.
Liferay version : 6.2 GA4 CE
Thanks!
AJ
First of all: Not finding a search term in a document can be a sign of good working synonym resolution in the search engine. It's questionable if this behaviour is always wrong or only in this particular case. Remember google bombs?
That being said, I believe that this architecture of half-visible documents is flawed from the beginning. Ideally I'd suggest to change it, for example by splitting the information to two articles, so that you can use the standard permissions to resolve. If you link both, you can determine how/which article or template to use. It's not an ideal solution, but might be a workaround.
Another workaround might be to change Liferay's indexer component and index two different versions of the article, with two different permissions. Of course, you'll have to change the search side as well, so that you'll find each article at most once, even if it's now twice in the search engine.
Again - not ideal, but might be the quickest fix that you can get right now without changing the underlying architecture. However, to change the underlying architecture is my actual recommendation.
I need to rename the content type I created a couple months back and
have been using for a document library, assigned site columns to, created
document library views for and have added workflow to.
It appears that this is quite simple to do under the site settings for content type. However it is often the simple, apparently straight forward things that cause unforeseen
issues.
Does anyone know of any gotchas when it comes to renaming a content type?
Here's some guidelines, the main statement though is:
The general guideline for evolving the content type IA is to never change or rename content types or their aspects, make new ones and hide the old ones.
You can set the SPContentType.Name property and then call SPContentType.Update(). Considering the guidelines linked to in Colin's answer you should test this in a non-production environment first.
I'm doing some work on an existing SharePoint site and part of what I need to do is create a new field on an existing content type.
I'm going to be deploying changes via a feature so I'm debating whether I use CAML to generate the field and then programmatically add it to the existing content type, or whether I can just do it all via the feature receiver.
What would be the best/ cleanest (and most reusable) solution for doing this?
A simple way is to do it in the feature receiver, get a reference to the SPContentType, add the field as XML (SPContentType.Fields.AddFieldAsXml) and then update pushing the changes to child content types
It is really tricky to modify content types on a site that already exists. My preferred method involves having a solution for all the content types and re-deploying that solution when changes are made.
I am going to go on the assumption that by field you mean a new Site Column. In this case I would do it all in the code behind. The amount of code that you need to write to create a site column is rather minimal. You can also attempt to remove the Site Column from any Content Types that are using it if you wish, but this is a task that is quite more involved.
From a reuse perspective if you set-up properties in the feature.xml file you can use those to configure things such as the column name, column type, target content type, etc. and then have a class that can be re-used in the future.
Have you looked at http://msdn.microsoft.com/en-us/library/ee537575.aspx, in particular the < AddContentTypeField> tag? That would be a declarative way to do this.
Is there anyway to change the length of the field that Sharepoint uses to store URLs. Its default is 255, which is just not long enough to hold links to content within the sharepoint site.
No, this is a hard limit in SharePoint. Studying the schema of the content database reveals the limit originates from the primary key columns DirName and LeafName in the AllDocs table.
I recently worked on a project where this problem also surfaced because users tended to create deep folder structures with long folder names and long file names. We managed to work around the problem by shortening some URLs according to these guidelines:
Prefer short URL names for sites and document libraries.
For document libraries, start by creating them with a title you want as the URL and then rename the title to the display name of the library.
Avoid excessively long folder names and file names.
Avoid excessively deep folder structures in document libraries, better create a few more document libraries.
I believe this is a WebDAV restriction. See File Name, Length, Size and Invalid Character Restrictions and Recommendations for more info.
However I could see this being a potential problem for linking to external content (although hopefully rare).
changing the length of a SharePoint data type could be dangerous when it's time for an upgrade. I would recommend making a new Site Column that has the properties you are expecting.
I've no idea how to solve this, I am having exactly the same problem, I found a hotfix for MOSS which will not work for WSS v3, it proposes to increase the length of the hyperlink field but is not compatable with WSSv3. It's a shame really.
You can't change it, but one work around is to shorten URLs when they can be shortened. Here is a free, online tool I wrote to do that:
http://qa76.net/shortener
It cannot help if the full document name goes over 255! But many times, the thing that has trouble is the view URLs that SharePoint makes. Those can be shortened, often dramatically.
More details on the page.
We deployed a feature that installs a custom site column named "Classification." It is a Choice column type. Now, we need to change the choices. We can update the XML in the feature easily enough, but it doesn't affect any of the lists already used the existing site column; they still see the old choices.
Is there any way to send a refresh signal or something to the lists that use our Classification site column feature to have those lists use the updated choices?
I think the only way to archive this is by iterating each list that uses the column and change the XML there as the column within a list has no reference to the original column any more.
Flo has a point, and I have previously been working with this issue and have made a blog post that might help you out somewhat. Have a look:
http://johanleino.wordpress.com/2009/08/11/propagating-updates-to-content-types/
SharePoint can do this.. Don't change your feature but modify the created site column in each site collection through the web UI. Changes made this way will propagate.
(I hope you don't have 10.000 site collections ;)