Properly use the /allow command to set labels

[gentlementlegen]

          /allow @gentlementlegen time

Originally posted by @0x4007 in ubiquity/business-development#102 (comment)

What happened

After using the /allow command, the user was still able to set all the other labels.

What was expected

The user should only be able to set the labels that were allowed to their account.

How to reproduce

• use an account that has permissions to set labels but is not a collaborator within the organization
• an admin uses the /allow user time command to only allow a user to set the time labels
• that user sets any other label using the UI
• notice that the bot does not revert the user's action

[ubiquity-os-beta]

Note

The following contributors may be suitable for this task:

rndquu

1% Match ubiquity/audit.ubq.fi#16

0x4007

1% Match ubiquity/work.ubq.fi#125

[ubiquity-os-beta]

! Error: Error: No labels are set.

[ubiquity-os-beta]

Important

• Be sure to link a pull-request before the first reminder to avoid disqualification.
• Reminders will be sent every 7 days if there is no activity.
• Assignees will be disqualified after 14 days of inactivity.

[0x4007]

Only collaborators can set labels. The OS should undo a label set if that class of labels isn't white listed, or "allowed"

[gentlementlegen]

I am not sure to understand. Organization collaborators have no restrictions on label isn't it? I thought the scenario was on repositories where you add a user as a collaborator with maintain or write access?

[0x4007]

It's impossible to set labels unless you're a collaborator under normal circumstances.

The ONLY exception to this is if we make an issue template that allows a user to file an issue with pre set labels when submitting the issue.

There is no UI for users to change labels unless they are a collaborator.

---

The scenario we are fixing:

• New team members join (Miguel, vadim)
• Their permissions start at the lowest level (contributor)
• they start filing a ton of proposals and I have to ask them what the time estimates are. Vadim manually writes reasonable time estimates on several proposals, so now I trust that they should be able to directly set the time labels.
• however I still need to review these proposals before they should be able to start and get paid for them, and the way we formalize this is by disabling their capability to set the priority or price labels.
• last year I was able to write /allow @user time for this and any labels prefixed with time can be set without a problem. Any other labels set would be undone by the OS and a warning would be thrown, listing their class(es) of labels they have permissions to set.
• /query also used to display an array of label classes they were able to set.

remarks

It's been a long time since I thought about the ergonomics of this command. After writing all of the below I'm having second thoughts because in practice we generally allow everybody to set time labels but want to only allow some people to set priority. Perhaps the simplest solution can be to only allow admins and billing managers to set priority. That way we can ditch the /allow command entirely.

As the business development team matures and Miguel + vadim prove that they set reasonable time and priority levels, then their promotions go as follows:

1. start as contributor (no label access)
2. added as collaborator (can set time)
3. added as billing manager (can set priority)

---

Last thought on self assigns but we should follow the same "promotion system" and only allow admins/billing managers to self start on GitHub issues without a price label using the UI.

OS can immediately unassign non admin/billing managers collaborators if the GitHub issue is not priced.

[0x4007]

Deprecated in favor for ubiquity-os-marketplace/daemon-pricing#62