•  
     
    story #13230 setup the contributor semantic for one user bound list field
Summary
Empty
setup the contributor semantic for one user bound list field

As Tuleap developers we can make the setup of the whole story (new semantic, permissions, TQL, XTS, widget) for a simple use case.

It's important to understand that this first story is not at all meant to be really usable by a end user. It's main purpose is to "touch" the whole stack of what should be modified by the epic but on a very limited subset of feature already under control because it's pretty much what we are doing for "regular" Contributor semantic.

The whole feature is hidden by a feature flag in local.inc for tracker administrators. Once activated for a tracker, all users "see" the feature. As it's behind a feature flag, the tracker cannot be inherited (either from tracker picker at tracker creation or as part of a template project).

Functional overview

Contributor semantic

In order to introduce this first step as light as possible, at this step, the "Contributor" semantic is re-used "as is" (tracker admin has to selection a field for that) but there is a toggle (hidden by a feature flag) that turn this Semantic in "automatic" mode. The automatic mode is meant to gather all user/groups fields on the longer term but at this step, it's a way to implement it as a baby step while having a field that "means" something (the alternative would have be to pick one field randomly, that was not really usable).

Once set to "automated", it's no longer possible to switch back to "regular" semantic (one field). It's mostly an arbitrary, technical, constraint to avoid having to manage the switch on/off consequences on the whole stack. As we don't see it as a nominal use case, we prefer to prevent it and to implement that later on when the need actually arise.

It's not possible to switch to "automated" if there is already a permission set to "have access to all artifacts assigned to group" or "have access to all artifacts submitted by or assigned to group". Tracker admin must remove them first.

There is a link from "Contributor" screen to "Tracker Permissions" screen to ease the switch.

Permissions

Once the "automatic" semantic is set:

  • It's no longer possible to select "have access to all artifacts assigned to group" or "have access to all artifacts submitted by or assigned to group"
  • There is a new "Role based permission" section (as in epic mockup) section

In the "Role based permission" section, the new perm can be activated. When activated, the permission of the artifact is enforced in

  • Artifact view
  • Modales
    • v1 in tracker
    • v2 "Agile Dasbhoard home"
    • Angular
  • CSV export
  • REST
  • reports
    • table
    • charts
    • cardwall
  • Kanban
  • Scrum
    • Planning
    • Overview
    • Cardwall
  • Cross tracker search
  • TTM
  • Baseline
  • Timetracking

Tracker TQL

Tracker TQL is enhanced to support `@assigned_to` (or maybe @contributor ?) syntax with all related features

  • @assigned_to
  • operators: =, !=, IN, NOT IN
  • expr
    • `username`
    • (`username1`, `username2`)
    • MYSELF()

Cross Tracker Search TQL

Ensure existing `@assigned_to` works with the new behaviour (there should be no change here).

However, the pre-query checks are made more strict to ensure all tracker selected in the query have the "automated contributor". Another way of stating is that it won't be possible to mix  trackers with "automated" and "regular" contributor semantic.

It's also an arbitrary, technical, constraint that can be relaxed later if needed but better not spend to much time on supporting that at this point of the development.

My Artifacts Widget v2

As the "my artifact" feature is going to be completly re-think, we make a completly new widget for "automated"  semantic to avoid having to deal with both development at the same time. At the end of the development "My artifacts v2" will include artifacts from the "regular" semantic as well.

At this point, the widget is very limited and doesn't do any performance optimization. It will list all Open artifacts "assigned to" with

  • id
  • title of the artifact
  • tracker name
  • project name

Ordered by artifact id descending (the latest at top) and only the first 30 results.

Technically speaking, it's plain php/mustache with ajax call (no vuejs at this point).

Empty
Geoffroy Grelot (ggrelot)
Status
Empty
Canceled
Development
  • [ ] Does it involves User Interface? 
  • [ ] Are there any mockups?
  • [ ] Are permissions checked?
  • [ ] Does it need Javascript development?
  • [ ] Does it need a forge upgrade bucket?
  • [ ] Does it need to execute things in system events?
  • [ ] Does it impact project creation (templates)?
  • [ ] Is it exploratory?
Empty
Details
#13230
Manuel Vacelet (vaceletm)
2022-05-09 16:29
2019-04-05 17:10
4040

References

Follow-ups

User avatar
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
  • CC list set to Geoffroy Grelot (ggrelot)
User avatar
  • So that
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes