I am using version 14.0.3811.1 of SqlPackage.exe
I am attempting to extract a database, without its User / Role and Role memberships.
I am specifying the properties as per below:
SqlPackage.exe /Action:Extract /SourceDatabaseName:"Foo" /SourceServerName:"foo\bar" /TargetFile:"C:\temp\Extracted\foo.dacpac" /p:ExtractAllTableData=True /p:DacApplicationName=foo.bar /p:DacMajorVersion=1 /p:DacMinorVersion=0 /p:VerifyExtraction=False /p:ExtractApplicationScopedObjectsOnly=True /p:IgnorePermissions=True /p:IgnoreUserLoginMappings=True
However if I inspect the model.xml file in the extracted dacpac file, it has various:
<Element Type="SqlRoleMembership">
<Element Type="SqlRole" Name="[Foo]">
<Element Type="SqlUser" Name="[foo]">
<Element Type="SqlLogin" Name="[foo\bar]" Disambiguator="4">
Shouldn't the p:IgnoreUserLoginMappings=true /p:IgnorePermissions=True and /p:ExtractApplicationScopedObjectsOnly=True arguments prevent this?
I found a workaround.
When publishing the .dacpac file containing these Users / Roles etc, you can use the /p:ExcludeObjectTypes= argument to exclude the necessary object types from the deployment.
Related
I need to enabled files with same name in same folder in Alfresco.
I try to create custom association, but I can't see the files in Share (bellow you can see my custom type code).
I can solve this changing the properties duplicate for true on contentModel.xml, but this type of global change is not recommended.
Any idea when I can enable duplicate files in Alfresco? Is correct create another type and define custom association for this OR do I really have to change the global file in contentModel.xml?
<type name="acme:project">
<title>Project folder</title>
<parent>cm:folder</parent>
<associations>
<child-association name="acme:contains">
<source>
<mandatory>false</mandatory>
<many>true</many>
</source>
<target>
<class>acme:document</class>
<mandatory>false</mandatory>
<many>true</many>
</target>
<duplicate>true</duplicate>
<propagateTimestamps>false</propagateTimestamps>
</child-association>
</associations>
</type>
*PS: Sorry for my English.
You can't configure this. Uniqueness on the filename in a directory is also enforced by a unique constraint directly in the database. You would break a lot of funktionallity if you change that. Alfresco implements the fileserver concepts and a fileserver only supports one file with the same path. Use your custom property instead.
I don't have your use case, so my proposition may be unsatisfying, but :
if you want to see your document in Share, it might be possible to custom your share interface to show another property than the document name, a property on which you can have the same value for nodes in the same folder.
Another proposition would be to categorise your documents and use the classification plan you made (with hierarchical categories instead of folder organisation) to access to your documents.
I’m creating a new add-on that will include some user preferences.
Let’s say each user can select multiple categories from a list of all content categories.
My goals are:
the users preferences must be persistent (maybe OK to have them still here if I reinstall the add-on)
the register and personal preferences pages to remain the same. I will have a custom view - form to update the preferences related to this add-on.
easy to index the values in a custom catalog. The catalog will be used to search users interested in a subject (Example: my_custom_catalog.query(subject=“Education”) -> list of brains containing users data subscribed to “Education” topic). The catalog is removed on uninstall and updated when a user changes his preferences.
Can you recommend the best way to store this data? Can I use memberdata without changes in register and personal default forms? Or better to use persistent objects (import persistent)? (Any example very appreciated.)
In profiles/default/memberdata_properties.xml:
<?xml version="1.0"?>
<object name="portal_memberdata">
<property name="custom_topics" type="lines"></property>
</object>
You will create an upgrade step to import memberdata-properties.
Then use:
user = api.user.get(user_id)
user.getProperty("custom_topics")
to get the values and
user.setMemberProperties({'custom_topics':list_of_selected_topics})
to update them.
These values remain stored when the catalog is removed / add-on is uninstalled.
Also no changes in register page and personal preferences form, only if you want to (by extending them).
In Alfresco, if a type name is removed/changed all nodes of that type will disappears but still exists.
Using alfresco 5.0.c I've added some custom types:
eg:
<type name="my:test">
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
now i deploy it and create a folder of this type (a simple folder, then change type)
Now i edit the type like this:
<type name="my:test2"> <!-- from my:test to my:test2 -->
<title>Test folder</title>
<parent>cm:folder</parent>
</type>
Deploying this: any "my:test" folder will disappear, but, if I try to create another folder with the same name I get an error becouse the node still exists.
These nodes will not be not even listed within the folder child:
print(document.getChildren());
How can I recover (if possible using the the javascript console) all the "broken" nodes and be able to change the type?
A little preface: as widely stated by Alfresco, if you want to change your custom content model you should change it only incrementally.
This means that you can't remove any properties, types or aspect at definition level of the model, you only can add new definitions in the content model of Alfresco.
So it is a very bad practice to change types "on the fly".
A good practice is to always start with a model as small as you can and then add features as long as you need them.
In your case you should have deleted all nodes referencing my:test type BEFORE changing the model and then safely remove it and finally you should have performed a full reindex. This could be the reason why the repository tells you that the folder exists even if you cannot see it anymore.
As far as I know it is not possible to delete this inconsistent nodes through the console, so my advice is to perform a full reindex. If the issues come up again then you should consider to start again from scratch.
Another approach next time is to add the new type and programmatically hide the older one.
I am trying to configure cd_storage and getting issue in setting up dynamic component presentation as they get over written by child and published to same folder from every publication.
I know we can define the publication level settings but once we define that then it expect us to define everything inside that publication tag. We do not want to define every thing 50 times in publication tag.
Could any one suggest the best practice for same.
this is for sdl tridion 2011 sp1
Thanks in advance...
Your problem is in how you defined your storage configuration for the storage which you use to store ComponentPresentations. There is a flag in the definition of a storage which sets exactly this type of behavior: defaultFilesystem. You probably have it set to false which causes all ComponentPresentations from all publications to be stored in the same location. By setting this flag to true you will get ComponentPresentations from different publications stored in different locations. I will give an example to show how this works in cd_storage_conf.xml:
<Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" Id="defaultCPs" defaultFilesystem="true">
<Root Path="c:\temp\cpRoot" />
</Storage>
....
<ItemTypes defaultStorageId="defaultFile" cached="true">
<Item typeMapping="ComponentPresentation" itemExtension=".jsp" storageId="defaultCPs"/>
....
This is really easy to maintain and will make the Broker to store ComponentPresentations to locations like: c:\temp\cpRoot\pub109\dcp\jsp\*** (here I have publicationId=109).
Hope this helps.
I have created a configuration section designer project to represent nodes of a custom section necessary to read and save from my web application. I am able to successfully create instances of the configuration elements and collections, however when I save the configuration using the referenced System.Configuration.Configuration object and issuing save, the elements get merged into their parents as attributes. An example of the issue is outlined below:
After calling the referenced Configuration.save, the output is as follows:
<savedReports xmlns="SavedReportSchema.xsd">
<resultsSets dataViewId="1" id="4203bb88-b0c4-4d57-8708-18e48f0a1d2d">
<selects keyId="1" sortOrder="1" />
</resultsSets>
</savedReports>
As defined in my configuration section designer project (confirmed by the resulting xsd as well) the output should match the following:
<savedReports xmlns="SavedReportSchema.xsd">
<resultsSets>
<savedReport id="1">
<selects>
<select keyId="1" sortOrder="1"/>
</selects>
</savedReport>
</resultsSets>
</savedReports>
Any ideas? The element collection types are set to BasicMapAlternate however when I set them to AddRemoveClearMapAlternate they are not merged but they are prefixed by "add" rather than "select" or "savedReport" causing the validation to be off.
Turns out AddRemoveClearMapAlternate was the option I needed to correct my problem referenced in the question.