Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Uffe

Pages: 1 2 [3] 4 5 ... 21
31
Bugs and Issues / Change: inconsistent details views
« on: April 11, 2018, 12:39:00 am »
Hi all,


I've spotted an inconsistency between the two details views for a Change, specifically with the Version property. I assume the behaviour is the same for other maintenance types.

The Changes window is a non-modal window which has the list of Changes for an element along with a details view which (NB) contains all the properties for a Change.1

You can also use the Element Browser, which is also a non-modal window with a tree view in which all maintenance items (and a bunch of other stuff) is displayed with just some basic info.
From the Element Browser you can double-click a Change to open a modal window titled "Change details for <element type>: <element name>" which (NB) contains all the properties for a Change.1

Here's my thing.

If you create a Change from the Changes window, it's given a default Version. A little cryptic, and not related to what's in the element's Version property, but whatever, it's there and you can change it to whatever you want.
You can even clear that property, and save the Change. The empty string is saved in the database.

But here's where it gets weird.

If I open up the Change Details window, the empty Version is replaced with a new Version on the same form as the default. The database has not changed at this point, but the Apply and OK buttons are disabled even though the dialog contents do not match the database.

If I close the Change Details window without making any changes, I don't get a confirmation prompt.

If I open it up again, there is a new generated Version filled in.

So in other words the Changes window allows empty Versions, but the Change Details window does not.

Reported.


/Uffe


1There's actually one column in the t_objectproblems table, Severity, which is not shown. But it's not in either of these windows, so it is consistent.

32
Hi all,


According to the user guide, the Description field of a Maintenance Item should be shown but not editable in the Notes window.

I don't see anything in the notes window, whether I select the element that has an associated maintenance item in the project browser or a diagram, or even if I select the maintenance item itself in the element browser.

Is there a configuration I'm missing?

Cheers,


/Uffe

33
Hi all,

Following on from my earlier Bugs & Issues post, I sent the following feature request to Sparx on March 28. I haven't heard back yet, but will update this post when and if.

/Uffe


1) For action pins which do not have a defined Argument but do have a defined Type, provided the type is a classifier, the classifier's tagged values should be included in the pin's extended tagged values.
This is how activity parameters behave.

2) For action pins which have a defined Argument, it should not be possible to edit the Name, Type, Multiplicity, Kind, or its Stream, Control Type or Exception properties.
These properties should all be slaved to the argument's corresponding properties.

3) If an action pin has a defined Argument, and that argument has the Fixed Value property set, it should not be possible to edit the pin's Value.

4) When creating an action pin based on an activity parameter, the pin's Value should be set to the parameter's Default Value, if any.

5) When creating an action pin based on an activity parameter, the pin's Kind should be set based on the parameter's Direction as follows:
in => in
out => out
return => out
inout => this should result in two pins, one in and one out, with otherwise identical properties.

6) When shown in diagrams, an action pin label should contain the following based on which of the pin's properties are set:
Name and Value => "name = value" (Type omitted if set)
Name, no Value => "name : type"
Value, no Name => "value : type"

34
Bugs and Issues / DocumentElement fails for certain users
« on: April 05, 2018, 12:07:23 am »
Hey guys,


Got a weird one.

The setup:
SQL Server repository, 13.5.1352 clients. Recently upgraded from 11.1, where everything worked.
Browser script (VB) which calls an MDG Technology-deployed script to generate a document. Templates in same MDG Technology.
Security enabled with Windows authentication. All users have both Run and Edit Script permissions.

For some users, the script fails when it hits the first call to DocumentGenerator.DocumentElement().
Previous DocumentGenerator calls all seem to work just fine. They are, in order:
DocumentGenerator.SetStyleSheetDocument("Numbered Headings - Black")
DocumentGenerator.NewDocument("")
DocumentGenerator.InsertLinkedDocument(linkedDoc)


Then comes
DocumentGenerator.DocumentElement elementID, 0, "The template"
... and that's all she wrote. The script breaks on that line, popping an error dialog which contains the line number but no error code or message.
If the user hits F8 and selects the same template, the generation works fine.

This is consistent:
Some users cannot run the script at all, other users can run the same script repeatedly without any problems.
For users who can't run the script, if they log in as admin (which has the full set of permissions), the script still breaks the same way.
In a different repository, the problem persists: the same users can't run the script.

