... and one other thing. as i'd mentioned about user_service.browse_articles() vs. article_service.with_author()... unfortunately that can't be bidirectional as DI can't permit user_svc -(relies on)-> article_svc -(relies on)-> user_svc
frispete joined the channel
frispete_ has quit
chrisw joined the channel
energizer joined the channel
Ergo
dfee: sounds like you do something very similar to what I did with ziggurat_foundations
dfee
Ergo: checking that out now thanks for passing it along
Ergo
i had resource class with polymorphic inheritance in sqlalchemy and user object
they had methods that solved directionality issue that you have if I understand correctly
brokencycle has quit
dfee
Ergo: are permissions confined to models, or can they be used for fields, too?
Ergo
for fields of models?
in my case i have permissions related to resources, and resource-less permissions too
dfee
user.email_address is visible to anyone who can view the user resource?
i guess what i'm asking is are the permissions tunable to attributes of the resource? but that might be the wrong question here
raydeo
normally that would just be fine-grained permissions on the resource like view_email
pyramid cares about resources... you could model the email as a resource or you're kinda on your own inventing something
I imagine a generic system could do per-field like I suggested with view_email, view_xxx where the resource is the user object itself
your view or proxy or whatever would need to call has_permission per field... as is your right
dfee
raydeo: yeah that's what i had in the code example. the __acl__ included permissions like: [(security.Allow, security.Everyone, ('retrieve:first_name',))...]
as the filtering requirements on relationships are more complex, i feel like relationships don't lend themselves to UI code (say a view or a graphql resolver)
raydeo: i'm also conscience that i might be building myself into a corner here
i'm somewhat trying to get right a module that has a good implementation of: sqla models + acl, corresponding graphql types, services that bridge those two, schemas that validate input, and entity/proxy that is the bag-of-values the service transacts with.
of course, all that wrapped up with pytests that i can scale out across my other modules that are ... less sophisticated
energizer joined the channel
energizer joined the channel
teix has quit
hvelarde is now known as hvelarde|brb
galileo_ joined the channel
Ergo
dfee: Yeah I think you could do it like this but when new columns get added that might become hard to scale in general
dfee
Ergo: i'm kind of combatting DRY, i know.
raydeo
I think it's nice, there's just a lot of legwork to make it happen
dfee
of course, there is the Column.info container that i could throw stuff
a lot of this would be easier if python let you dynamically create functions with named args, named kwargs.
raydeo
there's always eval but if you use it you're a monster
dfee
i found a sol'n a while back that lets you effectively do that with types.CodeType / types.FunctionType (https://stackoverflow.com/a/11292547/465164) but that is pretty ugly
after playing with it for a bit, i kept getting my interpreter to crash. though perhaps it could be argued it's slightly less evil than eval
oh wow, just realized you can indeed change the signature of the method by setting the __signature__ property as described in PEP 362: https://www.python.org/dev/peps/pep-0362/#id13 very cool! this should cut down on some of the nonsense i'm dealing with - having explicit kw-only create / update methods for my services.