Requests

Paying

A request is considered to be payable if its status is payment and it does not have an active crowdfund. A user can pay for a request if they can edit the request and if it is payable.

Payments are made to the <request>/pay endpoint and crowdfunds are created at the <request>/crowdfund endpoint. To make a payment, POST a valid Stripe token, an email, and an amount to the payment endpoint. To make a crowdfund, a valid CrowdfundRequestForm must be submitted. When making a payment, a 5% fee is added to the payment amount. When creating a crowdfund, a 15% fee is added to the crowdfund goal.

Sharing

A request may be shared with other MuckRock users. There are three roles for sharing: creator, editor, and viewer. There are two permissions for sharing: read and write. A viewer has permission to read. Creators and editors both have permission to read and write. A creator is distinct from an editor in that a creator may never have their permissions changed, while an editor's permissions may be changed.

Anyone with read permission may view a request under embargo.

Changing roles

Anyone with write access may add an editor or viewer at any time. Anyone with write access may demote an editor to a viewer. Anyone with write access may promote a viewer to an editor. Editors may also revoke their own access, if they choose.

Private URLs

An editor or creator may generate a private URL if the request is under embargo. This private URL is the regular request URL with an extra key argument. As long as the key in the URL matches the key saved to the request, anyone (even a logged out user) may view the request despite the embargo. Each time the private URL is generated, a new key is randomly generated.

Embargo

An embargo keeps a request private. Embargoes serve the needs of our journalist users, who may want to keep their research private until their story is published (don't scoop our own users!). Staff, pros, betas, proxies, and org members have permission to embargo requests. Staff and organization members may apply a permanent embargo.

Setting an embargo

Embargo should be allowed if the user can embargo and edit the request. Users without permission to edit the request should not be able to change the embargo. Users without permission to embargo should not be allowed to set one. When an embargo is set, all the followers of a request should be unsubscribed.

Updating an embargo

The embargo should be able to be updated. If the request is in a closed state, it needs a date to be applied. A request with a permanent embargo should stay embargoed indefinitely.

The default and maximum duration for an embargo is 30 days. End status where an embargo expiration date are required are rejected, no_docs, done, partial, and abandoned. If the request status is changed to an end status and it is embargoed, set the embargo expiration date to its default duration. If the request is then changed to a different end status (e.g. from partial to done), the existing expiration date should not be changed. The embargo date should be removed if the request is changed to a non-end status.

Removing an embargo

The embargo should be removable by editors of the request. Any user should be allowed to remove an embargo, even if they cannot apply one.

Every day at 00:00 (midnight), a task will be run that removes expired embargoes. Any requests with an embargo date before today should be unembargoed. Only after the embargo expiration date passes should the embargo expire. An embargo without an expiration date should not expire.

Dates

Dates are calculated when a request sends or receives a communication:

• If date_submitted is None, this is the first submission:
  • Set the date submitted field to today
  • Set date_due to the number of business days from now, based on the jurisdiction.
• If status is either awaiting acknowledgment or awaiting response, then what?:
  • If days_until_due is set, set it to None. Then set the date_due to that many business days out.
  • Set the followup date:
    • The new followup date is tentatively (estimated completion date if there is one, 30 days if federal, 15 days otherwise) out.
    • If there is a date due and it is further out in the future than the follow up date, then the date due is the new follow up date.
    • If there is already a follow up date and it is further in the future than this newly calculated date, do not update the follow up date.
• If the status is not awaiting acknowledgment or awaiting response, remove the follow up date and disable auto followups.
• If the status is fix or payment required and there is a due date:
  • Remove the due date, and count the number of business days between the last response date and the due date. Set days_until_due to this number of days