I am using Dynamic View Panel (xe:dynamicViewPanel) to display views. In my XPage I pass the name of view as a parameter to URL and then I fetch it and put it into viewName property of data source. On my server I have Domino 8.5.3 with Upgrade Pack 1. On my local machine I have extension library from OpenNTF (ExtensionLibraryOpenNTF-853.20120320-1003) installed.
According to my observation the Dynamic View Panel is showing the first non-categorized column as link to the document. So if in my first column of view I only write field name, say UserName, then that column is shown as link. But if I put in formula in first column as #Name([CN]; UserName) it doesn't show as a link, instead the next non-computed non-categorized column is shown as link. This behavior happens only with my server which has Domino 8.5.3 with Upgrade Pack 1.
But when I took a local copy of the database and tried to run on my localhost (which has extension library from OpenNTF) the computed column of #Name([CN]; UserName) shows as link.
Has anyone encountered this behavior? Is this a bug? Any work around?
Found it: I have reported this bug on openntf and it was fixed.
http://www.openntf.org/projects/pmt.nsf/66d9103768cc2fed85256c59006b5433/c3ccbddbdc0e44bf8625796d00305196!OpenDocument
But it wasn't fixed in UP1 codestream.
I suggest to use ExtLib distribution, as it is more feature rich (and bug free) than Upgrade Pack. Thanks to new feature of 8.5.3 you can distribute latest ExtLib via update site so no installation on server is needed.
Related
I'm currently learning how to extend Sharepoint Online (ie Sharepoint Modern) and am not sure how to achieve the below, so any pointers would help.
We want to create a site to be used as a knowledge base for pages on specific subjects.
(as this site would only have these pages would it matter f it were a Team Site or a Communication site? I suspect it dsoesn't matter)
There will be multiple revisions to each page, but we would like to keep earlier versions and just flag which is the current one.
Example :
Page 1 : Introduction to company systems
Initially this would be created as Version 1, and be visible to all users.
Later we create a new,edited copy that is Version 2.
Both remain published but we want to make sure visiters are offered Version 2.
What we would like:
A way to flag the version number against each page. I assume this would normally be done by a column in a list of the pages eg column 'Version'?
A way to flag the page that is the current version. Again, a list column eg column 'IsCurrentVersion'?
Is there any way to edit these columns (ie 'Version' and 'IsCurrentVersion') from within the page rather than having to open the list and edit the list row? (eg Possibly using PowerApps?)
Is there a way so that when an editor flags a page as the current version, an automated process goes through all other version of that page, and sets 'IsCurrentVersion' to 'No', so only one page is ever seen as the current version? (eg using Power Automate?)
A way so that when a user views a page, it checks to see if it is the current version (eg by checking the list column 'IsCurrentVersion') and:
if it IS the current version it offers a link to a list of previous versions,
or if it IS NOT the current version, javascript adds a class to the page so it is obvious this is not the current version (eg, a tinted overlay, pseudo element watermark) and offers a link to the current verison (would this be done with spfx extensions)?
Finally, (this may not be needed) a way so that some users cann ONLY see the current version - -e if they manage to get the url to a page which is 'IsCurrentVersion' set to 'No', they can not open it, or it redirects them to the current version, or sets a class with styling to hide the content (the last option is least desirable as it it is easily overcome by the user).
I am hoping this is possible in Sharepoint, and showing me where to look for solutions would be fantastic.
A few times I've attempted to customize a SP2007 page using css, html, or javascript in Sharepoint Designer; however, in Sharepoint Designer I am not able to get direct access to the desired elements since they are generated by a Sharepoint Control (such as a web part or dataview) and appear only AFTER the page is rendered in the browser. I use use IE's F12 to tracked the element I wish to change. Then I can see an identifer such as name or id I can use in my javascript or css.
Example 1: SP2007 generates "name=ctl00$PlaceHolderMain$g_ba9196a9_2842_4607_b048_9a443cb4def5$ff2_1$ctl00$ctl00$BooleanField" for an input text box. I use that name to manipulate the text box as I desire.
Example 2: SP2007 generates "id=zz6_menu" for the "Welcome" text which I use to get the users full name.
So far this has worked out fine. Am I tempting fate?
Can someone refer me to a reference that discusses how these names and other Sharepoint Control element identifiers are generated?
Are they stable? Can I count on them to be the same provided the application I develop with my version of SP isn't updated to a later version of SP? And even if that case I'm thinking I can simply update to the identifiers created by the newer version of SP.
Is this a good practice? Any other comments?
All responses are welcomed.
Thanks.
SharePoint is based on ASP.NET and that's why the Ids are automatically genereated.
cf this article.
You should not use them to identify elements on css or js.
Do not write code that references controls using the value of the
generated UniqueID property. You can treat the UniqueID property as a
handle (for example, by passing it to a process), but you should not
rely on it having a specific structure.
In my opinion, the best way is to rely on the css classes because they are not automatically generated and should not change a lot.
Anyway, if you upgrade to SP2010 or 2013, lot of your modifications won't work anymore because the structure and css changed...
I'm having a problem with the Person Picker control in InfoPath 2010. I enter a name and it is resolved and displayed on the control. So far, so good. Now I'm trying to retrieve the value of AccountId provided by the control. It works when I preview the form locally but when I publish it to SharePoint (this is a browser-enabled form) the AccountId is coming back as blank.
Below is the XPath I'm using. (I tried adding an index, as in "Person[1]", but InfoPath didn't like that either. Besides, I've limited the control so that only 1 user can be entered.)
/my:myFields/my:ApproverGroup/my:Analyst/pc:Person/pc:AccountId
Same result if I try to get DisplayName or AccountType--works in preview but not when I publish. And I'm publishing to my local SharePoint Server (same machine I'm developing on).
Any ideas? Thanks in advance.
I figured it out. Turns out a postback is required before the data source will reflect the value entered in the People Picker control. Why this is I don't know, but it somehow primes the control to work properly. This postback can be done once on form load and then the People Picker will work after that. So my next problem was looking for a way to force a postback on form load. Also, the People Picker inexplicably does not include a "Postback settings" property as, say, a textbox does. I resorted to enabling the postback setting to "Always" on the first textbox on my form, hoping the user will enter a value there before scrolling down to the People Picker control. It's a terrible hack, but the only workaround I have so far. If anyone can provide a better answer here please do so.
I have a SharePoint 2010 Foundation site that has recently been upgraded from WSS 3.0. The upgrade was completed successfully with no glitches.
However, ever since I have upgraded the site I have got a problem relating to lookup fields on the NewForm.aspx (New list entry page) on some calendar lists that were existing on the site prior to the upgrade.
The issue is that I have two lookup fields, one for Client and another for Meeting Type / Location. When I am on the NewForm.aspx (new list item entry page) and I select an entry in one of the lookup fields the second doesn’t allow me to select anything and just gives me the top value in the lookup list without offering any other alternative selections like it should. These fields are just standard SharePoint Lookup fields and are not modified in any way, nor is the page. This problem does not happen on new lists I create (with more than one lookup field in them) in the site nor does it happen if I add extra lookup fields on the existing lists, it just leaves these two fields with issues.
I have used Internet Explorers debugging tools to see if there is an error in any of the JavaScript on the page but nothing is being reported as being a problem and I have also tried rendering the page in different standards in Internet Explorer to see if it is related to the browser but these do not many any difference. One thing that is apparent though is that the values for both lookup fields are being pulled in to the HTML of the page as I can see them when viewing the HTML source of the page when it has loaded and in the Developer Tools in Internet Explorer…
If anyone has any experience of things like this and could point me in the direction of a fix for this I would be very grateful...
Many thanks in advance...
Take a look at these two links. This first might be your issue and while the fix was included on August 2012 CU you still have to make a manual edit (not a true fix in my book)
http://support.microsoft.com/kb/2598273
http://support.microsoft.com/kb/2687375
We had a need for a document management solution and were hoping SharePoint 2007 would satisfy our needs. We felt our needs were relatively simple. We needed to manage versioning, have searching capabilities, and having an approval workflow.
SharePoint handled these three aspects great out of the box.
However, we also require that the footer on the Office 2007 (Word, Excel, and PowerPoint) documents reflect the document version, last person to modify, and last modification date. These things can be done with office automation, but we have yet to find a complete solution.
We first tried to do it on the checking-in and checked-in events and followed this path for a while, however, the complication we ran into was after we made the changes to the document we had to no way of preventing the save from updating the version number. This resulted in something similar to this:
Document checked-in – the document version should be v0.1 however it is v0.2 because we save the document after the footer is replaced. If we look in the document history we there are 2 separate versions v0.1 does not have the footer v0.2 has the footer but it says v0.1 as that is the version the document was when it was replaced.
This is an unacceptable solution for us as we want the process to be completely handled on the user side so they would have full control to revert back to a version where the footer would be incorrect and not contain the correct data. When we attempted to create a custom approval/check-in workflow we found that the same problem was present. The footer is necessary so that hard-copies can be traced back to their electronic counterpart.
Another solution that was proposed to us was to build plugins for office that would handle the replacement of the footer. This is inadequate for our needs as it requires a client side deployment of our plugins which is undesirable by our clients. What we are looking for is a clean solution to this problem.
Here is a blog post which seem to be exactly the solution of your problem.
Basically they create a custom field in the document library and use event receivers to keep the current version of the document in this field.
The "trick" is that on the client side this custom field shows up as a property of the document the value of which you can easily embed into the document's contents.
I'm not sure why changing the field won't increase the version of the document, but I guess it is because you're only changing metadata, not the actual document.
They do use a little VBA script which runs on the client side, but it doesn't require any client side deployment as it is downloaded with the document. However I'm not sure if any security settings changes on the client side may be needed to allow the script to run.
Does this information need to be in the footer? A lot of the information is available within the Office 2007 application. If you click on the round button in the upper left, and select "Server", you can view the version history, a lot of the other properties are available by clicking the round button and opening the "Prepare" menu, and selecting Properties.
If this information must be displayed in the document footer I would investigate creating a custom Information Management Policy. This may be a good place to start.