DOOR filter for elements and macros (SF#78)

[sf-migrator-bot]

Create a DOOR filter to reduce the list of elements and macros available for the user from that DOOR.

F.ex.: Avoid access to some motors or to avoid running expert specific macros

Reported by: gjover ( http://sf.net/u/gjover )

Original Ticket: sardana/tickets/78

[sf-migrator-bot]

• status: unread --> waiting
• assigned_to: Zbigniew Reszela

Original comment by: reszelaz (http://sf.net/u/zreszela)

[sf-migrator-bot]

• Milestone: Jul14 --> Jan15

Original comment by: cpascual (http://sf.net/u/cpascual)

[sf-migrator-bot]

• Milestone: Jan15 --> unassigned

Original comment by: cpascual (http://sf.net/u/cpascual)

[sf-migrator-bot]

• Milestone: Jan16 --> unassigned

Original comment by: reszelaz (http://sf.net/u/zreszela)

[LJBD]

As a follow-up to today's mail exchange about this issue, I'm confirming that SOLARIS is also interested in this feature, exactly as worded here: to be able to restrict Door's access to certain Sardana elements. I guess that the issue will become high priority for us in the next 3 - 4 months.

A comment to Manu's suggestion: we've never used Tango Access Control at SOLARIS, but if it facilitates developing this feature we might give it a try. Unfortunately, it doesn't look like we can put resources there during the next 2 - 4 weeks.

[reszelaz]

I have a feeling that implementing this feature on the macroserver level will be much more straightforward than implementing it on the door level. Then to use it, multiple macroserver devices would need to be defined - they can be even exported by the same server.

The effect of the filtering should:

1. In macros: make invisible to the macroserver the elements that are filtered e.g. lsm will not show filtered motors, macro calling self.getMotor(<filtered_motor>) will raise an exception.
2. In spock: do not advise the filteredelements when using tab completion.
3. In the taurusgui do not populate the instrument panels with filtered out elements.
4. In macroexecution widgets: do not show the filtered elements in the parameters combo boxes.

With respect to the 1st point, the user will still be able to obtain the proxy to the filtered out element using directly the PyTango or taurus.

With respect to the 3rd point, the user will still be able to add a filtered element to a form or trend using the model chooser manually.

The proof-of-concept implementation could simply filter out elements in the on_elements_changed method of the Pool’s taurus extension class . This of course will not filter out macros, but I think that filtering macros is much easier to implement and we could treat it later.

We also need to decide how to define the filters:

1. What will be the filter syntax (I would use the regular expression patterns as the filter format).
2. The filters will be applied on the normal names or the full names?
3. The filter should describe what we want to filter out or describe what we want to allow.
4. Do we want to define them on each element type level i.e. different filters for motors than for experimental channels, or measurement groups?
5. How do we define the filters e.g. the MacroServer tango device properties.

[dfcarreiras]

I Zibi, I agree. Implementing the "filters" at the level of the Macroserver looks like the best option to me as well. We would need to add the concept of "Configuration of the Session", i. e. the configuration of that device of Macroserver. In this configuration the filters can be defined (or directly the list of motors, counters, detectors, triggers, ... available). Macros would not be necessary (although it doesn't hurt) because the device will have defined its own macro paths in (as properties). The init of the device (macroserver) could configure (import) the core elements and the elements that have been configured, i.e. are on the list (or not been filtered out, i.e. match a RE). A macro "(re)config" could go through the whole process. The issue of "read only elements" seem to me more complicated (please Zibi correct me if I am wrong). These could be kept apart from the first implementation if that is the case and if the community agrees.

[cpascual]

I have a feeling that implementing this feature on the macroserver level will be much more straightforward than implementing it on the door level.

I agree with the intuition that it would be easier implementation-wise... but still it seems that conceptually this should be done at Door level... (but, that said, I do not opose going for the easier implementation)

(...) We also need to decide how to define the filters:

1. What will be the filter syntax (I would use the regular expression patterns as the filter format). ou confirm that, I would go +1 to regexps

2. The filters will be applied on the normal names or the full names?

AFAIK, all sardana elements do have unique normal names (actually, tango aliases)... if it is so, I would go for normal names

3. The filter should describe what we want to filter out or describe what we want to allow.

I think that a combination of whitelist and blacklist (interpreted in this order) is the best. e.g., The defaut would be: blacklist = None whitelist = .*

4. Do we want to define them on each element type level i.e. different filters for motors than for experimental channels, or measurement groups?

I think it is not worth... regexps should be enough for discriminating even if done only at general element level (and doing it specific may increase the burden when adding new types). But I wouldn't oppose an implementation based on types (in such case, I think there should be both APIs implementations, general and per-element type)

5. How do we define the filters e.g. the MacroServer tango device properties.

Whatever the solution, IMHO it should not be tango-centric, so that we can eventually implement it in a non-Tango sardana

[reszelaz]

• The MacroServer is a natural place to implement the filtering since it is the elements’ container (macros, macro parameter types, macro libraries, etc.). Apart of that it aggregates other containers - the associated Pools. Finally, its API allows to obtain the elements from a union of all the containers.
• So let’s use the regexp in the implementation and for the moment have a general filter for all the elements (also coming from different Pools).
• I like the idea of having black and white lists. This way it will be much easier for the user to define the filters.
• I think that filtering of macros will also be necessary cause some of the allowed and not allowed macros may be defined in the same modules. Basing the filtering mechanism on the MacroPath would require splitting this module into two. I think it is not “expensive” to implement it, but we could do it latter of course.
• I agree that implementing the “read only” filtering is much more difficult. Let’s leave it for the future then.

I have done a very naive proof-of-concept by placing a simple string comparison in the on_elements_changed method of the Pool’s taurus extension class. And all the four cases mentioned in my previous comment were successfully filtered. One tiny detail is that the macro API method getMotor, does not raise an exception, but return a None object, in case one tries to obtain a filtered motor. But I think it is acceptable.

[pjb671]

Hello all, Following a discussion by email with Zibi and Teresa, I would like to say the MaxIV beamlines are also interested in this development. They do not mind how it is achieved, but the result should be the ability to hide certain motors from non-experts (ie from the beamline users but not from the staff.) In case its of interest for others, for now we have achieved this by putting all user motors and experimental channels into a user pool, and expert motors into their own pool, that has no experimental channels. Then the users use the user macro server connected to the user pool, and experts use an expert MS connected to both pools. This allows motors to be hidden, but not experimental channels (which is less important anyway.) Also you cannot hide the physical axes of psuedomotors like this.