After reading the documentation about the new 4.6 versioning feature and this post In Orbeon Forms, is form version information available in the REST API? I was wondering how the form builder receives the published version number?
In this screenshot from the builder
you see the latest published version has the value 5.
How does the builder receive this value and is it possible to accomplish this via our own CRUD interface?
The publishing part we got covered by handling the HTTP_ORBEON_FORM_DEFINITION_VERSION header field and its' value.
Looks like the python script I used returned the wrong header field.
Anyway the right headerfield both ways is ORBEON-FORM-DEFINITION-VERSION.
So sending this field with the version number results in the right value in the form builder
Related
I want to create a JIRA issue using Logic Apps when a row is inserted into a SharePoint online list. I've authenticated myself, but am getting this error. The main part of the message reads as follows:
Field ‘reporter’ of type ‘user’ is not supported. More diagnostic information: x-ms-client-request-id is ’71…’
The Logic App action is "create a new issue V2". The previous version seems to work OK, but has been deprecated.
The SharePoint list also has some rich text fields. Will I be able to upload them? Looking at the JIRA connector documentation I suspect not, but would like to check.
To resolve this, you need to remove the 'reporter' field from the JIRA Issue Type you are using in the Create a new issue task in Logic Apps.
We have the requirement to fetch an attachment to an Orbeon form from a simple automation script. We found the "List Forms Attachments" API (https://doc.orbeon.com/form-runner/api/persistence/list-form-data-attachments.html) and are trying to call it using a simple "curl" script that runs on the same host as the Orbeon Tomcat instance:
curl -v "http://localhost:8080/orbeon/fr/service/$app/$form/attachments?document=$docid"
This returns an HTTP 403 (Forbidden), and even after reading whatever doc we can find on Orbeon security, we're still scratching our heads over how to configure Orbeon. Is there a simple configuration example showing an Orbeon configuration that would allow the API to be called from a local script like ours? We are running Orbeon CE 2017.1.
If getting this API to work is an ordeal, the other option we'd consider would be a database solution. We have Orbeon running on a MySQL persistence layer, and the same script we're using also has access to this database. Is there an easy way to take a submitted form's XML and fetch the attachment for a given form field?
We see in the submitted form's XML that the attachment tag looks like this:
<File1 filename="Original Filename.doc" mediatype="application/msword" size="14236">
file:/tmp/tomcat7-tomcat7-tmp/xforms_upload_7266596219758922423.tmp?filename=Original+Filename+doc&mediatype=application%2Fmsword&size=14236&mac=fc2febb1227e93643a048fbb02abc16bba346531
</File1>
When we scan the orbeon_form_data_attach database table, we see a row with the file content we expect, but the file_name column doesn't match the file information in the form's XML above...in this example, the file_name on the database is 1af8cd16367470362e13f77e679c0ae590e1f4a5.bin. Some of our forms have multiple attachments, and there doesn't seem to be a direct way to go from the form XML to the file_name in the database table.
Either of these solutions would be fine for us - we just need a way to get the attachments for a form from a simple script.
For reference, the relevant documentation is Authorization of Pages and Services.
You can, although this is not to be done for production but only testing and development, open all services without authentication. See this section. Otherwise, you need to setup an authorization service.
I was hopping to have an easy way to customize the display behavior of the Grails fields plugin after reading its docs, but I just realized that it demands an enormous effort as there is no available templates to start from.
I can see the display functionality is hard-coded in FormFieldsTagLib (from methods like renderDefaultInput() ) but I think it is imperative to have the templates themselves (or a way to generate them, somewhat like generating static scaffolding in Grails).
I can see no consistent (and reasonable) way to customize display behaviors for the Grails fields plugin without that. Am I missing something?
Imagine the use case where someone wants to change the boolean default rendering just to display the field label after (and not before) the checkbox, and keep it available to all the boolean fields within its application. Which concerns will he need to handle regarding if the field is required, has errors, prefix and so on? When all he needed was just moving two divs around.
Grails version: 2.5.4, fields-plugin version: 1.5.1
You aren't missing something. You'd have to re-create the existing implementation of each field type rendering in a template for use with the plugin. There isn't a way to generate a file to start with (like scaffolding).
I won't bore you with the historical reason as to why this is the case, but if you do create a set of base templates it would be a good idea to contribute back to the plugin.
I had an issue with the <f:table> tag, and found this post, which led me to find the base or default template inside the plugin repo.
Take a look at
https://github.com/grails3-plugins/fields/tree/master/grails-app/views
That may help you finding some default templates, along with the official doc and this answer on where to put the override.
Hope it helps you.
I'm using the Jira (version 5) Rest API to Delete a version and like the documentation tell me, I pass the moveFixIssuesTo and moveAffectedIssuesTo to transfer issue from the deleted version to a other version. This just doesn't work. The issues that has AffectedVersion / FixVersion set to the deleted version have no version after the delete.
/rest/api/2/version/{id}?moveFixIssuesTo&moveAffectedIssuesTo
Here an example of the call :
http:// /rest/api/2/version/16238?16237&16237
My {id} is an existing versionId I want to delete.
moveFixIssuesTo and moveAffectedIssuesTo are versionId of the version I want the issues to be transfer.
If I do the same kind of action from the Web UI of Jira ( Deleting a version and setting in the form the version to transfer the AffectedVersion and FixVersion, It work correctly and I see the new version in the field of the issues.
Any idea why this does not work as expected ?
I think if you changed implementation of service operation - you must use another url for this operaton. For this thing you can change value of attribute version in rest tag in the file atlassian-plugin.xml:
<rest name="My Rest Resource" key="custom-rest-resource" path="/my-custom-resource" version="1.0"/>
I'm building a form in the Orbeon Form Builder. The simplest way to recreate this problem is as follows:
Put a control on the form.
Give it any label, it does not matter.
Go to 'control details'.
Change the 'Control Name' to 'test-controlenummer'.
Confirm with the 'apply' button.
See the control itself disappear
Notice that the question mark of the help feature does not disappear, nor do the delete and validation options once you hover over the formerly-visible-component. The grid cell also acts as if it was occupied. The control simply does not show and some of the changes to the name and/or validation options result in XPath expression errors.
I have taken a quick look at the underlying xml code, however at first glance I did not find anything out of the ordinary.
It disappears because of a bug in Orbeon Forms 3.9 when control names contain a dash. Like you said, there is nothing wrong with the markup Form Builder generates, but it then incorrectly just doesn't expect a dash to be present in the control name.
This bug has been fixed in the latest code, so it won't be present in the next release.
If you are using Orbeon Forms PE, I recommend you contact Orbeon to see if you can get a patch for this (either through Basecamp if you already have a support account setup, or by email, info AT orbeon.com).
If you are using Orbeon Forms CE, for now, you can work around this issue by avoiding dashes in the names of your controls.