First, I would remove the entry in isis.properties (or in your AppManifest)
that registers the TenantedAuthorizationFacetFactory (as per the README
[1]) to check that the record that's gone missing now appears.  If so, it
confirms that it is indeed tenancy.

Second, I would reinstate the facetfactory and then put a breakpoint in
TenantedAuthorizationFacetDefault [2] and trace through the logic for the
object that gets hidden.  It implements the algorithm described in the
README [3]


HTH
Dan



[1] https://github.com/isisaddons/isis-module-security#tenancy-checking
[2]
https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/facets/TenantedAuthorizationFacetDefault.java#L72
[3] https://github.com/isisaddons/isis-module-security#application-tenancy


On 30 November 2015 at 20:00, Stephen Cameron <[email protected]>
wrote:

> I think this is going to take a bit of effort to sort out, it does seem to
> be related to the region, which is the one I use for returning a  tenancy
> path for each entity. So given that it was working before adding tenancy,
> which I can can check, that will be a clue as to where to look later.
>
> On Tue, Dec 1, 2015 at 6:36 AM, Stephen Cameron <
> [email protected]>
> wrote:
>
> > Here are the relevant Native queries, they relate to a parent record and
> > two children in the activity table, ids are <29>, <30>, <31>
> >
> > 05:46:41,713  [Native               qtp730583371-17 DEBUG]  SELECT
> >
> a0.createdby,a0.createdon,a0.lastmodifiedby,a0.lastmodifiedon,a0.approximateenddatetime,a0.copiedfromactivityid,a0.costforparticipant,a0.description,a0.isrestricted,a0.`name`,a0.oldid,a0.scheduleid,a0.startdatetime,a0.activity_id,a0.classifier
> > FROM activity a0 WHERE a0.classifier = 'EVENT' AND a0.parent_activity_id
> =
> > <29>
> > 05:46:41,723  [Native               qtp730583371-17 DEBUG]  SELECT
> > b0.`name` FROM activity a0 INNER JOIN region b0 ON a0.region_name =
> > b0.`name` WHERE a0.activity_id = <30>
> > 05:46:41,726  [Native               qtp730583371-17 DEBUG]  SELECT
> > b0.`name` FROM activity a0 INNER JOIN region b0 ON a0.region_name =
> > b0.`name` WHERE a0.activity_id = <31>
> > 05:46:41,756  [Native               qtp730583371-17 DEBUG]  SELECT
> >
> b0.createdby,b0.createdon,b0.lastmodifiedby,b0.lastmodifiedon,b0.approximateenddatetime,b0.copiedfromactivityid,b0.costforparticipant,b0.description,b0.isrestricted,b0.`name`,b0.oldid,b0.scheduleid,b0.startdatetime,b0.periodicity,b0.activity_id,b0.classifier
> > FROM activity a0 LEFT OUTER JOIN activity b0 ON
> > a0.parentactivity_activity_id = b0.activity_id WHERE a0.activity_id =
> <31>
> >
> >
> >
> > It has to find the region for 30 and 31 to do a comparison I assume,
> which
> > is:
> >
> > return ObjectContracts.compare(other, this, "name", "startDateTime",
> > "region");
> >
> > So it seems to reject id=30 as being of no interest?
> >
> > I tried Guava compare but i broke all my tests, maybe I'll have another
> go
> >
> > region is the same for both, the startDateTime differs though.
> >
> >
> >
> >
> >
> > On Tue, Dec 1, 2015 at 6:08 AM, Stephen Cameron <
> > [email protected]> wrote:
> >
> >> Hi,
> >>
> >> I have a situation where a entity is not displayed in a collection, both
> >> are present in the database and get selected by the native query that DN
> >> creates, but for some reason one of the two is not displayed.
> >>
> >> This is kind of bizarre as when the two are created the first is not
> >> displayed, but the second is, so its not a comparison issue apparently.
> >>
> >> Any ideas?
> >>
> >>
> >>
> >>
> >>
> >
>

Reply via email to