I have this weird situation where I am trying to import a component (which is a shared item from parent publication) from prod environment to dev environment.
Situation:
Prod: In child publication - component is shared and has title as "prodcut_details"
Dev: In child publication - Component is a Local Item and has title as "prodcut_details"
While Import in progress, I get the following error:
Tridion.ContentManager.UniquenessException: Name must be unique for items of type: Component within this Folder and its BluePrint context. Source or sources of conflict: tcm:12-1234.
Can anyone help here ?
This is standard Tridion behaviour. The Content Porter will try to create a shared item within the child publication on the DEV environment and then it finds an item with the same name and it will throw the uniqueness exception.
You could just rename the local item on dev and then run the import.
Did you know there's a separate Tridion stack exchange?
You'll have more luck asking questions over there...
Related
I am using Polymerfire library and a native javascript API in my project and I need to set up the production environment. I searched through multiple posts (for example this one) and I came to a conclusion that I need to create a separate project. However since I am using Polymerfire library I have my app name specified all over the project.
<firebase-auth id="auth" user="{{user}}" app-name="project-name" provider="password"
signed-in="{{signedIn}}"></firebase-auth>
To deploy in production it is required to change this name everywhere. I was thinking that I could create a computeAppName function which would return the app name according to the environment but I hope there is a better solution.
The same issue doesn't occur when I use the native javascript API because I am simply selecting the first app in the array (I'll never use multiple apps in my project).
Example
var actionCode = this.route.__queryParams["oobCode"],
auth = firebase.apps[0].auth();
In my opinion ideal, behavior would be if Polymerfire library automatically selected the only existing app in firebase.apps array. If that would be the case I could initialize one firebase-app element with app name in index.html and leave the app name unspecified deeper in the DOM tree.
This issue would be eliminated if I stopped using the Polymerfire library entirely but that would not follow the "Polymer way" of doing things.
Another option would be to create a task in a build system (like gulp) to replace the app name for production but that would be probably overly complicated.
What do you think?
Edit:
For now I am using a workaround:
firebase-app element in index.html:
<firebase-app id="main_app"
name="project-id"
api-key="key"
auth-domain="project-id.firebaseapp.com"
database-url="https://project-id.firebaseio.com"
storage-bucket="project-id.appspot.com">
</firebase-app>
In every element where Polymerfire is used I created a appName property which uses document selector to get the app name from element in the index:
appName: {
type: String,
value: function () {
return document.getElementById("main_app").name;
}
}
<firebase-auth id="auth" user="{{user}}" app-name="[[appName]]" provider="password"
signed-in="{{signedIn}}"></firebase-auth>
Thanks Jan
Name property of firebase-app element is only used as a name for the firebase app object, which can be arbitrary and there is no need to change it when switching to production project.
I'm following the A-Frame Building with Components tutorial.
First, there is a typo around the Layout Component part:
layout="layout: line;
should be:
layout="type: line;
Secondly, I've got to the Event-Set Component part. Unfortunately, I'm getting the following errors:
core:schema:warn Unknown property `src` for component/system `undefined`
and
Error: Trying to initialize multiple components of type `event-set`. There can only be one component of this type per entity.
The first seems to link to an innocous part of my Browserified code and second is particularly ironic as the tutorial itself states:
Notice that the event-set component can have multiple instances
The code itself is on my GitHub for the project, and can be seen running via GitHub pages here. I would have linked to more pages and my GitHub, but I can only place two links in this post with my newbie status.
You need a more current version of the component. You can grab it from https://github.com/ngokevin/kframe/tree/master/components/event-set/dist
I'm creating a list of permission settings for an OrganizationalItemData object with the Core Service and am looking for help confirming when to explicitly set permissions in the CME.
Question
Given an organizational item and knowing its shared, localized, and permissions inheritance settings, when do we need to explicitly set permissions for it (in the CME under Properties > Security)?
API Details
Given OrganizationalItemData orgItem I can check the following (with details from the documentation).
IsShared
Gets or sets whether the item is shared in the current context Publication.
IsLocalized
Gets or sets whether the item is localized in the current context Publication.
IsPermissionsInheritanceRoot
true if permissions are specified for item itself; otherwise, false, if item inherits permissions from the parent item.
Example Code
I can use the Core Service to check permission settings in a given CMS. For example:
var CreatedHere = !orgItem.BluePrintInfo.IsShared.GetValueOrDefault();
var IsLocalized = orgItem.BluePrintInfo.IsLocalized.GetValueOrDefault();
var PermissionsFromParent = !orgItem.IsPermissionsInheritanceRoot.GetValueOrDefault();
I'd like to output the permissions for a given Organizational Item, but also instructions for when the CMS administrator actually needs to set properties in its publication. For example I could use a script against CMS Test to show what CMS Production might need.
Scenarios
Here's the truth of it (I think).
Shared Local(ized) PermissionsRoot Set here?
No No No No, set in parent in this Publication.
No No Yes Yes, set in this "local" item.
No Yes No Not possible. Can't localize non-shared item.
No Yes Yes Not possible. Can't localize non-shared item.
Yes No No No, set in parent item in higher Publication.
Yes No Yes No, set in this item but in a higher publication.
Yes Yes No No, set in parent item in this Publication.
Yes Yes Yes Yes
I might be wrong in my understanding of these options, but so far it seems we only need to explicitly set permissions for two scenarios:
For a non-shared (local) item that is a permissions root (Inherit Security Settings from Parent unchecked)
For a shared, localized item that is a permissions root.
Do I have the right scenarios and/or am I missing something in the 2^3 scenarios above?
I think you have it about right Alvin.
First of all, the only place you can ever have permissions is at an inheritance root.
Secondly, normal blueprinting rules apply.
I used to draw this as a diagram with a zig-zag arrow, showing the search for permissions:
(Imagine you're a folder trying to figure out stuff)
Am I a local inheritance root? No - keep on looking
OK - so BluePrinting applies, so maybe I'm a shared folder and I'm an inheritance root via bluePrinting? Nope? OK - keep on looking,
So what about that folder above me in the tree? Are there any permissions there? Is it a local inheritance root? Is it an inheritance root by way of BluePrinting? Nope - keep on looking
And so on all the way to the top
So looking at your table: Anything where "Permissions root" is false, can't have it's own permissions, so correctly you have either no or not possible for each of these.
For org items that are inheritance roots, the next question is are they local/localized or are they shared. Again you seem to have got this correct.
There's only one point of attention that I'd mention, and that is that perhaps "Localized" is the wrong name for your second column. I'd say "local" instead. An item is local if it is not shared, and this can be because it's been localised from a shared item in another publication, or because it's been created locally in this publication. I think you realise that any scripted or programmed approach you take needs to accommodate both scenarios.
I was going through Unity 2.0 to check if it has an effective use in our new application. My application is a Windows Forms application and uses a traditional bar menu (at the top), currently.
My UIs (Windows Forms) more or less support Dependency Injection pattern since they all work with a class (Presentation Model Class) supplied to them via the constructor. The form then binds to the properties of the supplied P Model class and calls methods on the P Model class to perform its duties. Pretty simple and straightforward.
How P Model reacts to the UI actions and responds to them by co-ordinating with the Domain Class (Business Logic/Model) is irrelevant here and thus not mentioned.
The object creation sequence to show up one UI from menu then goes like this -
Create Business Model instance
Create Presentation Model instance with Business Model instance passed to P Model constructor.
Create UI instance with Presentation Model instance passed to UI constructor.
My present solution:
To show an UI in the method above from my menu I would have to refer all assemblies (Business, PModel, UI) from my Menu class. Considering I have split the modules into a number of physical assemblies, that would be a dificult task to add references to about 60 different assemblies. Also the approach is not very scalable since I would certainly need to release more modules and with this approach I would have to change the source code every time I release a new module.
So primarily to avoid the reference of so many assemblies from my Menu class (assembly) I did as below -
Stored all the dependency described above in a database table (SQL Server), e.g.
ModuleShortCode | BModelAssembly | BModelFullTypeName | PModelAssembly | PModelFullTypeName | UIAssembly | UIFullTypeName
Now used a static class named "Launcher" with a method "Launch" as below -
Launcher.Launch("Discount");
Launcher.Launch("Customers");
The Launcher internally uses data from the dependency table and uses Activator.CreateInstance() to create each of the objects and uses the instance as constructor parameter to the next object being created, till the UI is built. The UI is then shown as a modal dialog. The code inside Launcher is somewhat like -
Form frm = ResolveForm("Discount");
frm.ShowDialog();`
The ResolveForm does the trick of building the chain of objects.
Can Unity help me here?
Now when I did that I did not have enough information on Unity and now that I have studied Unity I think I have been doing more or less the same thing. So I tried to replace my code with Unity.
However, as soon as I started I hit a block. If I try to resolve UI forms in my Menu as
Form customers = myUnityContainer.Resolve<Customers>();
or
Form customers = myUnityContainer.Resolve(typeof(Customers));
Then either way, I need to refer to my UI assembly from my Menu assembly since the target Type "Customers" need to be known for Unity to resolve it. So I am back to same place since I would have to refer all UI assemblies from the Menu assembly. I understand that with Unity I would have to refer fewer assemblies (only UI assemblies) but those references are needed which defeats my objectives below -
Create the chain of objects dynamically without any assembly reference from Menu assembly. This is to avoid Menu source code changing every time I release a new module. My Menu also is built dynamically from a table.
Be able to supply new modules just by supplying the new assemblies and inserting the new Dependency row in the table by a database patch.
At this stage, I have a feeling that I have to do it the way I was doing, i.e. Activator.CreateInstance() to fulfil all my objectives. I need to verify whether the community thinks the same way as me or have a better suggestion to solve the problem.
The post is really long and I sincerely thank you if you come til this point. Waiting for your valuable suggestions.
Rajarshi
As I can see from this code
Form customers = myUnityContainer.Resolve<Customers>();
all your code need to know about the customer - is that it's a Form class. So if you use xml configuration for unity you can do the following:
<type type="Form" mapTo="Customer" name="Customer">
</type>
And then you'll be able to resolve it like this:
Form customers = myUnityContainer.Resolve<Form>("Customer");
and there is no need to refference your UI assembly. Offcourse it should be presented in the bin directory or GAC. In this case if you'll develop new Assembly - all you need is to change config and put in in bin or gac.
If you want to make unity configuration from db then you'll have to add referrence to your ui, becouse you'll have to call Register("Customer").
When I run my seam application I get the following error
Exception sending context initialized event to listener instance of class org.jboss.seam.servlet.SeamListener
java.lang.IllegalStateException: Two components with the same name and precedence - component name: wizardController, component classes: package.WizardController, package.WizardController
at org.jboss.seam.init.Initialization.addComponentDescriptor(Initialization.java:543)
at org.jboss.seam.init.Initialization.installScannedComponentAndRoles(Initialization.java:809)
at org.jboss.seam.init.Initialization.scanForComponents(Initialization.java:756)
at org.jboss.seam.init.Initialization.init(Initialization.java:629)
at org.jboss.seam.servlet.SeamListener.contextInitialized(SeamListener.java:35)
I am not able to resolve this problem.
Seems like you have two components with the name wizardController. Try searching for wizardController and see if you find any duplicates somewhere.
You define the same component twice. Look if you have forgotten a #Name("componentName") inside your code and the same component definition in components.xml.
Or the same #Name("componentName") in two or more classes (copy-pasted and forgot to change the component name).
Assuming you don't have two classes with the same component name:
This sometimes happens if you have renamed a component and didn't clean out your build/deploy directories. The old .class and the new .class with the same component names will still get deployed.
Clean and re-deploy. That should fix it.
make sure the folder WEB-INF/dev is not exported with WAR file.
Delete them if exists.
regards,
Marcus VinÃcius Bastos de Andrade
try checking your exploded-archives and see if is updated. This usually occurs when you created a class and used #Name annotation having the same name as your other class, but then decided to delete the class. You think its deleted, but it is still in the exploded-archives.