we might think about this, including all relationships, if removing the entity. On the other side this could easily be done in the database (delete on cascade).
I have the use case, that groups have certain different roles assigned to each user and if the group is deleted, all the relationships shoud be deleted, where this group occurs. There might exist special groups, which keep the relationship and should not be deleted, but this might be checked somewhere. It even might be that one entry defines the role in a "global" group and another the group (with a default basic role entry). then only the group relationship would be deleted, while the global role still exists, which would be ok. Best regards, Georg Von: Jeffery Painter <[email protected]> An: [email protected] Datum: 13.12.2017 17:28 Betreff: Re: [RESULT] [VOTE] Release: Turbine-Webapp 1.0.2 archetype targeting Turbine4 on staged repository Yes - I saw you had made comment as well for something like role.removePermission() and related methods which are not there yet. I think it is probably cleaner to keep it in the security manager as all the other methods are already there (simpler to reference than knowing the Role and Group objects have their own add/remove methods). But I am open either way. And you are right, in my last update to the turbine-flux module, I was testing removing a role, and it was failing if the role was still linked to a user... I simply made a method to remove related users before removing the role, and that cleared it up for me. I think this is the proper logic. Feel free to correct me if I am wrong :-) Group removal 1. Remove linked user/group/role in TURBINE_USER_GROUP_ROLE 2. Remove from TURBINE_GROUP Group revoke: (Same as above with step 2) Role removal (Would impact all groups and users) 1. remove linked users in TURBINE_USER_ROLE 2. remove linked permissions in TURBINE_ROLE_PERMISSION 3. remove from TURBINE_ROLE Role revoke: just remove the entry in TURBINE_USER_ROLE for a single user (Unless we were to implement a TURBINE_GROUP_ROLE relationship - see below) Permission removal (impacts all associated roles) 1. remove from all associated roles in TURBINE_ROLE_PERMISSION 2. remove from TURBINE_PERMISSION Permission revoke: only works at the role level - permissions are not directly assigned to users 1. remove entry from TURBINE_ROLE_PERMISSION 2. do not delete from TURBINE_PERMISSION (does not affect other roles) After thoughts: Are we missing something here? Thinking that a group could encompass a set of roles? TURBINE_GROUP_ROLE (link roles to a group?) Nothing like this currently exists. I was never sure otherwise how the group object might be useful. If so, this would obviously change cascade effects for revoking a user from a group, but if not, wouldn't revoke group just essentially be remove group without removing the group from the TURBINE_GROUP table? Thoughts? How do you currently use groups? -- Jeff On 12/13/2017 11:13 AM, Georg Kallidis wrote: > Hi Jeff, > > I 've updated Turbine Webapp with more complex tests. > > This is not yet in the repo: > > @FulcrumSecurityTorqueModelManager > - We may be aware of the grant behaviour of Fulcrum Security Torque > ModelManager namely, that all relationships are cleaned up for each object > before updating, that is all relationships are refreshed. This happenss in > one big transaction and should be save. Where there might be issues, is > that for one one object there might be a lot of relationships, not for a > user I presumably, but for some group and/or role. It might be, that one > role grant have to clean up 1000s of entries or more, as this might be a > role/group shared by many. Actually this is not even needed at all, as the > user update does already cleanup the relationship table! As a result, I > would remove the group and role database update in the grant method. > > revokeAll(Group) > - I would like to add a Turbine Default Security method revokeAll(Group) > which revokes all entries, any rights/roles for any user in this specific > group (may be excluding global or Turbine). But may be I overlooked > something ... ? > > Best regards, Georg > > > > Von: Jeffery Painter <[email protected]> > An: [email protected] > Datum: 13.12.2017 16:26 > Betreff: Re: [RESULT] [VOTE] Release: Turbine-Webapp 1.0.2 > archetype targeting Turbine4 on staged repository > > > > Hi Georg, > > I have merged your pull request in github for turbine-flux and made a > few minor cleanups (updating licenses etc). All seems to be working > well, and I am using it in my own application without any trouble. > > Thanks for all your help on making the necessary changes to security > manager. Let me know what I can do to help with pushing the next release. > > I will download your updates to turbine webapp and see if there is > anything I can do there. > > -- > Jeff > > > On 12/12/2017 04:08 AM, Georg Kallidis wrote: >> Hi all, >> >> as a result we have two binding votes for the release candidate >> >> [binding] >> +1 - Georg Kallidis >> -1 - Jeffery Painter >> >> The result is we cancel this RC (dropping the artefacts, ..). >> >> Following the communitys discussion in the dev mailing list the > suggested >> workflow would be: >> >> - first to release two modules already in preparation with bugfixes, >> - only after this is done the Turbine Webapp RC will follow. >> >> In a sum, the projects next RCs in question for this issue are: >> >> (1) Security Fulcrum v1.1.2 >> (2) Turbine v4.0.1 (depends on 1) >> (3) Turbine Webapp 1.2 (depends on 1,2) >> >> Comments (and commits) welcome! >> >> Best regards, Georg >> >> >> >> >> Von: "Georg Kallidis" <[email protected]> >> An: "Turbine Developers List" <[email protected]> >> Datum: 08.12.2017 14:22 >> Betreff: Re: Re: [VOTE] Release: Turbine-Webapp 1.0.2 archetype >> targeting Turbine4 on staged repository >> >> >> >> Hi, >> >> please read also the forwarded e-mail below from Jeffery. Jeffery´s >> proposal may be the fastest way to release, what we already know has to > be >> done. >> >> But we may be aware, that SOME bugs may always be hidden in ANY release >> and I would NORMALLY suggest to always complete a Turbine release with > an >> Turbine Webapp release. >> >> As a result, if nobody complains (i.e. we get only unanimous consent, > "do >> not care" remarks or no reply at all), I'll continue by sending a >> VOTE/RESULT around beginning of next week proposing to >> >> - drop the current Turbine webapp RC >> >> - targeting instead for the following RCs in this order: >> >> (1) Security Fulcrum v1.2 - still some more checks needed >> (2) Turbine v4.0.1 - >> (3) Turbine Webapp 1.2 - double checking (1) and (2) with tests in >> SNAPSHOT mode >> >> If someone else wants to help out, let me know it! >> >> Best regards, Georg >> >> >> >> Von: Jeffery Painter <[email protected]> >> An: Georg Kallidis <[email protected]> >> Datum: 08.12.2017 13:05 >> Betreff: Re: [VOTE] Release: Turbine-Webapp 1.0.2 archetype >> targeting Turbine4 on staged repository >> >> >> >> >> I think that is a good plan. I have no other issues with Turbine >> 4.0.1-SNAPSHOT release at this time (after fixing the input.encoding >> issue). And the patches you've made to fulcrum-security seem to work >> "well enough" for most use cases and we have identified what needs to be >> addressed going forward. Again, I don't use permissions (but after >> working on the Flux system, it looks like something I might use in the >> future), so I am happy we have been giving those a thorough test. >> >> I would go ahead and push those artifacts as soon as you feel is >> appropriate. >> >> >> On 12/08/2017 02:33 AM, Georg Kallidis wrote: >>> we may indeed decide to proceed to Turbine 4.0.1, but we have to keep > in >>> mind then, that no Turbine Webapp would exist ready at hand to test >>> Turbine 4.0. Turbine 4.0 could be used in many, if not most parts. For >> the >>> security services you could use Fulcrum instead of Turbine (cft. to the >>> test examples), the one exception is permission revoke/grant, which > must >>> be fixed in Fulcrum. Of course we may find other fixables. >>> >>> If cancelling this release, we may then update NOW (after deciding >> process >>> is finished) Turbine Webapp to be based on Turbine 4.0.1-SNAPSHOT and >>> Fulcrum Security 1.1.2-SNAPSHOT. As a result we have to release 4.0.1 >> and >>> 1.1.2 before the next Turbine Webapp 1.0.2. Then we may (or may not) >>> include the Turbine - Flex module!? >>> >>> Best regards, Georg >>> >>> >>> >>> >>> Von: Jeffery Painter <[email protected]> >>> An: [email protected] >>> Datum: 07.12.2017 17:59 >>> Betreff: Re: [VOTE] Release: Turbine-Webapp 1.0.2 archetype >>> targeting Turbine4 on staged repository >>> >>> >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [X] -1 no, do not release it because >>> >>> I think we should delay the release until we finish fixing the few >>> remaining bugs in fulcrum-security and also use the patched turbine >>> 4.0.1 core. Then we can point the new archetype at those instead, and I >>> can work on completing the turbine-flux module if you would like to >>> include it. >>> >>> >>> Thanks! >>> Jeff >>> >>> >>> On 12/05/2017 09:20 AM, Georg Kallidis wrote: >>>> Hi all, >>>> >>>> >>>> a release candidate for the >>>> >>>> Turbine Webapp Maven-Archetype, version 1.0.2 >>>> >>>> has been prepared! >>>> >>>> >>>> It contains the archetype for Turbine 4.0 Version. >>>> >>>> Tag: https://svn.apache.org/repos/asf >>>> /turbine/maven/archetypes/tags/turbine-webapp-4.0-1.0.2 >>>> >>>> Artifacts: >>>> >> https://repository.apache.org/content/repositories/orgapacheturbine-1026 >>>> Major changes are >>>> >>>> - Now based on Turbine 4.0! >>>> - Added some more examples (JSON, Localization, ..) >>>> - Schema changed using by default MySQL autoincrement instead of > Torque >>> id >>>> broker. >>>> - JUnit Tests added to generated archetype project (mainly checking >>>> security managers) requiring MySQL, Torque Fulcrum Security and in >> parts >>>> Turbine. Part of the tests may only succeed in Turbine 4.0.1 version, >>> and >>>> are ignored. Tests must be activated manually with mvn test >>>> -DskipTests=false, more info in archetype folder docs/README.txt. >>>> - SLF4J support added >>>> >>>> >>>> Next steps: >>>> - Update to Turbine 4.0.1 >>>> - include Flex (Jar?) into Web App 1.0.3 >>>> >>>> >>>> >>>> Please verify this release candidate carefully and vote! >>>> >>>> [ ] +1 release it >>>> [ ] +0 go ahead I don't care >>>> [ ] -1 no, do not release it because >>>> >>>> >>>> >>>> Best Regards, Georg >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Jeff Painter CEO and Founder of JiveCast Software and analytics, made together http://jivecast.com 301 Fayetteville St. Unit 2301, Raleigh, NC 27601 (919) 533-9024 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
