{5} Assigned, Active Tickets by Owner (Full Description) (43 matches)

As data entry progresses from one field group to another in a nested Wip the data entry operator must use an Insert context menu to select the next field group to move into. Instead the WipViewer should presume the next field group and allow some keystroke to switch to the next candidate (or some similar mechanism).

Furthermore the choices for insert are limited to those that are logically "below" the current field group rather than a fuller set of possible subsequent field groups.

If a "Create new wip" is attempted on a dppool that isn't properly defined in wipsite.xml causes the WipViewer to die quietly with a Null Pointer Exception.

We need a case to reproduce this.

If the jythonlib attribute of the wipsite.xml file is set to the wrong place there is no notification until someone tries to import something from some script. The resulting import error won't ring a bell with a newcomer.

e.g. 'import re' in a script to pick up regular expressions might fail and only appear in the log.

Try to import some passage at startup time and display a first-class warning.

FieldDefs? are copied into the WipSpec as they're needed. All FieldSpecs? of the same FieldDef? object share the same copy of the FieldDef?. When all the FieldSpecs? for a particular FieldDef? are removed the FieldDef? should be removed as well.

WipViewer assumes that the caller has knowledge about SWT's UI thread restriction; see http://www.eclipse.org/swt/faq.php#uithread. If the WipViewer is opened as part of an RPC call, the opening thread is not always the same. This causes an exception in the SWT library when an attempt is made to open the viewer more than once.

Exception in thread "Remote WIP viewer" org.eclipse.swt.SWTException: Invalid thread access
        at org.eclipse.swt.SWT.error(SWT.java:2942)
        at org.eclipse.swt.SWT.error(SWT.java:2865)
        at org.eclipse.swt.SWT.error(SWT.java:2836)
        at org.eclipse.swt.widgets.Widget.error(Widget.java:395)
        at org.eclipse.swt.widgets.Shell.<init>(Shell.java:246)
        at org.eclipse.swt.widgets.Shell.<init>(Shell.java:237)
        at org.eclipse.swt.widgets.Shell.<init>(Shell.java:190)
        at org.eclipse.swt.widgets.Shell.<init>(Shell.java:128)
        at org.workthru.tools.viewers.WipViewer.createContents(WipViewer.java:428)
        at org.workthru.tools.viewers.WipViewer.run(WipViewer.java:930)
        at com.acesis.workflow.Toolbox$1.run(Toolbox.java:64)
        at java.lang.Thread.run(Thread.java:595)

Workarounds:

• Restart the server before opening the second WipViewer
• Always use the same thread when calling WipViewer.run, e.g. using java.util.concurrent.Executors:

        if (null == uiService) {
            uiService = Executors.newFixedThreadPool(1);
        }
        uiService.execute(new Runnable() {
            public void run() {
                wipViewer.run();
            }
        });

However, this prevents having more than one viewer open at the same time.

Aliases allow a mapping of the field group fieldname to the domain field name. This should be removed from the field group spec and added to new metadata associated with the domain. There are multiple reasons for this.

• Wip metadata is supposed to be domain-independent but aliases are definitely domain-dependent
• There are other types of mapping metadata that's needed as well (for example, field group spec name to domain name)

Sometimes a script viewer (e.g. in WipViewer) looses its stdout stream. Suddenly there's no more output from any script. Only recourse is to close and reopen the window.

This:

configfile = ./wipsite.xml

works okay. But this:

configfile = /EclipseSVN/WorkThru/test/org/workthru/bugs/testdata/wipsite.xml

causes:

Configuration file C:\EclipseSVN\WorkThru?\test\org\workthru\bugs\testdata\/EclipseSVN/WorkThru/test/org/workthru/bugs/testdata/wipsite.xml does not exist for FileSiteImpl?

as if absolute-looking configfile was prepended by current path.

The WorkThru? Eclipse plugin currently does not support to add the WorkThru? artifacts to an existing Eclipse Java project. The only options currently available are:

• New WorkThru? Project
  • Basic WorkThru? Project
  • WorkThru? Project structured for Tomcat
  • WorkThru? Project with Samples

It would be very helpful if only the necessary JARs, Python folders & scripts, and optionally the samples could be added to an existing project. I think the necessary components are:

• Folder jythonlib
• Folder scripts
• Folder wippools
• Files localsites.properties, site.properties, WipInit?.py, wipsite.xml, wipsiteTomcat.xml

The PythonScriptAdapter? is only initialized once and held in a static variable, i.e., it is a singleton. However, each site may specify different settings for the <jython> element: different settings for debug, different <lib> elements.

Maybe it is sufficient to have the script adapter as a singleton, but then the <jython> element should be moved from the site configuration asset to a "system-wide/JVM" configuration asset.

Because of ticket:78, I need to remove the default value set for a field. The field contains a string. I removed all characters from the field.

The logic of method Field.setDefaultValue does not detect that there is no longer any default value and therefore removing the default value from the root field group is not a workaround for ticket:78.

The access control configuration element of pools is parsed, but has no effect in Wip.initAlways() unless the Wip spec defines the script "assignroles". The default contents of this script is:

  roles.addAll(user.groups)

If a Wip spec does not define the script, but turns access control on for a pool, no access control is in effect. The default access control state should be determined by the pool configuration. Also, it should not be necessary to define the script unless some dynamic role assignments are desired.

