I'm not sure about the untag semantics. It would fail in this case. Does it make sense to test also fromtag if it exists? Isn't it a) confusing b) usable? For b it would mean that policy from the issue would work only if both tags are sidetags owned by the caller.

@mikem @ignatenkobrain ?

I'm not sure about the untag semantics. It would fail in this case. Does it make sense to test also fromtag if it exists?

With the other tag based policy checks (actually, it appears there are only tag and fromtag, plus buildtag but that's a different situation really), there is a separate test to consider the fromtag value. I suppose the test could take an argument. Note that move operations have both tag and fromtag values.

If someone is writing a policy and they care about builds coming from side tags, then you need a way to make the test specific for the move case

For my use-case, I want to give owners of sidetags freedom - meaning if they want to untag anything from their side-tag, they can. That means the logic should be if any of tag or fromtag match user, it should pass.

Added argument source/target/both - is the naming reasonable?

Added argument source/target/both - is the naming reasonable?

I'd rather not use the term "target" here, as it could create confusion with build targets

You have "target" looking at fromtag, which is backwards.

The stanza converting arg to action seems overly verbose given that it's basically just setting action=arg and checking that action is in the allowed set.

I'm not sure if "action" is the best name for this var either, since it's not really an action, more of a value/location to check.

values = self.str.split()[1:]

I think the name value here is overly generic and may have contributed to the typo below

for value in values:
    if value not in data:
        return False
    tag = get_tag(value)

It's the corresponding value in the data dict we want to pass to get_tag.

Maybe key or field instead of value here? E.g. tag = get_tag(data[field]). Other policy tests use field in similar way.

:thumbsup:

Commit d324f601 fixes this pull-request