Extending shared types with "private parts" (:-)

[jri]

When user A extends a type which is shared with user B with "private parts" user B gets real trouble with continuing using that type. Existing instances do not render anymore, even creating new instances is not possible anymore.

This happens if user B doesn't have read access to any part of the type def:

• child type
• assoc def
• custom assoc type

[Jörg Richter <jri@…>]

In e9b490461937f50f941784d1a80d0c5efdf6d8b7/deepamehta:

Core: user dependent type def views (#1021).

When handing types over to the userland for each type only the READable assoc defs are included.

An assoc def is regarded READable if *all* of these parts are READable:

• the assoc def itself (an association)
• the child type (a topic type)
• the custom association type, if set (an association type)

That is the same type definition may include different assoc defs depending on who is logged in.

As a consequence the webclient's detail panel renders only that topic/assoc parts that are READable by the current user. Example: user A extends the type "Person" with a private "Date of Death" assoc def. Now when selecting a person instance the detail panel renders the Date of Death field (both, info view, and form view) only if user A is logged in. For other users the Date of Death field is not rendered.

See #1021.

[Jörg Richter <jri@…>]

In 2562563fdf01a60f2dabc80cf7a2fe9772333981/deepamehta:

Core: project type defs in all situations (#1021).

Assoc defs the requesting user has no READ permission for are filtered in all situations:

• When a single type is requested
• When a type is contained in a directive
• Also assoc types are handled

See #1021.

[Jörg Richter <jri@…>]

In 25c5f13593d518936f41dee866a870583a233639/deepamehta:

Core fix: type editor w/ private fields (#1021).

Submitting the type editor form works even if it does not show all assoc defs (= "fields") due to lacking permissions. The exception adding/removing of assoc defs not yet supported via type update is not thrown anymore.

Example: user A extends the Person type with private assoc defs. When user B edits the Person type (clicking the type topic, then Edit) the assoc defs added by user A do not appear. Once the form is submitted the type definition is properly updated.

One cosmetic issue remains: after user B submits the form the assoc defs added by user A will move to the begin. The order is not preserved. User A can restore the order manually. However it will be lost again once user B edits the type.

See #1021.

[Jörg Richter <jri@…>]

In cdf267da66840a2fc3767aa80745e821d7bbb385/deepamehta:

Minor TypeModelImpl? refactoring (#1021).

See #1021.

[Jörg Richter <jri@…>]

In dd7f14dfdc870b7136f513d90a5d5d3e3feae158/deepamehta:

Minor TypeModelImpl? refactoring, pt. 2 (#1021)

See #1021.

[Jörg Richter <jri@…>]

In 28c58318e84c26e63d6591a1a7ab5e5afde20721/deepamehta:

Core: fix per-user type projection, pt. 1 (#1021)

When creating a type the type topic is instantiated explicitly on a TopicModel (which is freshly created from the TypeModel). Creating the type topic from the TypeModel directly would fail as topic creation implies topic instantiation, and due to the polymorphic instantiate() method a Type object would be instantiated (instead a Topic object). But instantiating a type newly implies per-user type projection, that is removing the assoc defs not readable by the current user. But at the time the type topic is stored in the DB its assoc defs are not yet stored, and the readability check would fail.

See #1021.

[Jörg Richter <jri@…>]

In 2b3225898eb7665952695a6d28ea73da744b73c1/deepamehta:

Core: fix per-user type projection, pt. 2 (#1021)

Type updates are performed on the internal (= kernel) type model instead on the userland's type model. Performing an update on the userland's type model would have no effect, as it is transient. The userland's type model is always a cloned and filtered (= "projected") version of a kernel type model which is created on-the-fly each time a specific user requests it.

See #1021.

[Jörg Richter <jri@…>]

In d8e955a5c29e9e916327b3433aee3a6883c8b256/deepamehta:

Core: adapt per-user type projection tests (#1021)

BREAKING CHANGE

When using DeepaMehtaType accessors (like getAssocDefs()) and manipulators (like addAssocDef()) one has to keep in mind that the manipulators operate on the kernel type model, while the accessors operate on the userland type model, which is a cloned (and filtered) kernel type model. Manipulations are not immediately visible in a previously obtained userland type model. To see the change one must re-get the userland type model (e.g. with dm4.getTopicType()).

Example:

TopicType type = dm4.getTopicType("some.type.uri");    // obtain a userland type

Suppose the type has 3 assoc defs:

type.getAssocDefs().size()      // 3

Now add another assoc def:

type.addAssocDef(...);

The (userland) type has still 3 assoc defs:

type.getAssocDefs().size()      // still 3

The added assoc def is seen only after re-getting the (userland) type:

dm4.getTopicType("some.type.uri").getAssocDefs().size()      // now 4

See #1021.

[Jörg Richter <jri@…>]

In 6a26e410b8f5de9bada6272472539c98db452431/deepamehta:

Core: fix type update (#1021).

See #1021.