I agree that ultimately the access needs to be controlled at the service tier rather than woven into presentation but I think i created a diversion by mentioning security in with this issue.
What I'm more keen to investigate is a neat way to have multiple flavours of the same functionality and for a ui app to be capable of satisfying the needs of different types of users but without that necessarily being permissions based, more based around what is the view that is relevant for a type (role). I'm saying 'role' here because I'd see that as simplest way to group users together given that we would have those roles available in whatever security solution is chosen for sculptor. To date I've played with lockdown of functionailty using regular JEE declarative authorisation via url-patterns and JEE roles described inside web.xml - i completely agree thats not the total solution for authorisation but it gives me a way to move forward now with current version of sculptor. Using that approach i can lock down flows as needed but more to the point I'm logically assigning some flows as being relevant particular roles (irrespective of what data content is visible). The example i gave was probably too simplistic but just say we had two different types of admin, one concerned with male persons and one with female persons. They both maybe needed to occasionaly look at detail of the opposite sex (so they are permitted to look at the other data) but in general they wanted a ListPerson to list only persons of the sex relevant to them. You see what I'm after is for a way to do the option like ListTask [male-admin] for Person { .. searchWith PersonService.findAllMales ListTask [female-admin] for Person { .. searchWith PersonService.findAllFemales as well as a 'default' for those users who aren't so 'focussed' ListTask for Person { .. A webapp may have all of the above available together and optionally to be used by any users as they see fit. This highlighting the point that a UI could be needed to expose multiple ways to want presentation of the same UI 'tasks' ie. sharing of control logic for different 'views. Another thought though to enable grouping of those 'related' tasks (eg. to enable simple generation of a male-admin menu as distinct from a female admin menu) would be to enable naming of multiple sculptor 'modules' be defined within a single 'gui' (at present it doesn't look like they can be named, just each being 'for' an underlying domain module). That could be a simplistic way to enable the generation and would be especially neat for partitioning the entire gui into role-relevant spaces. eg. Module male-admin for milkyway { .. ListTask for Person { .. searchWith PersonService.findAllMales Module female-admin for milkyway { .. ListTask for Person { .. searchWith PersonService.findAllFemales or maybe something similar could done up at defn of the 'gui' - though i'd expect that would tend to head us toward mutiple webapps as opposed to side-by-side modules inside a single webapp. Also obviously that last one could be achieved by simply defining multiple discrete gui's - which incidentally seems like the way i might head with this stuff in the short-term. Thanks heaps for your feedback guys - also should say the acegi/spring security will be great to have so pls don't misinterpret my comments above, just that my burning need is a way to re-use various UI tasks PaloT wrote: > > Some of my ideas: > - we have to consider supporting security on different levels: > - Service access (easy with Spring security and annotations or xml > config) > - Column access (read, write, search privileges) > - Row access (read, write, delete, create privileges) > > Row access: > Should be done in user code in services (find, save, ...). > > Column access: > With existing paging support isn't problem to simply nullify columns > in find service which can't be accessed by some users. I don't know if > hibernate somehow directly support this. > > My opinion is that you HAVE TO implement security on service tier not > VISUAL tier. Of course hiding columns for visualization purpose is > good feature. > > I guess you need "hint" feature also for Sculptor GUI because with: > ListTask for Person { > name.first > birthDate hints="role=admin, advisor" > ssn hints="role=advisor, accountant" > sex > } > and little tweak in SpecialCases you will be done ;-). > > Security is difficult because you can SLOW down your application too > much. That's why on this level is usually custom build. > > Regards > > Pavel > > 2010/4/21 Andreas Källberg <andreas.kallb...@gmail.com>: >> Hi, >> Nice suggestions, but you are a bit ahead of us here. >> There is plans for supporting authentication and authorization. When that >> is >> in place it would be nice to have dsl support for user roles. >> I guess it also could be possible to have multiple variations of tasks, >> i.e: >> ListTask for Person { >> name.first >> sex >> } >> ListTask [admin] for Person { >> name.first >> birthDate >> ssn >> sex >> } >> >> But it isn't something we have discussed >> If you feel it is something we should consider, think it through and add >> a >> suggestion in the tracker. >> >> .../Andreas >> >> On Wed, Apr 21, 2010 at 1:31 PM, greatfooty <greatfo...@gmail.com> wrote: >>> >>> I'm playing with setup of a sculptor site to contain multiple versions >>> of >>> various UI task-types (these to be invoked depending on auth role of the >>> user). >>> >>> For example I'd want to define a 'public' ListTask for Person like >>> this: >>> >>> ListTask for Person { >>> name.first >>> sex >>> } >>> >>> and an 'admin' ListTask for Person like this: >>> >>> ListTask for Person { >>> name.first >>> birthDate >>> sex >>> ssn >>> } >>> >>> Thats a simple example and obviously i can achieve this particular one >>> by >>> doing say role-based suppression of output within the list_include.html >>> but >>> there can be many more complex examples where declarative definition in >>> the >>> DSL would be way easier. >>> >>> Is there already any way to do this? eg. maybe some hidden DSL options >>> for >>> naming tasks?? >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/-Sculptor--Multiple-UI-tasks-per-%27task-type%27--tp28288008s17564p28288008.html >>> Sent from the Fornax-Platform mailing list archive at Nabble.com. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Fornax-developer mailing list >>> Fornax-developer@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/fornax-developer >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Fornax-developer mailing list >> Fornax-developer@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/fornax-developer >> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Fornax-developer mailing list > Fornax-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/fornax-developer > > -- View this message in context: http://old.nabble.com/-Sculptor--Multiple-UI-tasks-per-%27task-type%27--tp28288008s17564p28323801.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------------ _______________________________________________ Fornax-developer mailing list Fornax-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fornax-developer