I'm trying to populate a smartgwt calendar using data form a server obtained using a datasource. Unfortunately the examples in showcase only use client only test data, where one has to create an array of calendar events first. Can anyone give an example of how to do this directly from a rest datastore for example.
Thanks.
Yes, I had trouble tracking down an example too. I eventually figured it out by looking at the samples. It seems like the Calendar doesn't care about the type of the objects used by the datasource, but rather that they provide properties of name, startDate, endDate, and description. (Note that startDate and endDate should be defined as "datetime" in your ds.xml, or all of the events will be full-day events.) Here an example ds.xml (based on the sample for Google App Engine modified with a calendar object):
<DataSource
ID="Appointment_DataSource"
serverConstructor="com.isomorphic.jpa.GAEJPADataSource"
beanClassName="com.smartgwt.sample.server.Appointment"
>
<fields>
<field name="eventID" type="text" hidden="true" primaryKey="true" />
<field name="name" type="text" title="Name" required="true" />
<field name="startDate" type="datetime" title="Start Date" required="true" />
<field name="endDate" type="datetime" title="End Date" required="true" />
<field name="description" type="text" title="Description" />
</fields>
</DataSource>
Related
I am trying to import data from Document DB to solr-5.4.1.
Full import is executing properly but delta import is not working. When I execute delta import nothing happens
Here is the current delta configuration
deltaQuery="{'lastUpdatedDate':{$exists:true},'lastUpdatedDate':{$gt: Date('${dih.last_index_time}')}}"
deltaImportQuery="{'_id':'${dih.delta._id}'}">
whole db-data-config.xml
<dataConfig>
<propertyWriter dateFormat="yyyy-MM-dd'T'HH:mm:ss.SSSXXX" type="SimplePropertiesWriter" filename="dataimport.properties"/>
<document name="tvTitleSearch">
<entity name="tvTitleSearch"
processor="MongoEntityProcessor"
query=""
collection="tvTitleSearch"
datasource="MyMongo"
transformer="MongoMapperTransformer"
deltaQuery="{'lastUpdatedDate':{$exists:true},'lastUpdatedDate':{$gt: Date('${dih.last_index_time}')}}"
deltaImportQuery="{'_id':'${dih.delta._id}'}">
<field name="id" column="_id" indexed="true" type="uuid" stored="true" mongoField="_id"/>
<field column="lastUpdatedDate" sourceColName="lastUpdatedDate" dateTimeFormat="yyyy-MM-dd'T'HH:mm:ss.SSSXXX" locale="en"/>
</entity>
</document>
</dataConfig>
sample from managed-schema file
<field type="date" name="modifiedDate" indexed="true" stored="true"/>
<field type="date" name="lastUpdatedDate" indexed="true" stored="true"/>
the value stored in DocumentDB:
lastUpdatedDate:2019-11-24T11:43:46.045+00:00
I tried to follow the date-time format as stored in DocumentDB, but still, it did not work, also, I tried suggestions from other similar question asked here but no luck. I tried below snippet in delta query
{lastUpdatedDate : {$gt: ISODate('${dih.last_index_time}')}} , but I got JSON Prasing Excpetion
but got below Exception
java.lang.RuntimeException: org.apache.solr.handler.dataimport.DataImportHandlerException: com.mongodb.util.JSONParseException:
{'lastUpdatedDate':{$exists:true},'lastUpdatedDate':{$gt: ISODate('2019-11-20T13:14:30.576-08:00')}}
I tried following configuration too
deltaQuery="{'lastUpdatedDate':{$exists:true},'lastUpdatedDate':{$gt:
{$date:'${dih.last_index_time}'}}}"
could someone please help me or provide any suggestions to trigger delta query
The correct way to use the deltaQuery is
deltaQuery="{'lastUpdatedDate':{$exists:true},'lastUpdatedDate':{$gt: {$date:'2020-03-13T08:44:06.959Z'}}}"
as you can see here
However, the SOLR will use ${dih.last_index_time} that is by default formated as 2020-03-13 08:44:06. You'll need to change the format by adding something like the following setting inside your <dateConfig> element.
<propertyWriter dateFormat="yyyy-MM-dd'T'HH:mm:ss.SSSXXX" type="SimplePropertiesWriter" filename="my_dih.properties" locale="en-US" />
When you create a work item such as Bug in Azure devops, the values that you would see in the drop down of say Reason field would depend on the value you select for State field. For e.g. see these screenshots (Template Agile, no customizations)
Then if you change the state, the allowed values change as shown
To make matters more confusing, these are just few of the values that are returned by the documented REST API
The given API returns
"defaultValue": null,
"allowedValues": [
"Verified",
"Not fixed",
"Test Failed",
"As Designed",
"Cannot Reproduce",
"Copied to Backlog",
"Deferred",
"Duplicate",
"Fixed and verified",
"Obsolete",
"Fixed",
"Investigation Complete",
"Approved",
"Investigate",
"Resolved in error",
"Reactivated",
"Regression",
"Build Failure",
"New"
],
"helpText": "The reason why the bug is in the current state",
"alwaysRequired": false,
"dependentFields": [
{
"referenceName": "System.State",
"name": "State",
"url": "https://dev.azure.com/nikhil/_apis/wit/fields/System.State"
},
{
"referenceName": "Microsoft.VSTS.Common.ResolvedReason",
"name": "Resolved Reason",
"url": "https://dev.azure.com/nikhil/_apis/wit/fields/Microsoft.VSTS.Common.ResolvedReason"
}
],
"referenceName": "System.Reason",
"name": "Reason",
"url": "https://dev.azure.com/{project}/{templateid}/_apis/wit/fields/System.Reason"
},
I am trying to figure out the right API or set of APIs that help demystify when to show what in the combo boxes, when to mark them read-only and when to let the user edit them.
The Resolved Reason Field is further interesting. For most parts it seems to simply copy the value from the Reason field, however the Rules API (see below) does not indicate this behaviour. It looks like what the Rules API returns does not match the behaviour that this field exhibits.
There is a concept of Rules mentioned in the REST API here - https://learn.microsoft.com/en-us/rest/api/azure/devops/processes/rules/get?view=azure-devops-rest-5.1#processrule
However this does not seem to give rules which specifically control "allowedValues" for fields based on value of another field as I explained above.
Question:
Is there an API that can give a comprehensive set of rules for fields on a work item types including their allowedValues? For e.g. the Reason or Resolved Reason field depending on the choice of State field as shown above?
Is there an API that can give a comprehensive set of rules for fields
on a work item types including their allowedValues? For e.g. the
Reason or Resolved Reason field depending on the choice of State field
as shown above?
First of all, I need to say, no, there is no such REST API to get the Reason value which depending on the State filed chosen. Since these are all not be documented, the best way for us to verify it is using the Fiddler trace(Fiddler can record all internet data between web application and internet).
[As example, here I will use Bug work item to show that.]
First, clear all the records in Fiddler => open the Bug work item in Azure Devops => press F12 in Fiddler to start record the data.
Change the work item state in Azure Devops(Note: just change, do not save it. "Save" belong to another operation). Then go Fiddler to see its internet records:
You will see that there only 2 event API, and these API are only used to post the action sign but not operate it. See the request body of first POST Event API:
You can see that it just used to post a sign about the State field has changed. That's why I say that there's no API to get the Reason value which depending on the State filed chosen, because our develop team did not use the script with API to achieve that.
Now, you should be very confusing that who is this action message to be sent to? Since the Reason field value listed is not controlled by the api, then who is in control?
The answer is XML process template.
In Azure Devops, the WIT are all controlled by XML template. You can find all rules such as the Reason field value listed depend on the State field changed, copy the value from the Reason field and etc.
I have uploaded the Bug.xml of process template into my github, you can refer to that code to analysis it: Agile-process/Bug.xml .
For the Reason field value listed depend on the State field
changed.
<FIELD name="Resolved Reason" refname="Microsoft.VSTS.Common.ResolvedReason" type="String" reportable="dimension">
<ALLOWEDVALUES>
<LISTITEM value="As Designed" />
<LISTITEM value="Cannot Reproduce" />
<LISTITEM value="Deferred" />
<LISTITEM value="Duplicate" />
<LISTITEM value="Fixed" />
<LISTITEM value="Fixed and verified" />
<LISTITEM value="Obsolete" />
<LISTITEM value="Copied to Backlog" />
</ALLOWEDVALUES>
<HELPTEXT>The reason why the bug was resolved</HELPTEXT>
</FIELD>
These are the xml code which control the Resolved Reason listed. I believe that you have got its logic. The message of event API we got from fiddler are get by the relevant WIT *.xml. Then the corresponding operation will be trigger and acted.
For copy the value from the Reason field.
<TRANSITION from="New" to="Resolved">
<ACTIONS>
<ACTION value="Microsoft.VSTS.Actions.Checkin" />
</ACTIONS>
<REASONS>
<DEFAULTREASON value="Fixed">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Fixed" />
<ALLOWEDVALUES>
<LISTITEM value="Fixed" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</DEFAULTREASON>
<REASON value="Deferred">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Deferred" />
<ALLOWEDVALUES>
<LISTITEM value="Deferred" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Duplicate">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Duplicate" />
<ALLOWEDVALUES>
<LISTITEM value="Duplicate" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="As Designed">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="As Designed" />
<ALLOWEDVALUES>
<LISTITEM value="As Designed" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Cannot Reproduce">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Cannot Reproduce" />
<ALLOWEDVALUES>
<LISTITEM value="Cannot Reproduce" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Obsolete">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Obsolete" />
<ALLOWEDVALUES>
<LISTITEM value="Obsolete" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
<REASON value="Copied to Backlog">
<FIELDS>
<FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
<COPY from="value" value="Copied to Backlog" />
<ALLOWEDVALUES>
<LISTITEM value="Copied to Backlog" />
</ALLOWEDVALUES>
</FIELD>
</FIELDS>
</REASON>
</REASONS>
<FIELDS>
<FIELD refname="System.AssignedTo">
<COPY from="field" field="System.CreatedBy" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
<COPY from="currentuser" />
<VALIDUSER />
<REQUIRED />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
<COPY from="currentuser" />
<VALIDUSER />
<REQUIRED />
</FIELD>
<FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
<SERVERDEFAULT from="clock" />
</FIELD>
</FIELDS>
</TRANSITION>
This just a short section which about the copy value from the Reason field from the xml file of Bug work item.
In fact, you can find all process rules from these XML file which could not get with API(Note: I just mean the default process rule). If you want, I can share the completed XML files of process in my github.
Hope this could help you more clearly:-)
Is there an API that can give a comprehensive set of rules for fields
on a work item types including the allowedValues of say Reason field
depending on the choice of State field?
For this issue , you can use Rules - List api to get it .
GET https://dev.azure.com/{organization}/_apis/work/processes/{processId}/workItemTypes/{witRefName}/rules?api-version=5.1-preview.2
I test with postman , the figure below is the result returned by my test.
By searching for keywords, we can get the rules of allowed values for Reason field depending on the choice of State field.
The processId parameter required in the api can be obtained through this rest api.
Hope this helps.
Although I've developed some services with Liferay ServiceBuilder, I'm not quite sure I understand the point of using the attributes:
userId
companyId
groupId
Note that these attributes are available through the PortalRequest.
Following the basic tutorials, you are instructed to create these attributes for every entity, and take care to set them on 'add' functions. But thinking of it, I've not ever seen any tutorial or referenced code where these attributes are used on data retrieval (Finder methods, dynamic queries, or custom queries either)
So what's the point on keeping this information ?
Are these attributes used automatically somehow under some convention or scope ? Something like, the Liferay's default Finders using them when they are available through the PortalRequest ?
Or is it up to the developer to use them on every Select, E.g. are all the single-parameter Finders practically useless on multi-instance Portals (since the companyId attribute should be used on every Finder method) ?
Or is it just a good practice to keep this structure for database extendability, auditing, indexing or something else I'm totally missing ?
These attributes are necessary when you use your entities for example on staging environment. The groupId specifies to which environment the entity belongs to. Meaning of userId is obvious and as for companyId it is the site identifier. So IMHO these attributes are quite important when you have multiple sites on one portal, when you have staging env. enabled etc..
Suppose you have a new table and you want to set UserId in your table then it is necessary but otherwise I don't think these attributes are neccessary.
I have created service builder
<entity name="FaoEsalesCustomer" local-service="true" remote-service="false" table="fao_esalecustomer">
<!-- PK fields -->
<column name="esaleCustomerId" type="long" primary="true" />
<!-- Audit fields -->
<column name="createdBy" type="long" />
<column name="createdOn" type="Date" />
<column name="modifiedBy" type="long" />
<column name="modifiedOn" type="Date" />
<!-- Other fields -->
<column name="customerName" type="String" />
<column name="address" type="String" />
<column name="ph" type="Integer" />
<column name="categoryId" type="long" />
<column name="categoryName" type="String" />
<column name="quantity" type="Double" />
<column name="price" type="Double" />
</entity>
I need to add/modify fields in the FIX4.4 dictionary. I haven't found any helpful documentation or tutorials on this.
I'm guessing I have to modify the FIX44.xml file, but I'm not sure how exactly to do that.
In the <message></message> tags I don't see any attributes that define the number or the type(format) of that field. I see just the name and required attributes.
I think I found attributes I', looking for in the <fields></fields> tags.
I'm not sure if I'm looking in the right place or if I'm doing the right thing, but according to this I should modify the dictionary if it is necessary.
Please help.
A link to a tutorial for beginners that can help me would also be greatly appreciated.
The FIX Data Dictionary in QuickFIX contains Messages and Fields (among other things).
To add Messages you must add the message between the <messages></messages> tags like this:
<message name="CoolMessage" msgcat="app" msgtype="xCM">
<field name="Currency" required="N"/>
<field name="Text" required="N"/>
<field name="Account" required="Y"/>
</message>
And then add the new msgtype to the MsgType field in the <fields></fields> section like this:
<field number='35' name='MsgType' type='STRING'>
...
<value enum='xCM' description='COOLMESSAGE'/>
</field>
If you want to add new fields, just add them between the <fields></fields> tags like this:
<fields>
<field number="1" name="Account" type="STRING"/>
<field number="2" name="AdvId" type="STRING"/>
<field number="3" name="AdvRefID" type="STRING"/>
...
<field number="9006" name="AwesomeField" type="STRING"/>
</fields>
This and more information can be found in this tutorial.
I am trying to show all attachments (from the current page) in an auto-completed drop-down list. This is the part in the atlassian-plugin.xml which defines the parameters:
<xhtml-macro name="plugin-name" class="com.example.macro.name" key="macroname-xhtml" icon="/download/resources/${project.groupId}.${project.artifactId}/icons/macroname.png">
<category name="formatting"/>
<parameters>
<parameter name="content_input" type="confluence-content" />
<parameter name="space_input" type="spacekey" />
<parameter name="attachment_input" type="attachment" />
</parameters>
</xhtml-macro>
The confluence-content and spacekey types work just fine. It shows a textfield which autocompletes Pages and Spaces.
However, the attachment type shows a empty drop-down list (select box) which cannot auto-complete.
The official Confluence documentation says it should work like I do:
https://developer.atlassian.com/display/CONFDEV/Including+Information+in+your+Macro+for+the+Macro+Browser
I must be missing something here, but I don't know what. Anyone might know what the problem is?
If you want a drop-down list with all the attachments then you may also try the following:
<xhtml-macro name="plugin-name" class="com.example.macro.name" key="macroname-xhtml" icon="/download/resources/${project.groupId}.${project.artifactId}/icons/macroname.png">
<category name="confluence-content" />
<parameters>
<parameter name="page" type="confluence-content" required="false"
multiple="false" />
<parameter name="name" type="attachment" required="false" />
</parameters>
</xhtml-macro>
Don't change the names of the parameters
If you want to add a filter, then you need the following:
<web-resource key="macro-browser-smart-fields" name="Macro Browser Smart Fields">
<resource type="download" name="confluence-core-macro-fields.js" location="js/confluence-core-macro-fields.js" />
<dependency>confluence.editor.actions:editor-macro-browser</dependency>
<context>macro-browser</context>
</web-resource>
confluence-core-macro-fields.js
(function($) {
AJS.MacroBrowser.activateSmartFieldsAttachmentsOnPage("plugin-name", [ "png", "jpg", "gif" ]);
})(AJS.$);
I found that setting the type as attachment (following official documentation) is bugged. I have found a work-around to display attachments in a auto-complete box.
<parameter name="xsd" type="confluence-content" required="true">
<option key="type" value="attachment"/>
<option key="showKeyInPlaceholder" value="false" />
<option key="showValueInPlaceholder" value="true" />
</parameter>