Any bells ringing?

Could it be related to my zombie custom-script-fragment-doesn't-work-when-invoked-through-the-API bug?
The template in this case does include a fragment, although this time it's a regular SQL fragment.

Is DocumentGenerator fundamentally broken in 13.5?


/Uffe

35
Bugs and Issues / User guide: wrong permission listed
« on: April 04, 2018, 09:23:30 pm »
Hi all,


The user guide page Specify Required MDG Technologies specifies that in order to manage the set of required / permitted MDG Technologies for a security-enabled project, the permission 'Manage Project Settings' is required.

This is incorrect. The relevant permission is 'Configure Project Prerequisites'.

Reported.


/Uffe

36
In 1352, if you create an RTF template and select the Package / Element section, EA automatically includes the Child Elements section.

If you deselect Child Elements, and then click the '+' icon next to the Element section to collapse it, EA reselects the Child Elements section and places the corresponding tags in the template.

Reported.


/Uffe

37
Bugs and Issues / MDG Technology wizard: wrong back link
« on: March 27, 2018, 10:02:06 pm »
If in 1352 you start the MDG Technology wizard, select not to use an MTS file and click Next, and from the next wizard page click Back, you arrive at the MTS file selection page.

Instead, you should arrive at the wizard's first page.

Reported.


/Uffe

38
Bugs and Issues / Custom Script fragments not working in 13.5.1352
« on: March 27, 2018, 03:07:36 am »
Hi all,


We recently upgraded from 11.1 to 13.5.

I have a document generation script which worked fine for three years before the upgrade, and now doesn't.

In the project (SQL Server repository), there is a simple project browser script that calls the main document generation script which resides in an MDG Technology. The generation script makes a number of calls to DocumentGenerator.DocumentElement(), specifying various elements and a few dozen different templates. The templates reside in the same MDG Technology.

