I have a customized Account "Main" Form in CRM.
I added a new tab, a new section, and new fields inside it.
I published all customizations before-hand, then export, then import into my test environment. I publish all in the test environment.
The Unmanaged Solution contains this form and its new fields; When I review the Form XML in the exported zip's customizations.xml file, it indeed has the new tab label, new section label, I can see the fields in the XML.
PROBLEM: But after importing and publishing into the test environment... the changes don't show up!
What I see in its place is the way that section looked BEFORE (not sure how long ago last time it was changed). It's simply not getting my latest changes.
How can an Unmanaged solution import have these issues? What else is there to check/consider? I don't think Solution Layers would cause this since it's Unmanaged, nothing stood out there anyway.
Please follow this check list, also note* with Dynamics it needs more env/info including your environment to trouble shoot, since it could be something in tandem with your env.
1. Usual Suspects in an UnManaged Solution
With yours being an UNMANAGED solution, I strongly suspect its a security permissions issue not setup/enabled in the Target environment, check your logs, you may see something like this
Try these Solution Importing steps
Import your main solution (note* without field security profiles).
Now, Publish all your customizations (note* you can enable/import the field security after this step)
Lastly, Import the second solution which would contain your field security profiles
2. Troubleshooting Checklist
To resolve/hunt down the issue, try these checklist steps
Check IIS: if you reset/restart IIS, (after define and publish your field)
Clear you client side cache: run it by
pressing Ctrl+F5
Clear you server side cache:
https://learn.microsoft.com/en-us/powerapps/maker/portals/admin/clear-server-side-cache
Are using the entity form:
Do you have the correct: entity permissions Notes & Sub Grid
https://learn.microsoft.com/en-us/powerapps/maker/portals/configure-notes
Did you add the metadata
Lastly are you using activities
Related
So the column in question was a lookup column, which i deleted in the unmanaged solution, and mistakenly created a new column with the same name. Dynamics by default will use the same auto-generated schema name based on the display name. So when I go to import the unmanaged solution in my dev environment into the production environment as managed, obviously it throws an error because of the mismatched of data types per column schema name.
Error returned by Azure Pipeline
So I did the sensible next thing, and went to delete this column in my dev environment. But oh no! There are object dependencies which prevent me from deleting it, okay I look at which objects depend on this column, it is a form, i remove the column from the form, go to delete and oh no again! There is still a dependency on the form I just deleted the column from.
So what do I do? I can't change the column schema name, I can't change the data type back to the data type that's currently in the managed solution. Is this when I open up a microsoft support ticket? Hopefully someone here has some insight. Thanks!
The attribute can be associated with a custom control. Try removing this custom control using the classic form designer. It should be visible on one of the field property tabs.
If the attribute cannot be found anywhere on the form using the classic or modern form designer, try this:
Create a solution with this form only. Export the solution as unmanaged. Extract the customization.xml from the zip. Edit the xml and remove all references to your attribute. Paste the customization.xml into the zip and import and publish the solution.
The only way to delete a managed component is to upgrade the solution. In your case, you can delete the field and dependency in solution and apply the upgrade to target environment. Please noticed that all data in this field would get deleted when you apply the upgrade. You may check this link for more detail
I'm trying to add a new Parameter called CorporateIdentity to the SalesInvoice report in dynamics. I've added the parm***() method to SalesInvoiceContract and compiled the Contract, the Controller and the DataProvider forward.
But I can't get the parameter to show up in Visual Studio. I've tried refreshing the DataSources. I've tried deleting and recreating one of the DataSources. I've tried to create the Parameter manually.
How can I get this parameter to show up?
The answer was to perform an incremental CIL. Some other things to try are listed below.
Have you performed an incremental CIL?
Did you try refreshing your caches (Tools>Caches, just do all of them)?
Try restarting the AOS service and the SSRS service.
Is your WCF data up to date in your AXC file?
Try clearing your usage data and AUC/KTI files.
There are all sorts of weird things to try, but I listed them in order of what I would try ... no need to do them all if one step works.
I have my SQ server running in Kubernetes (via Tectonic) and all is going well. We need to tighten the security of our SQ installation, so we have LDAP up and working. We are trying to get all of the projects to be Private by default (which we can do Via the GUI for each project).
However, trying to flip the switch in the GUI to make all new projects Private works, until you refresh the page, then it reverts back to Public.
I have been searching for a way to set this up via the sonar.properties file or sonar-project.properties file (first if the preferred). The server.properties file we use is encrypted as a secret (because the LDAP settings exposes a service account password) and I would like to keep settings there.
I have combed through documentation, posts, discussions and all that, but have not been able to find out what the value=key combination is.
Has anyone seen what this is or if we can even accomplish that? Is it a setting stored in the database? I'm kind of at a loss on this one.
Thanks!
In SonarQube 7.x you can find the public/private setting when you browse to Administration - Projects - Management. This only works for new projects. For existing projects you can use the "Edit the permissions" option on the same page and switch between public and private.
You can also use the web_api to achieve the same results. You can find the documentation when you add "/web_api/api/projects" after the sonarqube URL:
Example of the POST request body: project=MyProject&visibility=private
I'm currently editing my portal_normal.vm (server/tomcat/webapps/mytheme-theme/templates) testing if I can write on the file and see it on my browser. I tried putting a test comment "<!-- test -->" just to see if I can really write on the file. So I refreshed the file and hope I can see the comment I've added, but there we're none. So I continued refreshing (ctrl+r),\ and viewing the source code for almost an twenty minutes. After a while when I tried viewing it again it reflected in my source code. So I thought it was cached by either Liferay or my browser.
So I tried tweaking the comment adding version on it ("<!-- test v2 -->"), hoping to see changes. I checked it on another browser and the comment didn't update or include my added version. So I think Liferay is responsible for the issue.
this is what my portal-ext.properties contain:
auth.token.check.enabled=false
# Database settings
jdbc.default.jndi.name=jdbc/LiferayPool
#For removing captch
captcha.check.portal.create_account=false
session.enable.phishing.protection=false
default.regular.theme.id=my_site_WAR_my_theme
#Delete cookies while deleting session
session.enable.persistent.cookies=false
#redirecting null problem.
redirect.url.security.mode=mysite.com
journal.template.velocity.restricted.variables=
admin.email.from.name=Market.Travel Team
admin.email.from.address=admin#mysite.com
# Added because of the Error - No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here
hibernate.current_session_context_class=thread
session.enable.url.with.session.id=false
and my portal-developer.properties
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=true
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
Addition: When I tried editing the css files I can see the changes fast. Just one reload the the changes appear. I think it is just in my velocity template that take some time or there's something wrong.
Liferay version: Liferay Portal Community Edition 6.0.6 CE
Thank You!
There is really no need to define your own portal-developer.properties. By adding -Dexternal-properties=portal-developer.properties to your JAVA_OPTS in tomcat/bin/setenv.(sh|bat) Liferay will use it's default developer settings, which are almost identical to what you have provided. However, I do not believe this is contributes to (or could resolve) your problem. More details here.
The developer properties do allow you to make live changes to the templates provided you are changing the right file. Due to the default context.xml Liferay provides to the deployed webapps, the webapps are copied/cached in tomcat/temp/{id}-webapp-name. This means if you change the template in webapp/mytheme then it may take tomcat a while to pick up on the change, if it notices the change at all (this will depend on the tomcat configuration). On the other hand, if you make a change in temp/1-mytheme it will show up immediately. Editing the files in the temp folder is probably not ideal, so...
How to fix this: (no specific order)
Prevent Tomcat from using the temp directory for your theme. Create a context.xml file for your theme.
<Context cachingAllowed="false"/>
This file should be placed in the META-INF folder of your
theme. If you are using the Liferay auto-deploy feature the
context.xml file may be clobbered, here, and here. If this
is the case you will need to find a work around that best suits your
needs, such as modifying the context.xml after the theme is deployed.
If you are using the Liferay Plugin-SDK the you can follow the fast plugin development guide for setting up your development environment.
I have a Managed Object Context to which I add two different SQLite stores. I use Configurations in the Mananged Object Model to assign certain entities to one store and other entities to the other. The Configurations are called "UserDB" and "MainDB".
Everything works okay until I try to use automatic migration. After creating a new Managed Object Model version, and adding a new attribute to one of the entities in the UserDB Configuration, I get an exception when adding the old version store (for the UserDB related store) to the store coordinator: 'Model does not contain configuration 'UserDB'.' I can find no hits for this error on Google. Anyone out there using multiple stores with Configurations? Anyone have an idea what I might be doing wrong?
The stack looks like this:
objc_exception_throw
-[NSManagedObjectModel isConfiguration:compatibleWithStoreMetadata:]
-[NSStoreMigrationPolicy sourceModelForStoreAtURL:metadata:error:]
-[NSStoreMigrationPolicy(InternalMethods) _gatherDataAndPerformMigration:]
-[NSPersistentStoreCoordinator addPersistentStoreWithType:configuration:URL:options:error:]
-[MyAppDelegate persistentStoreCoordinator]
This looks like a bug with migration+configurations. I was able to work around the problem by going through the same motions and passing nil for configuration when calling addPersistentStoreWithType. The migration happens, and then I can make a new persistent store coordinator and add the stores again with the proper Configuration string arguments.
This is the second configuration related bug I've run into. Not a well tested feature apparently.
I had the same problem. The fact pattern was identical and the error message the same. It turned out, however, to be the result of my own mistake.
Let's say the old model was Blah.xcdatamodel and the new Blah 2.xcdatamodel. I had started making changes to Blah before realising my mistake and creating Blah 2. I then used my version control system (Git) to revert to the old Blah and then recreated Blah 2. Everything looked right. But I must have done something wrong in the reversion process, because when I thought to double check that Blah.xcdatamodel in my current project folder was really the same as Blah.xcdatamodel in the project folder I used to build the previous version of the app (fortunately I always keep a zipped archive of the project folder for each released version as I don't fully trust version control systems), I found that they were in fact different, albeit that they looked identical in XCode. The file size was different, for instance.
I substituted the old Blah into my current project folder, and lo and behold it all went perfectly, without any need for the workaround described by Ken.
I am not saying that Ken had necessarily made a similar mistake, but if you do encounter this message it is at least worth confirming that the model you are migrating from is REALLY the model that was used to create the data in question.