Thanks Dan, I will check these when home this evening. On Tue, Dec 1, 2015 at 9:42 AM, Dan Haywood <[email protected]> wrote:
> 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? > > >> > > >> > > >> > > >> > > >> > > > > > >