Some templates include fragments. Custom SQL fragments work as expected every time. Custom Script fragments, however, do not.
(Note: these are the only two types of fragment I'm using. There are no Template Selector fragments or Document Script fragments. If you are unaware of the difference between these, please refrain from posting "helpful" suggestions.)

The first time I run the document generation script, all custom script fragments produce the desired result.
On subsequent runs, the custom script fragments produce nothing.
After a restart of the client, the document generation again works once, then I have to restart again, etc.

When testing, I am changing nothing between runs. The behaviour is consistent: all custom script fragments fail after the first run, none of them fail on the first run, and custom SQL fragments never fail.

If I select the same element in the project browser and hit F8 to invoke the regular document generator, and specify the "parent" template which contains the references to the fragments, this partial generation works every time. But it does not clear the error: when going through the document generation script, custom script fragments fail consistently every time after the very first.

I have tried regenerating the MDG Technology: no effect.

What the hell is going on?


/Uffe

39
Bugs and Issues / Behaviour of action pins
« on: March 22, 2018, 11:06:41 pm »
Hey all,


I'm bumping into some things I don't like with action pins. Am I the only one?

Let's say I create an activity with some parameters, and specify classes for their types.
Let's then say I create a call behavior action from the activity, with an action pin for each parameter.
Each pin thus created is correctly linked to the correct behavior (the activity) and parameter.

However, each pin is of "input" kind -- regardless of the corresponding parameter's direction.

Shouldn't the pin kind follow the parameter direction?


Furthermore, the pins do not have any types set.

Shouldn't they?


Finally, if an activity parameter's type (class) has tagged values, those tagged values are included in the parameter's extended tagged values.
A pin does not -- even after setting the type to match the corresponding parameter's, the pin has no extended tagged values.

Shouldn't tagged values be "extended-inherited" from types to pins, just as from types to parameters?


The first two I can script my way around if necessary. But there's magic behind the extended tagged values, so I'd need that to be fixed in the tool.

Or am I unreasonable -- or plain wrong -- in how I expect action pins to work?


/Uffe

40
Bugs and Issues / DB2 import: FK constraint connector target role
« on: March 21, 2018, 03:02:41 am »
Hi all,


Using 13.5.1352 on Windows 7x64, importing from a z/OS DB2 12 database through IBM DB2 Connect.

After import, some but not all foreign key constraint connectors are out of whack. The Involved Columns list is empty (as is the Join on Constraint field), and the target role is set to some random string of garbage.

The same garbage string gets reused in several broken connectors, but from one import there may be more than one such garbage string.
The behaviour is not consistent; the garbage strings and which connectors get them vary from import to import (of the same database).

Has anyone else seen this? If so, what's going on?

I can go through and set the Join on Constraint property manually. The dropdown is properly populated.
But does anyone know if this indicates that something else is broken in the model?


Secondly, EA crashes after import. Far as I can tell, this is an unrelated error.
The crash occurs even if I tell EA not to import any constraints or foreign keys at all, and it occurs whether or not I tell it to draw diagrams.

The Windows log shows a fault somewhere in or near ntdll.dll.

Anyone else see this?

Cheers,


/Uffe

41
Hi all,


EA does not allow structural elements (ports, activity parameters, etc) to be placed in a diagram unless their parent element is in the diagram as well.
This makes sense in most situations, but when the diagram is the composite diagram for the parent element it does not.

I would like to propose, therefore, a relaxation of the parent element restriction to allow structural elements to be placed in a diagram without their parent element if the diagram is the composite diagram of the parent element.

A composite diagram typically depicts the inner structure of a parent element -- a structural breakdown in the case of classes and components, or a behavioral breakdown in the case of activities -- with the structural elements representing parts of that breakdown.
In these cases, the presence of the parent element in the diagram serves no semantic purpose: if the diagram's context is a breakdown of an element, that element is unnecessary. All it does is cause layout problems.
However, if you want to show the structural elements, you have to include the parent. There's no other way to get them in there.

So EA should allow structural elements to be placed freely within the composite diagram of their parent element.

If the user chooses to place the parent element in its own composite diagram, the old rules should apply and the layout of the structural elements should be locked to the parent element.

You can almost see what I'm after by creating a diagram filter which hides the parent element's type, and applying it in a composite diagram. This causes the structural elements to appear to be free-floating, although they are in fact still constrained by the hidden parent element.


/Uffe

42
Hi all,

Activity parameters and action pins do not honour the diagram's Show Parameter Detail setting (in Features).

Shouldn't they?


/Uffe

43
Hey all,


How nicely do in-project defined requirement types play with profile-defined stereotypes?

Let's say I want to define a requirement type 'MyReqType'. I want it to show up in the Type dropdown in the properties dialog (project type), and I also want it to have a mandatory tagged value (stereotype).

If I define the requirement type both ways, how will EA behave?

If I create a «MyReqType» element from the toolbox, will EA recognize it as being of the 'MyReqType' requirement type, or will it see it as something different because the fully-qualified stereotype name is MyProfile::MyReqType?

If I create a regular requirement from the Common toolbox and set its type to 'MyReqType' in the property dialog during creation, will the tagged value be created?


Cheers,


/Uffe

44
Automation Interface, Add-Ins and Tools / WebEA user authentication
« on: February 17, 2018, 12:05:54 am »
Hi all,


I'm evaluating WebEA for a client. According to the WebEA Login help page, in addition to some "access code" I cannot see any point of, WebEA supports "standard Enterprise Architect model security." However, the page then states that login credentials can include
  • An access code, or
  • A user ID and password, or
  • Possibly all three
Ignoring the fact that "all three" makes no sense since you can't provide just a password with no user ID, what about Windows domain authentication? It's part of standard EA model security, but it's not in the list.

Can you authenticate WebEA users against a domain, or not?

What happens if you configure a project for windows authentication, and configure WebEA to prompt user ID and password?
Should users provide a blank password?
Is the password ignored?
Or will users be unable to log in?

What happens if you configure a project for windows authentication, and configure WebEA to prompt for an access code, or no authentication at all?
Are users correctly identified in the project (in Author fields etc)?


/Uffe

45
General Board / Security permission missing from user guide
« on: February 10, 2018, 02:50:52 am »
Hi all,

The recently added security permission Configure Project Requisites is not listed on either the 13.0 permission list or the 13.5 permission list pages.

/Uffe

Pages: 1 2 [3] 4 5 ... 21