I am completely new to CMIS Tech. I am trying to change the Versionable Value to Yes for cmis:document type by using the CMIS Workbench.
The only option which I could find is relevant is to click on Update Type, but if you would refer to the attached image it's currently disabled.
Can anyone please suggest an alternative way to change the Versionable value to Yes ?
enter image description here
If the "Update Type" button is disabled the repository does not support updating types via CMIS, or does not allow updating this type, or does not allow you to update types.
In any case, you have to refer to the documentation of your repository how to change type definitions via a native interface or UI.
The versionable attribute is special, though. If the repository does not support versioning or does not support versioning for this base type you will not be able to change this at all.
Related
Facing with strange behavior of the FileNet Choice Lists when they are being returned through CMIS.
There are
IntList in FEM:
and IntList_Test
first one is bound to both MultiInteger and MultiSelectedInteger property templates
There is a Document Class called "Multi" that contains those property templates with correct choice list (IntList):
Despite this fact CMIS Workbench shows incorrect choices for MultiSelectedInteger:
and correct ones for MultiInteger:
So, i can't understand why. It seems that there's some invisible connection between MultiSelectedInteger and IntList_Test. Moreover, working via WSI\EJB connection there's no such problems.
Probably there's some bug at CMIS navigator "Proxy" (.war deployment) side.
Also it's ok when i put values from IntList and it argues when i try to put value from offered choice list (IntList_Test):
Any help is appreciated.
I am new to Hybris and was following the Commerce trail given in Hybris wiki. I can see that they perform "Update" under "Platform" tag. What does this operation do ?
From the above link. for people who do not have wiki access or if page moves.
Update
During an update, type system definitions are modified to match the new type system definition in the items.xml files.
First and foremost, the update mechanism makes sure that all data that existed in the system before the update is still accessible after the update.
Therefore:
•Update preserves the table name, to which a type was mapped, even if it was changed in items.xml
•Update preserves the column name, to which an attribute was mapped, even if it was changed in items.xml
•Update preserves the column type for an attribute, even if it was changed in items.xml
•Update does not drop any tables and columns
•Update does not delete any item data, including type instances and type system data (composed types etc.)
•Update drops and recreate indices, if they are added or changed in items.xml
•Update does NOT change the attribute from optional to mandatory, even if it was changed in items.xml
This is what the process looks like:
1.The type system definitions from all extensions items.xml files are read in.
2.The hybris Commerce Suite type system in the database is modified according to the type definitions of all extensions items.xml files.
A. Adding newly defined types to the type system definition in the database.
Type definitions and attribute definitions that are not part of the type system definition in the database are added.
B. Modifying existing types to match the type system definition in the database.
Type definitions and attribute definitions that are changed compared to the type system definition in the database are modified.
C. Again, like in the init process, the old update logic (prior to hybris Commerce Suite 5.1) iterates through extensions and uses extension manager methods to create and modify types. Whereas, in the new update (since hybris Commerce Suite 5.1), ddl and dml scripts are also generated here.
D. Update then continues with creating essential and project data, optionally, if selected.
As you have access to the hybris wiki you should check the following URL: https://wiki.hybris.com/display/release5/Initializing+and+Updating+the+hybris+Commerce+Suite
Here you will find everything about the initialize and update functionality in the hAC of hybris.
I want to fill the specified property on create a document. Server will have to calculate another properties and forget about original value.
Have read 1.1 (latest) specification, but didn't find any mentions about the issue.
Is it possible to add a custom control to the Document Type? Suppose i couldn't create a multiselect or just a simple textfield control. How could i create a custom one and use that from the Document Type page in Umbraco?
If this is possible, then what steps need to be taken? Because i can add all sorts of config information in the Document Type controls that currently exist in there. Like, when i add a textfield i can gvie it a name, an alias and a validation message (and it has some others options).
Do i have to build the custom Document Type control in a specific way? And how is it saved to the database? How does Umbraco handle that?
Any information on this matter is more than welcome!
Since adding custom document types is native to Umbraco, and judging by the description in your question, I'm going to assume that you are talking about adding custom data types with user controls.
If so, check some of the following links on the subject, it's actually fairly simple:
Creating custom datatypes using the umbraco usercontrol wrapper (I personally used this one)
Custom DataTypes in Umbraco
Creating a custom datatype using the usercontrol wrapper (Video tutorial)
When beginning to develop against SharePoint I did not fully understand all the ins and outs initially. I created a list definition (for a document library) and associated various custom actions to it. Unfortunately, I used the following for the list definition itself:
<ListTemplate...
...
Type="101"
...
And to register the CustomActions against the list:
<CustomAction...
...
RegistrationType="List"
RegistrationId="101"
...
Of course, this means that the custom actions are visible for all document libraries where the feature is activated which is undesirable behaviour. Also, there are lots of these document libraries that have been created from the above list definition in production.
What is the best way to fix this problem? My assumption is that I somehow need to change the "Type" attribute of the already existing lists, but I do not know how to do that. Can it be done via some direct SQL manipulation perhaps? Or is there a better way?
Note: I can see that the AllLists table has a column tp_ServerTemplate, is that the right thing to change?
Modifying the SharePoint database is completely unsupported by Microsoft. Please do not do this on production!
Another option is to create a content type and associate the custom action with that. You may need to write a simple console application to iterate through your existing document libraries and add the content type so it is available for use. The existing documents that you'd like the custom action to apply to would need their content types changed as well.
From some quick initial testing it does look like changing the AllLists table does the trick.
So steps to resolve:
1) Change List Definition Type attribute to be a unique value (for example 11000)
2) Change the CustomAction RegistrationId attributes to be the same (11000)
3) Update the tp_servertemplate column in the AllLists table to be the new template Type (11000) for all the relevant lists.