Mailman auto-approve postings by members of nested lists - mailman

I have an umbrella configuration on mailman, and postings to the top list from members of the nested lists will be held for approval, something I do not want, I want them to be auto-approved. The main problem is that there are email addresses from multiple domains, so a regex sender filter (or a dozen) won't suffice.
Is there any way to accomplish this?

Related

What is a RESTful approach to linking one resource to multiple different resources?

I am working on a small project which consists of a number of resources, including a Person, a Group and a Task. Each Group consists of multiple Person resources. Additionally, each Person can have multiple links to Task, and each Group can have multiple links to Task as well. In somewhat more technical terms, this situation could be described as follows:
there's a one-to-many relationship between Group and Person
there's a one-to-many relationship between Person and Task
there's a one-to-many relationship between Group and Task
To nobody's surprise, each of these relationships are also a requirement for RESTful endpoints. In other words, there should be a way to list people in a group, to add people to a group, to add tasks to people/groups, etc.
The relationship between Group and Person is fairly standard in RESTful terms. Something like /groups/{group}/people should do fine, with different HTTP verbs dictating what action should be taken.
Where I'm struggling to come up with a satisfactory solution are the relationships between a Person and a Task, and a Group and a Task. In the context of the project I'm working on, a task is a task and the differences between individual tasks and group tasks are minimal. I suppose that's why I'm struggling to decide which approach would be better in this case.
What I've done so far is completely separate the routes for individual tasks and group tasks. In other words, the project has the following routes:
/people/{person}/tasks
/groups/{group}tasks
I think those routes make sense. What I dislike about them is the code that they lead to. It's lead me to two almost identical controllers and a few other almost identical files used for validation and what not.
Now, something else I've wanted to explore is using one route to create tasks for both people and groups. Something like /tasks would work fine in that case. The difference between this approach and the first approach I explored is where the "link" is coming from - the first approach has the URL specify if it's an individual task or a group task, and the second approach would receive that information in the request body (e.g. either a person_id or group_id would have to be set, but not both at the same time). What this means is that the second approach requires one controller, but with additional logic to "route" between people and groups.
If I'm being completely honest, I'm probably overthinking this. But this is something that I've had on my mind for a while now and could never figure out which is "more RESTful." I'm curious to hear what other people think and thankful for everyone's two cents.
I would just make a class from the reusable part and include it to the Controllers. Afaik. PHP is object oriented, so you can do it with it. Another way of having a single Task class with an assignedTo property and set a Person or a Group there or if PHP is strongly typed then some sort of interface e.g. iAssignable to both. Another way is inheritance or composition with the common part of PersonTask and GroupTask if the difference is more than the upper. So this is rather an OOP problem of code reusage and not a REST problem as far as I understand.

Entity groups in dialogflow cx

How would you approach a problem where a user can order multiple objects which each can have entities associated
For example with a user utterance
"I want to order a large pizza with pepperoni and a small pizza with ham and pineapple"
I would want to
Recognise two distinct pizzas
The different size for each pizza
The topping associated with each pizza
I know Rasa has an option called entity groups which can handle this but does dialogflow cx? Or is it better to design a conversation flow that manages the conversation in a way that doesn't allow this sort of input?
You would have to use a form parameter in your page collecting your pizza order. You can see in the form parameter documentation that there's a boolean option for each parameter of the form named isList that collects multiple instances of a particular entity type you specify, which in your case I assume it would be the entity pizza.
For the example your provided ("I want to order a large pizza with pepperoni and a small pizza with ham and pineapple"), you can use numerical indexes in the intent parameter names in the training phrase annotations.
The annotations may look like this:
Numerical indexes will allow you to understand how many pizzas were ordered.
Extracted parameter values for this annotation will look like this:
For this proof of concept, the fulfillment is defined as conditional response:
You can define more sophisticated dynamic responses in your webhook.
Note that if you opt for this approach, you will need to add multiple diverse training phrases and annotated all of them consistently. Check out agent design best practices.
An alternative approach – collecting parameter values one by one via required form parameters – has various advantages:
you don't need to add and annotate training phrases
parameter value extraction may be more accurate.
In form parameter prompts, you may need to instruct the end-user to responds with only one piece of information at a time.