1. Use a FieldGroupSequenceNumber? to create n items then commit. 2. Manually delete the first row. 3. Next Wip populate fails with "attempt to change key 2 to 1:

When developing workflows for an application container environment, the following site configuration files are needed:

• localsite.properties (points to localsite.xml) - expected by WipViewer from Eclipse
• localsite.xml (uses OSUserIdentifer) - to be able to use WipViewer from Eclipse
• remotesite.properties (points to remotesite.xml) - needed to be able to open a WipViewer remotely in the server JVM
• remotesite.xml(uses OSUserIdentifer) - could be same as localsite.xml, unless custom factories are needed
• site.xml - used by the application, typically does not use OSUserIdentifier, instead e.g. DirectUserIdentifier?, and custom factories

That makes for a lot of configuration files to be kept in sync.

A possible improvement could be to use xi:XInclude to modularize the various site XML files. I have not tested if WorkThru? allows XIncludes.

It would be much better if there was only one pair of site properties/site XML files. It would be even better if there was NO site properties file, only the site XML file.

There are situations where it's impossible to infer the domain keys given the Wip keys. For example, a reference field group that allows multiple entries based on a left-subset key. (Populate a subfieldgroup with all people in department 41...this particular case also requires a FieldGroupSequence? to complete the key).

The default is that the domainKey is the same as the wip key for all interaction modes exception Reference. For reference the default is all non-inherited keys.

Sometimes a child field group has the same keys as its parent (perfectly valid). But if the interaction mode is a Reference this can cause problems. In the Reference field group the true domain key is usually not the same as the field group's key(s). The true key is the right-subset non-inherited keys of the field group. But when the parent's keys are the same there are now non-inherited keys. Solution is to find the first domain key by searching upwards n-levels until a lower-dimensional key is found.

Created a new WipSpec. The WipSpec viewer's Field Use tab shows no fields for the root field group. I then added a key field. Then I decided to rename the corresponding field in the FieldDef? Editor.

First problem: The FieldDef? name in the WipSpec editor did not update to reflect the new field name in the FieldDef? Editor.

Second problem: I tried to delete the key field in the WipSpec editor, which should return the WipSpec to the state that a new WipSpec has (i.e., no fields at all). The editor does not let me delete the key field, complaining that this would violate a constraint "Attempt to delete all rootfieldgroup keys". This is inconsistent behavior, at best.

The workaround for the second problem is to add another key field, and then delete the obsolete key field.

Tentative insert is a mode that exists for the period of time after an insert is started and before all the keys are specified. TentativeInsert mode is aborted if 1) cancelInsert is called 2) another insert is attempted while the previous insert is still unresolved or 3) if the Wip is SAVEing. Any of these aborts silently discard the insert.

Suggestion: add a mode to the Wip that throws an exception (InvalidStateException?) in cases 2 or 3 above.

Compiling the sources using JDK 5.0 leads to warnings and aborts with an error due to Java core library API changes.

 [javac] F:\WorkThru Trunk\src\org\workthru\core\TimedAction.java:224: warning: non-varargs call of varargs method with inexact argument type for last parameter;
    [javac] cast to java.lang.Object for a varargs call
    [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
    [javac] method.invoke(wip, strArgs);
    [javac] ^
    [javac] F:\WorkThru Trunk\src\org\workthru\core\TimedAction.java:246: warning: non-varargs call of varargs method with inexact argument type for last parameter;
    [javac] cast to java.lang.Object for a varargs call
    [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
    [javac] method.invoke(wip, strArgs);
    [javac] ^
    [javac] F:\WorkThru Trunk\src\org\workthru\core\TimedAction.java:261: warning: non-varargs call of varargs method with inexact argument type for last parameter;
    [javac] cast to java.lang.Object for a varargs call
    [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
    [javac] method.invoke(pool, strArgs);
    [javac] ^
    [javac] F:\WorkThru Trunk\src\org\workthru\core\TimedAction.java:271: warning: non-varargs call of varargs method with inexact argument type for last parameter;
    [javac] cast to java.lang.Object for a varargs call
    [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
    [javac] method.invoke(pool, strArgs);
    [javac] ^
    [javac] F:\WorkThru Trunk\src\org\workthru\core\TimedAction.java:280: warning: non-varargs call of varargs method with inexact argument type for last parameter;
    [javac] cast to java.lang.Object for a varargs call
    [javac] cast to java.lang.Object[] for a non-varargs call and to suppress this warning
    [javac] method.invoke(objectStore, strArgs);
    [javac] ^
    [javac] F:\WorkThru Trunk\src\org\workthru\util\JulianCalendar.java:42: java.lang.Comparable cannot be inherited with different arguments: <> and <java.util.Calendar>
    [javac] public class JulianCalendar extends GregorianCalendar implements Cloneable, Comparable
    [javac] ^
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.
    [javac] 1 error
    [javac] 5 warnings

This can be ameliorated by adding the following additional argument to the javac task:

<compilerarg line="-Xlint:unchecked -source 1.4"/>

This additional compiler argument should be optional so that both JDK 1.4 and JDK 5.0 can be used without the need to change the build.xml file.

If the WipViewer is started using the main method, it is configured to call System.exit upon closing of the main window.

This presents a problem, if the viewer is started in an application container, such as an application server. When the WipViewer window is closed, the server is aborted.

As a workaround, I call the WipViewer constructor followed by run() with the last argument set to false.