<div dir="ltr">Another big topic; worthy of it's own thread. :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 9:30 AM, Monica Granfield <span dir="ltr"><<a href="mailto:mgranfie@redhat.com" target="_blank">mgranfie@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am not sure we are including roles, although I would think they are useful, as they are basically pre-packaged/template permissions for reuse.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 31, 2016 at 9:25 AM, Leonard Dimaggio <span dir="ltr"><<a href="mailto:ldimaggi@redhat.com" target="_blank">ldimaggi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>P.S. wrt to teams - are we thinking about defining roles for users - where each role definition consists of permissions to perform specific tasks?<br><br></div>--Len D.<br></div><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Oct 31, 2016 at 9:18 AM, Thomas Mäder <span dir="ltr"><<a href="mailto:tmader@redhat.com" target="_blank">tmader@redhat.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-7731852264062827716h5">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    Hi folks, I've tried to write up what I think project features are
    going to be in almighty in the future. I've tried to enumerate
    things that seem relevant to how we implement projects in the short
    run. Once again, I would invite interested parties to read through
    this and point out where my understanding is wrong or not complete.
    Next step would be to define what we need to do next to introduce
    projects.<br>
    <br>
    thx, <br>
    <br>
    /Thomas<br>
    <h1>Project functions</h1>
    <p>Based on the PDD and <a class="m_-7731852264062827716m_27940310091398210m_-2789146968678269397moz-txt-link-freetext" href="https://github.com/almighty/almighty-core/issues/357" target="_blank">https://github.com/almighty/al<wbr>mighty-core/issues/357</a>,
      I see the following roles for projects in almighty:</p>
    <ul>
      <li>Process Configuration<br>
        1603E130 & 1603E131 imply that for each project, there is a
        configuration of allowed work item types. I would also expect
        process workflow (states, transitions, permissions) to be
        configured at this level. This requires a way to specify the
        configuration when creating a project. The PDD sees the creation
        of new configurations as a admin level task available to the
        operators of the service, not something that users of the
        service can do. For the user, it would be as simple as selecting
        a "project type" when creating a project. We would have to
        create a configuration and migrate our existing work items into
        that project.<br>
      </li>
      <li>Work Item Owner<br>
        This implies that a work item is a all times associated with
        exactly one project. Deleting the project would imply that the
        work item is deleted as well. It is not clear whether moving a
        work item would be allowed. However, the target project of a
        move might not allow the work item type of the moved work items,
        so at least we can say that it is not always possible.  <br>
      </li>
      <li>Partition<br>
        Since we expect to have a very large number of work items and
        links between them, we might have to partition the system in
        some way for performance reasons. Keeping work items and links
        local to a project would bring down the number of expected
        instances to a couple of 100k. Naively, this would prevent us
        from doing work item links across project boundaries and global
        searches (what are all the work items being blocked by this one?
        What are all bugs filed by Max Andersen?). However, we could
        replicate information of cross-item links in both projects. We
        could treat searches across projects as a special case and
        offload it to a near-realtime indexing service ("Google for
        mighti").<br>
      </li>
      <li>Permissions<br>
        Projects are the object of permissions, meaning that permissions
        are expressed in terms of projects: "Thomas is allowed to create
        issues in Project 'ALM Core'".</li>
      <li>Team(s) container<br>
        One or more teams will be associated with the project. This is
        not only a permission issue: one might use this for
        communication (team chat) or to determine who a work item can be
        assigned to. At the same time groups of users are traditionally
        what permissions are granted for. If we have general notion of
        "groups of users", it would make sense to associate multiple
        "teams" with a project: administrators, contributors, "guests",
        etc. These groups would be created with the project and assigned
        a default set of permissions.<br>
      </li>
    </ul>
    <h1>Other topics</h1>
    <ul>
      <li>Nested projects<br>
        <a class="m_-7731852264062827716m_27940310091398210m_-2789146968678269397moz-txt-link-freetext" href="https://github.com/almighty/almighty-core/issues/357" target="_blank">https://github.com/almighty/al<wbr>mighty-core/issues/357</a>
        introduces the notion of nested projects ("projects owning
        projects"). I am not sure where in the PDD this is mandated. It
        would introduce complexity with permissions and process
        configuration (unless they are a restricted form of project).
        Unless necessary, I would not introduce this concept<br>
      </li>
    </ul>
    <br>
  </div>

<br></div></div><span>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
<br></span></blockquote></div><span><br><br clear="all"><br>-- <br><div class="m_-7731852264062827716m_27940310091398210gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Len DiMaggio (<a href="mailto:ldimaggi@redhat.com" target="_blank">ldimaggi@redhat.com</a>)<br>JBoss by Red Hat<br>314 Littleton Road<br>Westford, MA 01886  USA<br>tel:  <a href="tel:978.392.3179" value="+19783923179" target="_blank">978.392.3179</a><br>cell: <a href="tel:781.472.9912" value="+17814729912" target="_blank">781.472.9912</a><br><a href="http://www.redhat.com" target="_blank">http://www.redhat.com</a><br><a href="http://community.jboss.org/people/ldimaggio" target="_blank">http://community.jboss.org/peo<wbr>ple/ldimaggio</a><br><br><img src="http://www.redhat.com/g/logos/RedHat_JBoss_logo.png"><br></div></div></div></div>
</span></div>
<br>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com" target="_blank">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/almighty-public</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
almighty-public mailing list<br>
<a href="mailto:almighty-public@redhat.com">almighty-public@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/almighty-public" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/almighty-<wbr>public</a><br>
<br></blockquote></div><br></div>