find all HealthcareService resources for a given Practitioner - fhir search

I'm struggling a bit with reverse chaining in fhir search.
I can find all PractitionerRole resources for a given Practitioner with:
[base]/PractitionerRole?practitioner:Practitioner:id=100
How do I combine chaning and reverse chaining to find all HealthcareService resources for a given Practitioner? I tried the below and some variations of it.
[base]/HealthcareService?_has:PractitionerRole:practitioner:Practitioner:id=100
I would use:
[base]/PractitionerRole?practitioner=100&_include=PractitionerRole.service
It's more likely to be supported, and would also give you the roles in which the Practitioner is associated with the service.

How to store an arrays within a PersistentVector item?

I'm attempting the Bucket List Design challenge here:
https://github.com/near-examples/workshop--exploring-assemblyscript-contracts
In the notes it says there is one model Activity, and this should include a PersistentVector for a list of friends.
My activities are stored as a PersistentVector, so this would mean a nested PersistentVector with the Activity model - it seems this would not be possible. Am I missing something, or is this maybe designed to create a bit of thinking?
It’s certainly possible to have a PersistentVector<Activity>, and inside each activity have a PersistentVector<string> with friends. However, using this datastructure, I think you end up with a shared list of friends for all activites (unless you use a unique prefix). If you use PersistentVector for your activities, then it’s possible to use a regular list (string[]) for your friends to isolate it inside one activity. Otherwise, you would need to store the PersistentVector of friends using the id of your activity (maybe as the unique prefix like below)
friends: PersistentVector<string> = new PersistentVector<string>(uniqueIdOfActivity);
I haven’t tested my hypothesis yet, but as far as I understand, a PersistentVector is just a helper to use the storage

Can any element of a FHIR resource be used as a search parameter?

Is use of search parameters limited to the common search parameters (ie. _id, _text) and those defined at the bottom of each resource definition? For instance, family, that's defined on the Patient resource # https://www.hl7.org/fhir/patient.html#search.
I'd like to know if it's possible to use any element of a resource directly as a search parameter? For example:
to search ImagingStudy with more than 3 series: /ImagingStudy?numberOfSeries>3
to search ImagingStudy with any series with ONLINE availability:
/ImagingStudy?series.availability=ONLINE. This is similar to Complex Type filter from Odata (http://www.odata.org/getting-started/basic-tutorial/#filter), where the same query could be written in OData as /ImagingStudy?$filter=series/any(s:s/availability eq 'ONLINE')
Following added on 2015-11-28:
Our server is a read-only service that aggregates data from various source systems and implements an API based on FHIR. Here are some interesting facts and challenges about the infrastructure:
Most of source systems can only provide primitive query capability,
for instance, filter by date.
We are not able to create indexes as we do not own the data repository.
In a typical scenario, we would first retrieve the date filter from the client's request and use it to reduce the amount of data that needs to be returned by a source system. Then our service will process the remaining filter, sorting, and paging on the aggregated result.
As an example, we have a requirement to implement string searching against ImagingStudy.procedure.code.coding[].display.
It is nice to know that server has the ability to define extra search parameters in the conformance statement; however, for our scenario, the search parameters are mostly driven by the clients needs. Any change or update to this needs could trigger a change to the server's conformance. This makes the conformance/contract vulnerable to changes.
This is the motivation that prompted my question, that since FHIR client and server already have a well defined contract defined via FHIR resources, would it be possible to extend this contract for search parameters, where the client and server will be able to leverage the existing object graph of the FHIR resource as the search parameters without having to define a separate list.
The search parameters are defined separately and mapped to actual paths within the resources to allow servers to maintain indexes via something like map/reduce rather than execute the queries long hand against unindexed content. You cannot simply query against arbitrary paths in the resources. Note: This includes the _filter search parameter.
Servers are allowed, however, to define their own search parameters and map these to arbitrary paths in the resources. If the server exposes a search parameter, it should declare it in the conformance statement, and then you'll know whether you can use it or not.
(btw, Servers are also allowed to choose not to use map/reduce, and to execute the queries long hand, and therefore to allow any path to be used as a parameter, if that is an effective strategy for their technology base - though I don't know of one that does this.)

Resources