Channel properties 'owner' is always inherited from original Property creator about recsync HOT 13 OPEN

That is intentional.

The idea is that e.g. specific physics properties of magnet power supplies (the fact that it is being part of a certain bump configuration) should be owned by the physics group, not the power supply group.
Or specific properties for BPMs that say "is being used for global orbit correction" should be owned by the beam steering people, not the diagnostics people.

But I certainly see that other properties like "color of the mains cable" should be owned by the device specialists, as there is no cable color group.

from recsync.

@ralphlange, some context:

We are planning to use infotags to populate CF properties. The target application consuming this the Archiver Appliance.

So, a record in a IOC specifies, info(archive, 'scan: 10'), then cfstore picks this up and creates a property for that record in ChannelFinder. But, if that property was initially created by ioc owner 'xyz, then all channels that have that property will indicate that that property's owner is 'xyz', even if the owner is actually 'abc' (or 'wtf', or 'omg', or...).

I don't think this is harmful in this instance, just surprising and misleading. But, I also think that the link between 'owner' and permissions policy is kinda weak. Is there business logic in CF that cares about 'owner' permissions and is capable of enforcement?

from recsync.

Well, in your case the owner could be 'archive' for all archiving related properties, shouldn't it?

Sure enough there is business logic in the CF web service that only allows changes/renames/deletes of channels and properties for authenticated users that are belonging to an LDAP group matching the 'owner' of the items. Can be switched off (so I am not sure if it applies to your installation), but this is certainly implemented and extensively tested in the unit tests. (There is also an admin user with all rights.)
Of course I don't know if cfstore goes through the web service, or if it is sneaking data directly into the back end store (which it shouldn't).

from recsync.

@ralphlange thanks for the synopsis.

FYI, cfstore does not circumvent the web service.
But, it does look like it's mishandling the assignment of per-channel property 'owner'.
IMO, the channel property owner should (in most cases) be the owner of the channel, not the creator of the property.

I'd be happy discussing this and catching up in person, if you're going to be at ICALEPCS in October. Perhaps over some fine Spanish vino?

from recsync.

No ICALEPCS for ITER staff, as we are not allowed to publish at JACoW conferences due to copyright issues.

I would say there are two kinds of properties:

1. Across-channel properties, e.g. ones set by physics or operations. These should be owned by physics or operations and not be changeable by powersupply or cleaning staff.
2. Local channel properties, e.g. ones set by the database designer. These could be owned by the channel owner, or a functional group ('database'? 'epics'?).

from recsync.

No ICALEPCS for ITER staff, as we are not allowed to publish at JACoW conferences due to copyright issues.

To this I say, "booooooo"!

I would say there are two kinds of properties:

Across-channel properties, e.g. ones set by physics or operations. These should be owned by physics or operations and not be changeable by powersupply or cleaning staff.
Local channel properties, e.g. ones set by the database designer. These could be owned by the channel owner, or a functional group ('database'? 'epics'?).

Right. I'll maybe propose something along the lines of a 'cfstore' group, as that's the entity doing the CRUD operations here.

If there is no further discussion on this over the next few days, I'll close this issue and make some noise elsewhere.

from recsync.

Tangential, but for the record. I don't like the CF ownership/permissions model either. imo. this is major step in the barrier to entry for new application developers.

The alternative I've proposed (to @shroffk at least) is to introduce the idea of scope instead. The same property may exist in multiple scopes. A particular request will have an ordered list of scopes to search. The key point being that every user could have a personal scope as a sandbox.

from recsync.

I don't see how the scope idea relates.
The key point was to allow 'foreign' properties on a channel that can only be changed by the property owner, not by the channel owner.

from recsync.

To expand. I would drop the idea of ownership per channel or property. The only ownership would be per scope. In the context of cfstore, the only question would be which scope to (attempt to) operate on. Some daemon configured default, or a per-IOC/record/info override.

Understand. What I saw during nsls2 commissioning has led me to conclude that the current, granular, permissions scheme was a major contributor for the small uptake of CF. This scheme arises from a desire/need to curate the global namespace for properties. This will indeed be necessary when CF has many users. Of course this hasn't happened yet. I see this in part due to the hassle of figuring out permissions. I would address this by splitting up the single global namespace, and consequently reducing the need for curation.

Also, in my suggestion of using a prefix "cf:" for info() tags, I'm trying to make it easier for individual IOC owners to take the initiative to try new properties to see what is useful.

from recsync.

When CF was developed, there was an explicit requirement, driven by the importance and significance of the directory data, that there should be authN/authZ in place to effectively protect someone from accidentally deleting someone else's data.
How would that be implemented using scopes?

from recsync.

In the extreme case, only one user has permission to alter each scope. A user and/or application author chooses which scopes to include (and trust). Other scopes are invisible.

from recsync.

Wouldn't it be confusing for the directory to have multiple properties of the same name on a channel, with different values, and the client configuration (order of included scopes) determines which one is used?

In my preferred "yellow pages" analogy, that would be a business being labeled as "plumber", "baker" and "urologist" at the same time, and you would have to choose...

from recsync.

One man's plumber is another man's urologist.

from recsync.