ksession name is invisible in kmodule.xml on Project Screen. I can add a ksession to kmodule.xml, however:
1. After clicking on OK, I would assume that the dialog for adding will close.
2. The name of ksession is later invisible in the list, so user can be confused and add more ksessions of the same name. Have not tried working with multiple same names for ksessions, but I guess that this won't work.
3. The name 'default' is possible to save. But it's a trap. You can build the project, but cannot deploy later due to message that the name cannot be 'default'. This is both annoying and confusing, because kbase can be named default. So I think that the user should be warned in advance before using forbidden names.
This should be fixed as at least one ksession is mandatory to be added to a kmodule.xml of the project.
business-central.war - BPMS 6 DR5 (Beta3)
A part of the problem is that the ksession element is added into the kbase element, therefore, if you are creating a new ksession via the GUI, you need to select a kbase first. This way, the dialog for adding a ksession will close. If you don't select a kbase first, it won't.
The GUI allows you to add ksession outside of a kbase it seems, which makes things quite buggy, as Jiri described above.
Names don't seem to be exactly forbidden, but if you try to add a ksession outside of a kbase with the same name as an already existing kbase, you will get something like the following in your Problems tab:
kmodulet.xml found, but unable to read org.xml.sax.SAXParseException; lineNumber: 3; columnNumber: 83; cvc-id.2: There are multiple occurrences of ID value 'default'.
I'm not the responsible for that screen, Toni Rikkola or Michael Anstis should review this issue.
you are the default Assignee for business central component. Default assignee should be the one who is either able to fix the bug or who can reassign the bug to someone who does the fix.
Also please change the status of the bug to modified only when it is fixed, not in the case that you think that it should be fixed by someone else.
p.s. Changing the assignee to Kris, so he can decide who will work on this issue.
Verified on DR6 (Beta 5).
Step 1) is not fixed but I will create a separate issue for it so we can better track it.
This BZ has been part of the 6.0.0 stream.