I cannot try alternatives till later this evening, will let you know of results. If I cannot get tenancies working for tomorrow its not the end of the world. I was getting "record not found" errors last night due to making region allowsNull="false", so a bit of a panic, given its mostly been working very smoothly now for a while.
On Thu, Nov 26, 2015 at 9:40 AM, Dan Haywood <[email protected]> wrote: > On 25 November 2015 at 22:26, Stephen Cameron <[email protected]> > wrote: > > > Hi Dan, > > > > I did not explain it that well sorry. > > > > I want to get rid of nulls completely, the fact that I do handle them is > > just a work-around for the fact that they are still being created, but > only > > for People. That is, if a new Participant is registered it looks to see > if > > there is an existing Person with the same details then adds a new one if > > not present (a single Person can be a Participant and/or a Volunteer). > The > > Participant is getting its region set in setUpdatedBy() but the Person is > > not, I need to debug this. > > > > > In 1.10.0, a better approach is probably to add a subscriber to the > lifecycle events: > > @DomainService(nature=NatureOfService.DOMAIN) > public class RegionSubscriber extends AbstractSubscriber { > > @Subscribe > public void on(ObjectPersistingEvent ev) { > Object domainObject = ev.getSource(); > } > > @Subscribe > public void on(ObjectUpdatingEvent ev) { > Object domainObject = ev.getSource(); > } > } > > > > > > As general interest is handling such things via such a service better, > that > > is to avoid injecting services into entities if possible? > > > > > There's nothing wrong with injecting services into entities; it allows them > to perform their responsibilities without leaking details of how they do it > (their implementation) to the caller. I don't hold by this "pass in the > services" and "double dispatch"... I see that as a code smell. > > On the other hand, we now have a very rich set of domain events; in AOP > terms these are jointpoints (or is it pointcuts? see [1]), anyway they are > a different way to cause "stuff to happen". > > Should one have the entity call a services, or rely on subscribers to > domain events? With the latter, the entity is very clean and the > responsibility kept completely separate. On the other hand, with events > the order in which the subscribers fire is non-deterministic. > > > > > > > > Last minute tweeks aren't the best idea, but the tests that I do have are > > proving their value. These particular issues are probably a result of no > > integration tests yet. > > > > > It's not clear to me if my suggestion to use the TenancyEvaluator SPI > helped ? Or, indeed, whether you have a reasonable workaround in your > current handling of the nulls? > > > > > > Thanks > > > > > > [1] > > http://stackoverflow.com/questions/15447397/spring-aop-whats-the-difference-between-joinpoint-and-pointcut > > > > On Thu, Nov 26, 2015 at 8:09 AM, Dan Haywood < > [email protected] > > > > > wrote: > > > > > Hi Steve, > > > > > > Not sure I follow quite all the ins-and-outs of this, but what could > well > > > be of use is the optional ApplicationTenancyPathEvaluator domain > > > service[1]. If an implementation is registered (on the classpath), > then > > > the security module will delegate to this [2] in order to determine who > > > gets to see/edit what. > > > > > > From what I did follow, it sounds like you need to treat objects with a > > > null region in a particular way? If so, then hopefully you can put this > > > "special case" logic in an implementation of said service. > > > > > > HTH > > > Dan > > > > > > > > > > > > [1] > > > > > > > > > https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/dom/tenancy/ApplicationTenancyPathEvaluator.java > > > [2] > > > > > > > > > https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/facets/TenantedAuthorizationFacetFactory.java#L72 > > > > > > > > > On 25 November 2015 at 20:25, Stephen Cameron < > > [email protected]> > > > wrote: > > > > > > > Hi, > > > > > > > > I have a problem with Application Tenancies not working the way I > > want, I > > > > want to drive it off a field 'region', such that a person is > assigned a > > > > tenancy of GLOBAL, NORTH, SOUTH, NORTH-WEST and these are also the > > > regions > > > > that they are working in too, so when they create a record their > region > > > > gets assigned to the new record and that controls who else can see > the > > > > record. > > > > > > > > This mostly works, but there is one small glitch. The main problem I > > have > > > > is setting it up so that region is non-null and any records created > by > > a > > > > GLOBAL tenancy user are seen by all users, while those created by a > > > NORTH, > > > > SOUTH or NORTH-WEST user are seen only by users with the same > tenancy. > > By > > > > changing the region of a record it can change tenancy. > > > > > > > > Presently this is broken, or at least it I think it was working > > correctly > > > > when I allowed a record with a region of null to be the GLOBAL ones. > I > > > need > > > > to have this working for a demo tomorrow, so advice is welcomed on > how > > > best > > > > to set this up properly. > > > > > > > > My base class that controls all this here: > > > > > > > > > > > > > > https://github.com/Stephen-Cameron-Data-Services/isis-chats/blob/master/dom/src/main/java/au/com/scds/chats/dom/AbstractChatsDomainEntity.java > > > > > > > > The other small glitch is that a person record created in the process > > of > > > > creating a participant doesn't get assigned a region automatically. I > > > have > > > > a work-around for that in place at present, anything that has a null > > > region > > > > gets presented as having a global tenancy. > > > > > > > > > > > > Thanks > > > > > > > > Steve Cameron > > > > > > > > > >
