There's something fishy with the way the projects are being exported. Say I have two companies, a production and test. I move customisation projects between them. From testing, I wrote a new screen MA.20.20.20. And under custom files, the ASP files are listed as follows.
Once working I exported this project, got the ZIP file and then imported into production. For some reason, my customised screen MA.20.20.20 is missing from the list in the production. It's just blank ! The ASP files are still listed though and I checked ZIP project. The physical files are still in there.
So what's am I doing wrong here?
TIA
It sounds like you are referring to two different entries in the project. Your files are the pages in the pages directory while it seems like you also have screen modifications to your custom page files which I assume under customized screens would require a site map entry.
Are you including your sitemap entries in your customization project?
It seems like a little glitch in Acumatica. Publishing anyway ignoring this would solve the problem.
This is just a permissions issue. Make sure your role has access to that particular screen. It's a bit strange as I would expect the screen to show within the Customization Project for the administrator but apparently it doesn't. I had faced a similar problem where in my local instance access permissions was Not Set for any roles and thus I could see the screen. But in production one of the roles had the access Revoked for the screen and thus even the admin couldn't see the screen even within the Customization Project.
Related
I have found recently that a couple of newly created customisation projects seem to have disappeared from the Publish Customisation screen. I was wanting to make a change to one of them but I couldn't find the project anywhere.
On the login screen, I can see which customisations are published, including the two projects that have disappeared, which I have highlighted. The changes in those projects are still working, which is great, but if something was to go wrong or I needed to change the functionality, then I wouldn't be able to find it.
Here is the login screen with the publish projects highlighted.
And here is the publish customisation screen which is sorted by all published customisations. As you can see, the two highlighted projects are missing.
Do you know if there is a reason why they would be hidden, and if there is a way to make them appear in this screen again?
Thanks for any assistance on this.
As Joshua mentioned, the instance has multiple tenants, so I just needed to make sure that I published my customisation to all tenants.
I’m experiencing an issue with customization projects in Acumatica 2017 R2 Build 17.203.0029.
Specifically, custom screens, while in my project XML, are not visible within the customization project browser nor can they be navigated to once published (which occurs without error). This only occurs on my staging server. Everything works fine in my local dev environment and even on a different instance of Acumatica. My local dev environment matches the staging server in every possible way (Acumatica version, other packages, etc.)
Older versions of the same customization project have been published before and did not exhibit this behavior. It’s only after I replaced the project with newer version of the same project that I encounter the missing custom screen issue.
As shown in the screenshot below, remnants of the custom screens are present in the Customized Screens window. And the ASPX files are present and shown in the Custom Files window.
Screenshot of missing custom screen data
When I compare the “Edit Project Items” objects between the staging the server and my local dev version, they appear the same.
It it possible that the internal customization or sitemap tables on the staging server have inconsistent data? Is there anyway to rebuild them?
The solution appears related to the users roles config. I had not assigned access rights to the custom forms. Doing so solved the issue. The custom screens are now accessible by direct URL and are shown in the customization project browser. Maybe this will help someone else.
I had this same issue when trying to Deploy the customization to another instance.
To fix it I had to go to the site manager and change the URL of the new page
from: "/Pages/SO/CustomName"
to: "~/Pages/SO/CustomName"
While setting up a test environment I was attempting to set up many different types of sites for testing various things when I ran into a strange bug in SharePoint.
I was creating a subsite under a blank site template and saw the option for "News Site" so I selected it and got an error saying that the Publishing Feature was not enabled at the site collection level.
Fine. So, I went and activated it and then attempted to create the site again and I got the error:
The Web site address "/mpsite/news" is already in use
Ok, so the site must have been created anyway so I try to visit the URL and get:
The webpage cannot be found
Fine. So, obviously it errored in the middle of the site creation so I'll just delete it via STSADM. Wrong:
There is no top-level Web site named "http://server/mpsite/news/".
So, the site is listed in the sites and workspaces list, but doesn't really exist and can't actually be deleted.
How do I get rid of it from the Sites and Workspaces listing?
You've run into one of the lovely undocumented "features" of SharePoint - site templates get applied after the site gets created in a seperate, descrete step. This means that potentially, a site can "exist" (as far as the content database is concerned) without template, which leaves you with a site you can't browse to, but still sorta "exists" in SharePoint purgatory (I've actually written a couple of hacks that involve relying on this "feature").
It looks to me like you may have run into one such situation - when you went to go create your site, I'm guessing that you got the error before the template was applied to your news site.
The way I've fixed similar problems in the past has been to use SharePoint Designer to delete the sites - since it looks straight into the content database for what does and doesn't exist, it might do the trick for deleting your rouge news site.
Hope this helps!
Have you tried http://server/mpsite/news/_layouts/deleteweb.aspx ?
Or maybe the "Content and structure" (http://server/mpsite/_layouts/sitemanager.aspx) link from site actions?
I know this is old, but it may help somebody. In SP2013 running the Remove-SPWeb Powershell command with the url of the corrupted web worked perfectly for me.
I am developing publishing site. I have some layouts that are pre-populated with web parts and have a problem when I need to make some change on the layout.
Deployment succeeds but I still see old version. If make I change in SP Designer it is reflected OK but not if the change is done by the feature that is being deployed.
It looks like after I deploy particular layout any site collection in that web application will have the first version.
I have tried deleting complete site, all the pages, layouts and nothing happens, after deployment I still see old layout.
Current solution for this problem was that I take new virtual image and start with clean machine.
Real problem is how to solve this on clients installation without reverting to clean machine. There will be some bug fixes and I will have to send new WSP file with some changes in layout.
Is there any way to force SharePoint to use newly deployed layout and not some old Unghosted version?
If the layouts are without web parts I don't have this problem.
Update
I am using default "Publishing Portal" and deploying layouts using features. For development I am using VSeWSS 1.3.
tried in SharePoint designer to detach page from layout and attach it again but still no results.
Since you are using VSeWSS, you can execute your own code upon feature activation. So try writing an SPFeatureReceiver that will call SPWeb.RevertAllDocumentContentStreams() to reghost directly after feature activation on the web(s) in question.
If this doesn't work, then the problem isn't about ghosting, maybe it's about Orphans then. But try this first.
If it's a feature that you are deploying you have do deactivate the feature and activate it after deployment again. And don't forget to do an IISRESET or an AppPool recycle.
If your new site collection has the first version of the layout make sure that it is really your new feature version that you are activating.
Try to reject your solution first and add the new one after that.
Are you using Site Definitons or Site Templates? If you are using either of these it may not update after initial provisioning.
Try completely retracting and deleting the solution from central admin, resetting AppPools and then redeploying the solution.
Make sure your element manifest for your feature specifies that existing files should be overwritten.
Looks like some folks have had problems with layouts too...
See http://msdn.microsoft.com/en-us/library/ms459213.aspx
If you are developing new sitedefinition, you can attach your new layout in the onet.xml file by using the property, i hope it will help you
-->
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.