story #14600 create full artifact in kanban

  • A new button "Add new <tracker name>"  is added in the button bar (next to Kanban title & "show graphs" button)
  • The visual feedback when the artifact is pending creation, updated and created are changed to be aligned with what is done in Planning view as well as Taskboard
  • When the artifact is created with a status that correspond to a collapsed column, there is a visual feedback on the column
  • After creation, counters and WIP status are updated
  • The creation takes into account real time as well as absence of real time
  • The artifact is created at the end of the column
    • When the artifact is created in a column that already contains a lot of elements, there is little popup message at the bottom right of the screen to inform user (as in Document)
    • When the kanban is used as a widget, the message is also on the bottom right of the screen, even if there are other, unrelated, widgets there
  • When the kanban is filtered, the same constraint and behaviour are applied to "full artifact creation"

story #14570 Authorization grant confirmation page

See epics acceptance criteria. Figma mockup of the page

This story is a technical split that corresponds to the Authorization endpoint form interface to ease track of development.

story #14561 Recertification reminders

Functional overview

- Reminders will be send before the suspension of a project : 

  • month before
  • Every day the week before
  • The last chance reminder

- A Banner will be displayed to alert project members 

- Project is suspended if the grace periode is reached 

story #14558 Recertify a project

Functional overview

Recertification mechanism :

As project owner or site administrator, in  "Project certification" pane under project ownership plugin, I can see a checkbox " Yes, i want to recertify my project and keep it open". 

When the "Submit" button is clicked the  certification is submitted

The certification-date  is then recorded and the next certifications  deadline is displayed. 

Suspension mechanism :

When the grace period is reached the project is suspended in automatic way through the nightly job

 

Permissions

Only project owner or site administrators can submit certification.

All project admins can only read  the certification date and next certification date fields 

The certification is no more allowed if the project has been suspended

 

1923-us2.png

story #14557 Change Project Privacy

Functional overview

As project owner or site admin , i can change the project visibility (public/private/incl.restricted...)  

when i click the submit button the  privacy update will be propagated to db, the next certification date will be recalculated accroding to the new privacy, and an email will be send to all (project members+project owner) 

Permissions

 

If the plugin project ownership is enabled, the project visibility settings configured at site admin level will be ignored 

1920-image.png

In this case site admins and project owner can change the visibility from project ownership interface

 

1922-us11.png

 

and the privacy will be read only in the old access interface 

1924-readonly.png

story #14555 To be removed : Change Project Privacy

story #14552 User preferences goes Burning Parrot

TBD

story #14550 False story to be removed please : Change Privacy

story #14549 False story to be removed please : recertify the project

story #14543 have OAuth2 user settings

See epic's acceptance criteria.

This story is a technical split that corresponds to user's part of the epic.

story #14542 have OAuth2 flow

See epics acceeptance criteria.

The whole thing is a "all or thing" story, here it corresponds to implementation of the OAuth2 protocol flow.

story #14541 have OAuth2 project admin

See epics acceptance criteria.

This story is a technical split that corresponds to Project Admin interfaces to ease track of development.

story #14508 Set remaining effort when it hasn't been set before

When the remaining effort has no value, I can set a value.
I should not see a remaining effort badge on all cards, because for many cards I will never set this value (for example R&D or Tech cards).

Following options have been proposed:

  • Add a button when hovering the card
  • Show a (? => Flag> badge when hovering cards that don't have a remaining effort
  • Have a way to set a remaining effort when editing the card (after clicking on the "edit pen" icon)

story #14482 Project Owner Management

Functional overview

- Ownership transfer : 

case 1 :

  • As project owner and site admin, in the project owner pane,a list of active admins(only ST employee with active status) is dispalyed , when i select a member to be project owner , the update will be propagated to db and fire the owner change email

case 2 :

  • Current owner has been suspended by the nightly job, his manager will inherit ownership of the project (added to the project and promoted as admin)

=>Ownership tranfer notification will be send to the new owner

-Ownership  Creation :

          When new project is created, once validated the requester will be set  as project owner

 

Permission 

- Only project owner or site administrators can change the owner 

 

 

 

 

1916-us3.png

 

story #14470 Support scrolling while dragging

Technical overview

To support scrolling while dragging a card, our drag and drop library must be changed. At the moment of writing, it is based on the drag and drop API. It should instead rely on mouse/touch events or pointer events (the latter does not support IE11).
Drag and drop API suppresses all mouse / keyboard events once a drag has started. We don't want to reimplement ourselves the browser scroll behaviour, which means we must not base the drag and drop library on this API and use the lower-level mouse or pointer events.
Moving to mouse events means writing more code and handling the "drag mirror image" (the image that follows the pointer) manually. It means detecting ourselves when the pointer enters / leaves a potential drop container.

As as side-effect, we will be able to support programmatic cancel() and support cancelling drag when the ESC key is pressed. That was not possible with the Drag and drop API, because there appears to be no way to cancel it programmatically.

story #14430 automate build feedback from jenkins to Tuleap

Built on top of story #14019.

Build feedback (to be used in Pull Requests to inform about PR status) should be sent back to Tuleap automatically by Jenkins as a Jenkinsfile step.

It works when jobs are completely defined manually by teams as well as when Tuleap Branch Source is used.

story #14291 Beautiful tracker creation

Figma

=> https://www.figma.com/file/RaBL0FL199pbWkh7TUJXIrAP/Trackers-service-flow?node-id=30%3A1

Info

  • Description field is not mandatory anymore

  • Be careful with old colors support (XML import…)

  • Tracker name and shortname should be validated on the fly

    • Exisiting shortnames are provided through a data-attribute preventing the user to reuse an existing shortname (if two trackers with the same shortname are created at the same time, the latest will lead to the error case — see below)

  • Shortname is automatically slugified

  • Color selector should use select2 (like in OIC plugin) but with circles for colors instead of rectangles. Only the colors of the new palette are suggested.

  • In case of error : redirect the user to the step 2 with an error feedback

    • In case of tracker creation from an XML file, a new input file is displayed in step 2 with a warning asking the user to reselect the file

Bonus

  • Align the color selectors of the OIC plugin and the one in the new tracker creation (new component ?)

Not Covered

  • "Migrate from TV3" and "Migrate from TV3 with data", if people need to migrate from TV3, they will be using the old interface.

story #14254 have a post action to remove "Scrum Top Backlog" flag

Follow-up for art #14096

Behavior of the "remove from backlog" post-action:

  • It can only be set on artifacts that can be in Backlog
    • Same behaviour regarding the configuration in Agile Dashboard administration
  • It can only remove the flag if the flag can be removed as in story #13998. If the flag cannot be removed, a feedback message is displayed to the user (if the transition happen in artifact view) but the transition is made anyway
    • To be defined: Same TBD as previous
  • if the element is not in top backlog (manually removed) the post-action silently succeed

story #14251 have Real-time update

Functional overview

This story concentrates all the discussions arount the general "real-time update" feature the team had during estimation of the stories.

Technical overview

Edit in place

Given that the "Edit in place" interaction really is an "artifact update" in a general sense, we must be able to handle realtime events for the general case of "artifact updates".
We will introduce the realtime message-sending mechanism here.

We need to send realtime events for taskboard from the Tracker plugin (where the PUT /artifacts/:id route lives). Tracker will send an event (Dispatchable) that the taskboard plugin will listen to. It will then need to detect whether the artifact is used in one or many taskboards. Finally, it will send realtime messages to all the identified taskboard "rooms" to notify front-ends that the card has been edited.

If the "mapped list field" for a card is changed, we will need to send two events:

  1. An event for removing the card from its current cell.
  2. An event for adding a card to a new cell.

This strategy is easier than handling every case of "update" events.

Front-end for Realtime edit in place

In order to have a nice UX for change of "mapped list field" value, we will maintain a cache of "hot cards". Whenever we receive a "removed from cell" realtime event , we will store the card in this cache and hide it from the view.

When we receive an "added to cell" realtime event, if we find the card in the cache, we can retrieve the card from the cache and display it in the new cell. Meanwhile, we will query the taskboard_cards/:id REST route to update the card (potentially, every field has changed as well as the "mapped list field"). When the route answers, we erase the card from the cache and re-draw it from the REST payload.

We will need an animation to have a seamless transition between the two realtime events so that people don't wonder "what is happening ?"

Drag and drop

Reminder of the realtime events:
2 events are emitted:

  • one to remove the card from the cell
  • one to add the card into the new cell

The "add" event should tell us "before" or "after" which artifact id the new card is in the cell. We should not try to reuse global "rank" which is computed in backend, as it is computed dynamically.

When the add event is received, taskboard app should re-query the card to get the complete and up to date data. The fetch of the card can be done with the existing route GET /taskboard_cards/:id. Given that there may be trigger rules between parent and child, the app should also re-query the parent of that card (its remaining effort may now be 0).

When the card is removed, it needs to be placed in a "cache of hot elements" to avoid having to re-query everything to display it again.

Reordering of cards
When reordering cards, we need to have a sensible behaviour. For example, with permissions on artefacts, we might receive a "reorder" event from Realtime "before" or "after" an artifact id that we are not allowed to see. In these cases, we should put the card at the "end" (bottom) of the cell.

  • What should be the UX of realtime addition of addition/removal/re-order of parent items (stories)
    • esp. I'm on my way to drop a card into a given cell but someone is re-ordering the stories so instead of dropping into "Story A", I ended dropping into "Story B".

story #14149 Drag and drop to move a card between swimlanes

Functional overview

Limits (in the first implementation, if the need arise it will be done afterward):

  • There is no multiselect of elements (cannot drag'n drop multiple tasks at once).
  • We do not support drop in collapsed swimlanes (closed stories for instance).
  • Change of swimlane (move a task between 2 stories) can only be done between 2 swimlanes of same type (cannot move a task between a story and a bug).
  • Solo items cannot become a child (a solo task cannot be moved as a child of a story).

Technical overview

Realtime update is NOT included.

This story will need to adjust the existing PATCH /taskboard_cells/{swimlane_id}/column/{column_id} REST route.
In addition to reordering cards in a cell and changing the card status (or mapped field value), it needs to detect and handle a change of swimlane.
In order to remove the artifact link from its old swimlane, a new parameter must be passed in the payload

PATCH /taskboard_cells/{swimlane_id}/column/{column_id} REST route.
{
    add: <card_id>,                    // The artifact id of the card we are dropping
    remove_from: <source_swimlane_id>, // The previous parent's artifact id. The swimlane we dragged the card from
    order: {
      direction: "before",             // "before" | "after"
      compared_to: <card_id>
    }
}

In order to know whether the current user has permission to update the Artifact link field of the swimlanes (both old and new), a new information must be added to the Trackers mappings information passed in DOM to the app:

/* The name may change */
can_update_children: true | false // Does current user have "update" permission on the "artifact links" field for this tracker

When can_update_children is false for a swimlane (parent card), current user will not be able to drop new child cards in that swimlane OR to remove any child card from that swimlane.

The frontend part of the app must prevent dropping a card to a swimlane for the following reasons:

  • User does not have permission to write the artifact link field of the new swimlane or the old swimlane. For example if I drag a task from user story A to user story B, and I do not have permission to write the artifact link, then I won't be able to drop the task anywhere in story B's swimlane.
  • I am trying to drop the card into a parent of a different type, for example I am trying to drop a Task from a User story into a Bug.

story #14131 Have an automatic notification to be sent to the inactive user on suspension day

- Only 1 notification is sent.
- No need for the moment to have dedicated interface at site admin level to customize the email template

story #14095 Collapse "Done" column when I click on "Hide closed items"

See mockup on Codepen: https://s.codepen.io/enalean/debug/615728ad14def79e9b694647c582ce16

Functional overview

When the user clicks on [hide closed elements] then it should also collapse the "Done" column.

Technical overview

We need to find a way to retrieve/mark the columns in which the elements are considered "Done".

story #14050 filter cards

See mockup on codepen: https://s.codepen.io/enalean/debug/615728ad14def79e9b694647c582ce16

Functional overview

When I type in the "search input" on the right of the taskboard's actions bar, cards are filtered and only cards that match what I type are shown.
The search term is highlighted on the card to show the user how the matching was done.

Matching to be defined: probably close to Planning. Planning matches backlog item on all card fields. It also takes "children" into account : here, we will want to show the swimlanes when a child card matches the search term.

UX to be refined:

  • If a "parent" card matches the search term, are all its children shown ?
  • What does the highlighting look like on card fields ?
  • What happens for collapsed columns ?
  • What happens for collapsed swimlanes ?

Technical overview

Be mindful that users can drag and drop into a filtered taskboard. As we usually maintain two models, one that contains "all cards" and one that contains "filtered cards", drag and drop should modify those two models.

story #14031 Have global progress indicator on the milestone

See mockup on codepen: https://cdpn.io/enalean/debug/615728ad14def79e9b694647c582ce16

Functional overview

There are two progress bars visible: one for the time remaining, one for the number of open elements remaining in the backlog. The progress bars should be present on all tabs of the milesone: Overview, Planning, Taskboard.

They are NOT present on the cardwall tab.

Technical overview

The progress bars should expose a "vanilla JS" API: either watch an HTML attribute or react on a custom event. That way, we have a simple way to work with them with either Planning (AngularJS), Overview (Vanilla JS), Taskboard (Vue + Typescript).
Given they must appear on Planning and Overview, they MUST run on IE11.

story #14030 See all card fields

Functional overview

All the possible card fields should be represented on the card:

  • int field
  • float field
  • computed field
  • string field
  • text field (when HTML format, tags are stripped)
  • Date fields (human format "A day ago" with the real date on hover)
  • List fields bound to static values (with the values' colors). Value colors can be "legacy RGB" or "tlp" (CSS classname)
  • List fields bound to users (with the user's avatar)
  • Shared fields (same as lists)
  • Open lists (same as lists)
  • Cross-references field
  • File field (attachments). It should be a link to attached files (no preview)
  • Permissions on artifact (just list the user groups separated by commas)
  • Read-only fields: artifact id, per-tracker id, priority, Last update date, Submitted on
  • Last updated by, Submitted by

Technical overview

At the design level, the card fields display should match that of Kanban or planning v2. On the technical level, code has to be rewritten because Kanban and planning use an AngularJS module (service / directive).

Card fields information should be added in REST routes (see Agiledashboard routes for reference)

story #14024 be able to recover my account when I have lost my TOTP device

When the user enroll itself, the possibility is given to download 10 recovery codes.

* A recovery code can be used instead of a TOTP code during the login process
* Each recovery code can be used only once
* There is a view in the account preferences to see how many recovery codes can still be used
* The recovery codes are stored in a way that make impossible to retrieve them (see the mechanism used for the personal access keys)
* The user can ask to generate new recovery codes








Open question: what to do when a user uses the last valid recovery code?

story #14020 have a OAuth2 server at Tuleap side to grant Jenkins permissions

story #14019 automate jenkins job creation & run

The base work is the existing Tuleap Git Branch Source jenkins plugin that already provides a first level of integration between the 2 tools.

The purpose of this story is to make it fully functionnal in a production environment:

  • Unify credentials management to replace using basic auth for REST and git usage (because it's consume too much resources).
    • Need a tuleap self-check scopes for a given key
  • Add a dedicated endpoint to be used for git push triggers
    • On Tuleap side, there must be a configuration project wide (git) to trigger events on the target jenkins.
  • All configuration means must be compatible with Jcaas to automate deployments
  • Clean-up code base

To investigate:

  • How lifecycle of git repo/branch is managed ?
    • In traditional "Git Branch Source" plugins, jenkins polls the remote organisation (in our case Tuleap project) on regular basis to identify new repositories/branches and create corresponding jobs.
    • Is that possible to have a push based approach where Tuleap would notify the target Jenkins about changes ?
  • How the configuration Tuleap <-> Jenkins is done ?
    • At very least there must be a info about the target Jenkins server in Tuleap project to trigger builds on push
    • Do we limit the configuration to "push" or do we have a more generic "Target Jenkins Server(s)" approach that could be later reused for other purpose (like more comprehensive management of the target Jenkins) ?
  • Prepare work for PR feedback integration (spike & complete AC of story #14430)

Reference plugins:

story #14018 have a central management of users and groups using oauth

Overview

Alternative strategy for users and groups management based on OAuth (initial proposal was based on LDAP).

This proposal is about implementing a tuleap-oauth Jenkins plugin in the same fashion than github-oauth or gitlab-oauth. It, of course, implies that Tuleap should be an OAuth2 and OpenID Connect Server provider first for this to work (epic #14432).

The way of working would be:

  • Jenkins servers would delegate to Tuleap the authentication of users (via OpenID Connect Provider).
  • Project and Groups defined in Tuleap could be exposed to Jenkins with the appropriate OAuth2 scope (read how it works with github-oauth).
  • The Tuleap Groups could be then used in Matrix based permissions (for best backward compatibility)

As a reference, here is a screencap of a Github configuration.

1894-Image%20Pasted%20at%202020-1-22%2017-37.png

 

Not covered

The following is something that can be done as part of a future work but it's not in the scope of this User Story.

The plugin can also provied "pre-wired" permissions based on Tuleap own permission system to help Jenkins admins in the configuration of their server (basically it would mean adding specific permissions Tuleap side to be exposed to Jenkins like "This Tuleap Group has developer capabilities, they are allowed to create jobs" or "This Tuleap Group has jenkins admin capabilities, they can administrate the whole platform".

story #14017 display baselines in tracker report table view

story #14016 set and update baseline permissions

story #14015 Edit & Freeze a baseline

story #14014 cherry-pick git tags

story #14013 cherry-pick SVN tags

story #14012 display baseline as a table

story #14011 cherry-pick documents

story #14010 cherry-pick artifacts

story #14006 add/remove backlog items in kanban

story #13999 vizualize association with scrum in artifact view

story #13948 Assign the review to myself

We can assign a pull request to individuals (no ugroups) (UI: same place than "reviewers")
I have a shortcut [assign to me]
We can identify assignee on PR lists
The PR I have been assigned to appears in the personal widget "My PR" (to be created, maybe another story)

story #13947 Have formatting capabilities in Pull Requests

I have at least a minimal formatting options:
- lists
- code blocs
- links

Markdown would be ideal (used elsewhere in Tuleap), though it needs formatting so that it does not break the display if user puts crazy formatting like h1 or tables.

I have a Preview button so that I can check my message before publish.

/!\ comments for files are done in a code mirror editor.

story #13946 Publish all comments as one review

I can either publish a comment directly (like today) or start a review.
When review is started
- comments (both file and global) are saved as drafts
- drafts can be edited/removed

I can identify PR with drafts
- on PR lists
- on personal widget?

/!\ we need mockup

story #13945 Have threaded conversations in Pull Requests

Inline diffs or side by side diffs allows current user to answer to a comment

/!\ We need mockup for that

story #13811 Have a customisable reactivation period for the account

- A dedicated info message to explain that the default value for the reactivation can be updated from the drop-down list.
- The proposed values to be refined.
- The default value is a config param in the local.inc

story #13686 reorder steps in the modale

story #13685 add steps in the modale

story #13635 edit cards with a modal

Functional overview

It's a rewrite of the current modale used in planning v2 using VueJS as we cannot re-use the current modal (done in AngularJS).

The only change that might be seen by user is that upload of files will be handled by TuS for streamed upload (instead of chunking done in AngularJS modal)

Technical overview

The modal is meant to be used in cardwall but also to completly replace the AngularJS one in Planning view, test management & kanban. As it's done in VueJS we can also use it to edit an artifact in and BurningParrot page (in Git, Document or Dashboard for instance).

The modal is a module provided by tracker, it's written in TypeScript and VueJS.

In order to learn from our past mistake, we decided to clearly separate the 2 use case of the modale:

  • Creation of a new artifact
  • Update of an existing artifact

As the 2 modes are clearly different:

  • Creation need
    • the tracker structure (GET /trackers/:id)
    • the default values
    • permissions "on submit"
    • transmit ALL data with a POST /artifacts/
    • have a special case for workflow (do not manage mandatory follow-up comment)
    • cannot display "read-only fields" such as "artifact id", "submitted on", etc.
    • can have prefilled data (as when we report a bug from TTM)
  • Update need:
    • tracker structure and artifact data (GET /artifacts/:id?with_tracker_structure) + followup comments (GET /artifacts/:id/changesets)
    • permissions on update
    • transmit only MODIFIED data with a PUT /artifacts/:id
    • have the complete workflow

Fields that might be tricky:

  • artifact links (management of a parent selection when applicable)
  • permission on artifact (the business rules for serialization for save server side are tricky)
  • files
    • There is a quota management to handle
    • Move to TuS
    • Display of upload progress on submit
    • Garbage collect of uploaded images that are no longer used. This is for image copy/paste in Followups or Text fields.
  • textarea + follow-up comments
    • dependency with files for copy/paste of images

Suggested split

  • Start by doing the full modal with only one simple field: String field. That means doing the GET requests, the transformation to Vuex model, the diff (modified files), the transformation to PUT / POST request and the actual requests. This step also takes care of workflow Hidden fieldsets and Frozen fields.
  • (The following is not necessarily ordered)
  • Add Open Lists fields
  • Add File fields with Tus upload
  • Add Text fields with image copy/paste support. This introduces a "cross-field" transformation where Text fields can change the values of File fields.
  • Add List fields with Field dependencies and Workflow transitions. That means Selectbox, multi-selectbox, radio button, checkbox. Field dependencies affect which values one can select from, from one List field to another. Workflow transitions restrict which values one can select from for only one list field.
  • Other supported fields : integer, float, date, datetime, computed, permissions on artifact, burndown (image from jpgraph), cross references, Structural (linebreak, static rich text, separator), Read-only fields (artifact id, per-tracker artifact id, priority, submitted by, last update by, submitted on, last update on)

story #13582 Know when my tracker name is already taken

The change is limited to a small UX increase. The form stays in Flaming Parrot, it stays a form submit and not a dynamic thing with REST calls. Those changes will come later.

The tracker shortname is auto-filled and "slugified" with underscores.
There is a check to warn the tracker admin that the tracker name or shortname are already taken (not unique).
 

story #13581 Have a breadcrumb link to other trackers

See mockup on Figma: https://www.figma.com/proto/RaBL0FL199pbWkh7TUJXIrAP/Trackers-service-flow?node-id=39%3A492&scaling=scale-down&redirected=1

The breadcrumb will display a list of other trackers in the project.
The list is limited to 10 or 15 entries (depending on what is possible to show on a screen of a reasonable size, for example a laptop).
The list of trackers is sorted by lexicographical order.
Test executions are excluded from the list. They are a special tracker and people rarely, if ever, need to access them directly instead of through Test management.

 

Notes:

There were other ideas proposed for the tracker "selection" and sort :

  1. Marking trackers as "favorite" or "starred" and showing "starred" trackers. It was not kept because it requires the Tracker administrators to classify trackers. If they don't, it changes nothing on the tracker user's experience.
  2. Sorting by "last modified date". It raises concerns because this sort will vary a lot and weighs in favor of "Tasks" trackers or "Test Execution" trackers, which have intensive use and are not necessarily relevant to access directly. Tasks are more accessed through Cardwall for example.

story #13573 See at a glance which parts need configuration

This is a follow-up of story #13570 Navigate in tracker administration with tabs

The "pulse" information is stored per-tracker. Once a tracker administrator visits a "pulse" page, the visit is stored and the "pulse" is no longer shown to others.
The pages that have a "pulse" are not configurable: it will always be "Fields usage", "Semantics, etc.

See mockup in Figma: https://www.figma.com/proto/RaBL0FL199pbWkh7TUJXIrAP/Trackers-service-flow?node-id=39%3A492&scaling=scale-down&redirected=1

story #13506 Support Images DnD in TTM steps

story #13425 Deal with performances in javascript

story #13421 Have better way to access to my primary actions

story #13402 have better edition capabilities in artifacts

story #13324 easily associate Document and Artifacts

Overview

The feature is provided is the Document plugin is active.

At this level of implemenation:

  • Only 1 folder (no other types of documents) can be associated with an artifact
  • A folder can be associated with only one artifact
  • Select of the folder is done with done with it's ID

Functional overview

You can checkout a live mock-up to better feel the feature.

Creation / link

The association is meant to be done in the Artifact via an "Action menu" option (mock-up to be done):

With the Following behaviours:

Create new will

  • pop-up a modal window that allow to select a parent folder (within the current project) where the new document will be created
  • then either (to be checked with Dev & UX team)
    • Option 1
      1. redirect to the Document service to proceed to creation of Folder
      2. redirect to the Artifact after creation
    • Option 2
      1. Displays the Folder creation modale within the Aritfact view
      2. and then reload the artifact page

Link with existing will

  • Allow to select a folder in the Document service with folder ID

Display

In Artifact view

When an artifact is linked to a document, the link appears in the tab view as it's done for (file releases ATM).

In Document view

Management of deletions

We need to take into account deletes. With special case of delete in docman that can ce reverted (folder restored).

On delete of folder the link is no longer displayed.

  • if the folder is restored, the link is displayed again
  • if someone links the artifact to another folder while the 1st one is deleted-not-yet-purged, if the deleted-not-yet-purged folder is restored, the link is not restored (the artifact is now attached to a different folder)
  • at document purge, if the folder is still associated to the artifact, the link is purged too.

If the artifact is deleted, the link is purged

Access rights

In order to link an artifact with a folder, a user must have:

  • "canWrite" permission on folder
  • "canAccess" (read) permission to the artifact

XML import/exported

As docmant is not part of standard XML/Import, the link cannot be imported nor exported.

Technical overview

The feature must be provided by a new Plugin (Tuleap Enterprise) that bridges Document & Trackers. This plugin will be responsible of

  • storing the link between one artifact and one folder.
  • providing the REST API to manipulate this link: OPTIONS, GET, POST & DELETE
  • a VueJS app to manage the creation and/or link from artifact view (hook in action menu + in artifact view JS)
  • + 2 VueJS component that should be dynamically loaded by Document app to provide the integration.

The ability for Document app to dynamically load components provided by a 3rd party plugin seems possible according to the spec but a quick spike should be done to ensure it works as expected.

In addition to that, the following views need to be modified to take into account the new tab:

  • Agile Dashboard Milestone details
  • Agile Dashboard Planning
  • Agile Dashboard Cardwall
  • Artifact view
  • FRS release view

Story Split

  1. Link with existing folder with it's ID and display in Artifact view
    1. New entry in action menu
    2. New app to manage the modale & the creation
    3. Manage permission for linking
    4. New tracker_document plugin for storage of the link with 2 routes: POST & DELETE
    5. Display of the link in Artifact view
    6. Management of delete of artifact or folder
  2. Display in Document view
    1. Display the tabs (Document, Artifact, FRS, ...) in Document view (display of tabs might a a builtin feature of docman or dynamic-loaded feature provided by the plugin).
    2. Display the link to artifact (and only artifact) in the folder "Quick View"
    3. Implement GET of link between document & artifact
    4. Display & check permission of tabs in all services (Document, Artifact, FRS, AgileDasbhoard)
    5. Impelement a new GET route to fetch all linked resources.
  3. Link with existing folder with a folder selector
    1. TBD
  4. Link + Create a new folder
    1. TBD

story #13311 send notification to people using @ notation in trackers

Overview

This is not meant to replace the current notification mecanism, that is to say assignement, or "CC fields". This feature is designed to be a one time "ping" of people to inform them about something related to one issue in a follow-up comment (or any text area).

Generally speaking:

  • People should be notified at the time they are mentionned
  • but not after
    • If people should be permanently notified, the regular notification mecanism should be used.
  • If people explicitly set to not be notified on a given artifact (unsubscribe on the artifact or "stop tracker notification") they won't receive an email
    • there is then a "warning feedback" displayed to the user who notified someone that this person won't be notified
  • People receives the notification accordign to their permissions (on project, tracker & fields).
    • If you mention @jdoe in a project she cannot access, she won't be notified.
  • Notification is automatic and not configurable, everytime '@jdoe' string is matched in a supported area (see bellow), jdoe user will be notified.

Note: at XML import there is no notification of people.

Functional

Follow-up comments

At follow-up comment creation (web & REST)

  • When there is a @string mention that match a username, the user is notified
    • if the user should have been notified with another field, there is only 1 notif that is sent
    • it can be used in combination with another notification mecanism. For instance jdoe is notified because assignee only on status changes but somebody mentions @jdoe in ca comment w/o status change => jdoe will get an email for this change.
    • further follow-up comments (without mention of user) won't notify the user

At follow-up comment edition:

  • Same rules apply than at creation. It means that
    • given a first comment with @jdoe (that triggered a notif)
    • whe this comment is updated and that the @jdoe string is still in the comment
    • then a mail is sent to jdoe
  • => Side Effect if @jdoe was not an actual user when the comment was created but is created later on, when the initial comment is update, @jdoe gets the notification.

Textarea fields

At text creation (web & REST):

  • (creation means from an Empty text to something not empty
  • When there is a @string mention that match a username, the user is notified
    • if the user should have been notified with another field, there is only 1 notif that is sent

At text update (web & REST)

  • Same rules apply than at "creation"

User is notified Only when the text field she is mentionned in is updated. Another way of saying it is that if @jdoe is mentionned in bug description, he won't be notified when "status" or "title" are changed or when a follow-up comment is added. How ever, as long as the string '@jdoe' is present in bug description, everytime description get changed, @jdoe will be notified.

String fields

Question: As of today, @mention is not supported in those fields ?

story #13239 finalize "automated" contributor

AC to be defined more precisely after implementation of story #13230, story #13231 and story #13232

A couple of things where not taken into account during dev, it's now tim to:

  • be able to switch Contributor semantic from Regular to Automated
  • inherit the tracker at project creation
  • do XML import/export
  • update the REST route for tracker description
  • remove the feature flag

story #13235 finalize "My artifact v2" widget

To be defined. Waiting for UX investigations

story #13234 setup the contributor semantic for all user groups bound "open list" fields

This story depends on story #13233

Functional Overview

Contributor semantic

No change is the configuration screens.

But now the "automated" semantic covers:

  • All list fields (select box, multi select box, checkbox, radio button)
    • Bound to users
    • Bound to user groups
  • All open list fields
    • Bound to users
    • Bound to user groups

Permissions

No change for the configuration.

The enforcement of the permissions now takes into account all list fields as described in the previous section.

Tracker TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

Cross Tracker Search TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

My Artifacts Widget v2

No change in the display

All list fields as described in the previous section are taken into account for the display of artifacts.

story #13233 setup the contributor semantic for all user bound "open list" fields

This story depends on story #13232

Functional Overview

Contributor semantic

No change is the configuration screens.

But now the "automated" semantic covers:

  • All list fields (select box, multi select box, checkbox, radio button)
    • Bound to users
    • Bound to user groups
  • All open list fields
    • Bound to users

Permissions

No change for the configuration.

The enforcement of the permissions now takes into account all list fields as described in the previous section.

Tracker TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

Cross Tracker Search TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

My Artifacts Widget v2

No change in the display

All list fields as described in the previous section are taken into account for the display of artifacts.

story #13232 setup the contributor semantic for all user groups bound list fields

This story depends on story #13231

Functional Overview

Contributor semantic

No change is the configuration screens.

But now the "automated" semantic covers:

  • All list fields (select box, multi select box, checkbox, radio button)
  • Bound to users
  • Bound to user groups

Permissions

No change for the configuration.

The enforcement of the permissions now takes into account all list fields as described in the previous section.

Tracker TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

Cross Tracker Search TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

My Artifacts Widget v2

No change in the display

All list fields as described in the previous section are taken into account for the display of artifacts.

story #13231 setup the contributor semantic for all user bound list fields

At this point of the development, we want to ensure that what was put in place in story #13230 works with several fields.

Functional Overview

Contributor semantic

The Contributor semantic evolves to its final form.

When no semantic is defined, the tracker admin can choose to either

  • Regular semantic: Select one field amongst the "users" lists fields
  • Automated semantic: All list fields (select box, multi select box, checkbox, radio button) bound to users are taken into account.
    • In this case, for the features bellow, the list of fields that are taken into account are computed dynamically everytime we need it. This way we don't have to maintain the list of fields and manage their addition / removal.
    • This can come with a perf penalty but this should be verified first (make it works, make it correct, make it fast).

When automated is selected, its still not possible to switch back.

For admin who switch to automated with the previous story, they are moved automatically to "Automated semantic" without further configuration.

Permissions

No change for the configuration.

The enforcement of the permissions now takes into account all list fields as described in the previous section.

Tracker TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

Cross Tracker Search TQL

No change in the syntax.

The @assigned_to will look for values in all list fields as described in the previous section.

My Artifacts Widget v2

No change in the display

All list fields as described in the previous section are taken into account for the display of artifacts.

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

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).

story #13003 import/export TTM steps in XML

There are two kind of data that should be taken into account:

  • tracker structure
  • artifacts/changesets data

It's the first 100% external plugin that contributes tracker stuctures and data. It's not possible to include those informations in Tuleap schema (project.xml).

We will introduce a catch-all markup <external-fields> in <tracker> and <changeset> schema and then, it will be up to the plugin to validate the content of what will be in <external-field>.

The validation must be done up-front to ensure all the data and structure are consistent before running the actual import.

REST tests are updated to leverage this XML import

story #12870 delete empty releases and packages

In SOAP api there was a possibility to delete empty packages and releases. We cannot replicate the exact same API with REST as the approach is not RESTful but we can provide the following en points

GET /projects/:id/frs_packages?query={"is_empty": true}

The result is paginated

GET /frs_packages/:id/frs_releases?query={"is_empty": true}

The result is paginated

DELETE /frs_releases/:id

It can only delete releases that doesn't have any files in it.

DELETE /frs_packages/:id

It can only delete packages that doesn't have any releases in it

story #12800 select all "Can submit" checkbox at once in tracker field permissions screen

As in the title, in Tracker > Admin > Permissions > Fields Permissions > Field, below "Can Submit" column, there are 2 links "Check all" and ""Uncheck All" that allow to select/unselect all checkbock in 1 click.
 

story #12639 a central tool to configure/setup/customize tuleap

Overview

This tool should replace the current "setup.el7.sh" + the various "nginx/fpm/apache" redeploy.

Things that needs to be covered/replaced

  • tools/setup.el7.sh
    • Core.sh
      • apache
      • mailman
      • libnss & co
      • cvs
    • Plugins.sh
      • git
      • svn
      • mediawiki
  • tools/utils/php72/run.php

story #12540 see status change in a chart over a time period

Given the following data

  • On Sept 2, #123 is created with status "New"
  • On Sept 4, #99 is updated with status "Closed"
  • On Sept 10, #124 is created with status "New"
  • On Sept 11, #124 is updated with status "On going"
  • On Sept 12, #124 is updated with status "Closed"
  • On Sept 23, #78 gets a comment + a remaining effort change
  • On Oct 10, #77 is updated with status "Declined"
  • On Oct 11, #222 is created with status "New"
  • On Oct 12, #223 is created with status "New"
  • On Oct 12, #223 is updated with status "Closed"

The chart renderer over September and October (per month) will be a cummulative bar chart:

For Sept:

  • New: #123
  • Closed: #99, #124

For Oct:

  • Closed: #223
  • Declined: #77

Comments (questions ?):

  • On Sept, #78 got updated but is not displayed because there is no status change
  • On Oct, #123 is no longer shown as "New" because there were no change

The underlying calculation:

  • For a given period (month), take into account all artifacts with a status change (in previous example, #78 is excluded from counts)
  • Take the last status as the end of time period (the intermediate states are not displayed, as for #124 and #223, calculation is done on Sept 30 and Oct 31 respectively)

story #12538 set values on fields given conditions

This should be added as a part of the workflow post-action of a given transition (e.g. on "Done").

There are two approches there:

  • numeric fields + formula
    • eg: The integer field [overdue by] is set to [=end_date - due_date]
  • list field + condition
    • eg. The list/checkbox field [post-mortem] is set to [late] when [end_date] [>] [due_date]

In both cases, a special care should be taken to the order of conditions are fields might get a value by another post action of the same transition.

 

story #12405 download a selection of files as a zip archive

This depends on story #12404.

The docman UI allows to multi-select files.

When more than one file is selected, a "Download as zip" button appears with a filesize indicator (it corresponds to the unzipped file size).

On button click the download starts.

When the total file size is greater than the threshold defined in previous story, the button is turned in "warning" mode to inform about the "large download incoming"

story #12404 download folder as zip

Functional overview

  • Only files & embedded documents are downloaded. Other doc types are ignored
  • On download action, if the amout of files to d/l (uncompressed) is bigger than a given threshold (1GB?) there is a warning + confirm
  • As content is streamed and zipped on the fly, the end users cannot have a progress bar to infrom them the time it will take.

Technical overview

  • Zip is generated on the fly and streamed from the backend (with PHP) to avoid creation of fat archives on the backend.

story #12401 have consistent breadcrumbs in the new Git service UI

  • Split repository name in the global breadcrumb : "Git repositories > tuleap > stable.git instead" of "Git repositories > tuleap/stable.git"
  • When viewing a commit, add it to the global breadcrumb ("Git repositories > tuleap > stable.git > 5c41de This is my commit…")
    • If the title is too long, css ellipsis should help
  • When viewing a pull request, add it to the global breadcrumb (like a commit)
  • Keep selected branches/tags when the user navigate between Files and Commits tabs
  • File pane: keep only the repository name at root

story #12262 change project owner in web UI

Overview

The feature comes as a new plugin 'project_certification'. This story depends on story #12161.

Functional requirement

In project administration, project owner or site administrator access:

  • They get write access to owner selection
  • They can change owner with a select box that list all project administrators of the project (not suspended nor deleted)

When there are no owner (project created before activation of the plugin)

  • Only site administrator is allowed to set a owner

story #12217 approve an artifact (complete)

This is an alternative proposal for story #11839.

Instead of being something that sit next to the artifact, the approval table described here is a field by itself and behaves at such. The main difference between the 2 proposal is that the complete version (this one) allows:

  • A full logging of changes (who added who to the table, when status was modified, what was changed between 2 changes of a vote)
  • A UI integration into the artifact view itself (as a field)

The field comes as a plugin, field must be explicity added to the tracker to be used.

Functional overview

The approval table is a new field that can be instanciated only once in a given tracker. The field can be placed anywhere but it's not recommended to put it in a column (will break layout).

The approval table value can be accessed in:

  • Artifact view
  • Report
  • REST representation
  • Webhook representation

All other usage are not possible (no search criteria, no TQL, no SOAP, no charts, etc).

Tracker admin, field configuration

Tracker admin can add the field where he wants. There are not configuration values for this field. Permissions apply:

  • Submit/Update: it corresponds to the people who are allowed to create a new approval table, add and remove people, turn on/off the review.
  • Read: People that are asked for review must be part of people allowed to read it.

Ask for review

Who: those with write permission (see upper)

When: at any time of artifact life

Where: in artifact view only (not possible from the various modals in scrum, kanban or test management).

In the "Approval table" tab of the artifact, the creator have a autocompleter field that allow to choose people in the list of "registered users". There are no check that selected user can actually access the artifact.

When people are added to the table, the modification be be seen in corresponding changeset (+ notification to people monitoring artifact).

In addition to a list of users, the approval requester have a "free form" where he can write something to reviewers. The change of the text is also displayed in artifact history (+ notification to people monitoring artifact).

Once people are selected, approval requester should click on "start review" to start the review process. One email is sent to all reviewers with the text in "free from" + the link to the approval table. All reviewers are in CC of this email as well as the approval requester. The change of approval table state (from "disabled" to "under review") is recorded in artifact history + notification to people monitoring artifact.

No reminder are sent.

All changes to the table are recorded: addition or removal of reviewer, vote of people, comments, etc. Each action lead to a notification to people that are monitoring the artifact.

Do the Review

As a reviewer, I'll get a specific email (regardless of their tracker/artifact monitoring preferences) asking me to review a given artifact with link to id where I can see:

  • Who asked the review
  • When it's been requested
  • The free text
  • The list of all reviewers with
    • their name
    • the status of their review
    • the date and hour of the review.
    • the comment they made

For the line of the table that corresponds to my name, I'm able to select either

  • Approved
  • Rejected
  • Will not review
  • Under review (can be used to ask for a change)

I can use the follow-up comment of the artifact to comment my vote and I click on the regular "Submit" button of the artifact ot record my vote. This triggers a regular artifact notification with the vote and comment as diff to all people monitoring the artifact.

Reviewers can change there vote at any time as long as the table is still in "under review" state.

Approval or rejection

Note for reviewers: the following behaviour is not tight to "light" or "complete" version of the approval table. It's another approch of the feature thant the one described in story #11839. Each behaviour can be implemented regardless of "light" or "complete" strategy.

At creation, approval table gets the status "Disabled". People can be added in advanced as reviewers.

When approval is actually requested, its status becomes "Under review" (any user that can manage approval can do that).

A user that can manage the approval table can switch the table to "Close" at any time.

There are no other management of status. The action to approve or not the table is left to approval manager when he closes the review. This allow more flexibility on the rules of approval. For instance it can be either 100% of approval, or majority + 1, etc.

When the table is closed, reviewers can no longer change their vote. A notification is sent to people monitoring the artifact.

Artifact life

The approval table lifecycle and the artifact lifecycle are tighly integrated and it will be easy to see the change of artifact between 2 votes. All changes are recorded.

The actual approval of the artifact is left to end users but there will be a clear statement in the history if the final approval doesn't match what was in the approval table

When the artifact is deleted, the approval table is also deleted.

Artifact life

The approval table lifecycle and the artifact lifecycle are completely separated. The artifact can be rewritten completly during the approval table process without impact or notice.

The approval status change (No started, approved, rejected, reset) should be logged as change into the artifact history (Technically: check how it's possible to deal with that).

Same after the end of the approval process, the artifact can be either "Approved" or "Rejected" and it can still be modified.

When the artifact is deleted, the approval table is also deleted.

There are no CSV import/export of approval tables

There are no XML import/export of approval tables

story #12189 prevent field modification according to state

Overview

The intend of this feature is to progressively settle fields during artifact life in case of usage of worklow to mark maturity stages (like ISO/CMM processes often do). With this in mind, when moving from one stage to another, a bunch of fields that were "under elaboration" became frozen.

It's still possible to un-freeze those fields if the workflow allows some back-tracker (ie. a tracker admin could temporarly allows a transition to make edit possible).

With this feature it would be possible to configure a worklow so an artifact would be entirely "read-only" when "Closed" (except for follow-up comments).

This story depends on story #12187 for new workflow configuration panel.

See live mockup: https://s.codepen.io/enalean/debug/dace752a350bcecdad1003e505bc9992

Functional overview

Tracker administrator point of view, configuration

The configuration of frozen fields is made in workflow transition settings. A new post-action is proposed "Freeze fields" with a multi-select box like in tracker field administration (with fields grouped by containers). All the fields selected won't be modifiable (even by a tracker, project or site administrator).

In order to keep a clear UI and not make it confusing, this post-action can only be added once per state. After adding it once, when you try to add this type of post-action again, then the selectbox for post-action type will show a disabled option.

Edge cases:

  • Field dependencies: if 2 fields have dependencies they must be configured to be either editable or frozen at same time.
  • Triggers: Triggers are defined by tracker admin and can modify a "frozen" field on the behalf of the user.
  • Other post-actions. If the transaction set a value to a field (for instance set "0" as remaining_effort when status is Done) and the field is set to frozen, the post action valuation is done (that is to say: remaining_effort is set to 0 and no longer modifiable).
  • Rules: Rules applies regardless of the frozen field. A tracker admin can make a dead-end transaction by having a global rule that cannot be satisfied due to frozen field.

End user point of view, usage

At a given state, all the frozen fields the user can see are read only (as if they were not updatable as per permissions).

Limitations

There are some limits with the interaction of workflow post action with some Tuleap features:

  • On scrum cardwall. If the workflow defines that at some states either "Remaining effort" or "Assigned to" are no longer modifiable, it will not be taken into account on the cardwall. To say it differently, in this situation, the data won't be updated on the backend (data are safe) but the error will not be shown to the end user. It would require a major rewrite of the current scrum cardwall (out of the scope of this dev) and it's very unlikely that a team would actually set this up.
  • On cardwall renderer of a tracker. If the workflow forbids modification of state at some points of the workflow, the following drag'n drop will be possible but will trigger an error with a opening modal of the artifact to modify the values so the constraints are met.

Technical overview

  • Configuration must be exported/imported with tracker XML format
  • Configuration must be duplicated at tracker / project creation.
  • On the configuration screen fields that are already readonly (burndown, last_update_date, etc) or containers (columns, etc) are not listed to limit the amount of elements to pick-up.

For REST and the angular Artifact modal

The REST routes need to be updated. We initially thought to use the permissions, but those live on the tracker and not on the artifact. The tracker has no knowledge of the particular states of artifacts. We must add the information on the artifact or more precisely, on the artifact's fields.
Here is the proposal:

{
  "field_id": 8506,
  "type": "float",
  "label": "Effort",
  "value": 126
}

Becomes

{
  "field_id": 8506,
  "type": "float",
  "label": "Effort",
  "value": 126,
  "workflow_state": {
    "can_user_update": false
  }
}

The artifact modal will need to be updated to take into account that fields with "can_user_update" === false should not be editable.
"workflow_state" can be reused in story #12188 to also support the "hide" information that will tell the REST consumer that this field is supposed to be hidden.

story #11839 approve an artifact (light)

Functional overview

This approval table is meant to get a formal agreement of a given artifact. Its used to simplify approval of people on a requirement, a spec, etc.

The approval table is only really used as a way to ensure that a given list of people were OK on something at a point of time. However this information is not used elsewhere (no REST API, no CSV export, no column in report, no chart, no webhook trigger, no workflow/transitions, etc).

From a usage point of view, the only way to have an artifact approval table status is to go on the given artifact and to click on the "Approval table" link in the list of tabs (new to "Artifact", "Children", etc).

There is no automated actions introduced by the approval of an artifact. When an artifact is approved, is visible in the "Approval table" link of the artifact and that's it. If the consequence is to change something on the artifact, it's the duty of the requester to make the update afterward.

The feature comes as a plugin, as long as the plugin is installed, all artifacts in all trackers can have approval tables.

Ask for review

Who can do that: Anyone that can create an artifact in a tracker can create an approval table on an artifact of this tracker.

When: the approval table can only be created after the artifact creation (ie it's not possible to create an artifact & the approval table at the same time).

Where: in the tracker only (not possible from the various modals in scrum, kanban or test management).

In the "Approval table" tab of the artifact, the creator have a autocompleter field that allow to choose people in the list of "registered users". There are no check that selected user can actually access the artifact.

In addition to a list of users, the approval requester have a "free form" where he can write something to reviewers.

Once people are selected, approval requester should click on "start review" to start the review process. One email is sent to all reviewers with the text in "free from" + the link to the approval table. All reviewers are in CC of this email as well as the approval requester.

There a no other notification sent. As it's not an artifact update, people monitoring the tracker won't receive an email about this approval table.

There are no reminder sent.

The approval table creator is the only person than can add/remove people to/from the list (+ tracker & project admins). The update of the table itself is not recorded (if someone rejected the doc but was removed after that it's not visible).

Approval table creator can also "reset" the vote of a given user, it's then reverted to "Under review". Resets aren't log either.

Do the Review

As a reviewer, if I click on the link I receive in the mail, I'm accessing the "Approval table" tab where I can see

  • Who asked the review
  • When it's been requested
  • The free form text
  • The list of all reviewers with
    • their name
    • the status of their review
    • the date and hour of the review.
    • the comment they made

For the line of the table that corresponds to my name, I'm able to write a comment and to select either

  • Approved
  • Rejected
  • Will not review
  • Under review (can be used to ask for a change)

+ Submit button.

At Submit, all reviewers + approval requester are notified of the status of the review + comment if any.

Once the "Approved" or "Rejected" are chosen, it's no longer possible to change for the reviewer. If there is an update to do, the approval creator should reset the original vote.

Approval or rejection

At creation, approval table gets the status "Under review".

When all reviewers approved the artifact, the status of the approval table is switched "Approved". It can happen when

  • the last reviewer set "Approved" or "Will not review"
  • the approval creator removes the last "Rejected" from the list

When at least one user "Reject", the approval table is switched to "Rejected".

As soon as the table is either "Approved" or "Rejected", the date is recorded and the approval process is stopped (other reviewers cannot modify).

Artifact life

The approval table lifecycle and the artifact lifecycle are completely separated. The artifact can be rewritten completly during the approval table process without impact or notice.

The approval status change (No started, approved, rejected, reset) should be logged as change into the artifact history (Technically: check how it's possible to deal with that).

Same after the end of the approval process, the artifact can be either "Approved" or "Rejected" and it can still be modified.

When the artifact is deleted, the approval table is also deleted.

There are no CSV import/export of approval tables

There are no XML import/export of approval tables

story #11649 protect my account with a TOTP code

  • The multi-factor authentication feature is provided by a plugin

 

  • Once the first authentication is successful (username/password), I need to enter a TOTP code in order to be logged
  • All logins tentative through the web interface are concerned by this:
    • username/password
    • username/password with LDAP
  • All login tentatives that can not redirect the user to a web interface are declined, concerned endpoints are:
    • REST API
      • token request
      • basic authentication
    • SOAP API
    • SVN (core or plugin)
    • Git over HTTP
    • CVS
  • Authentication relying on a token that has been explicitely requested by the user (i.e. SVN tokens) do not need to validate a second authentication factor to be authenticated
  • Users can enable the MFA from their account parameters. The MFA is enabled once:
    • They have configured their app/hardware token with the given random generated secret key
    • They have successfully answered one challenge
  • Users can disable the MFA they have enabled
  • The generated secret key is never displayed again after the initial enrollment and is stored encrypted in the DB
  • Only one secret key can be associated by user account (aka it is not possible to use multiple app/hardware tokens with different secret keys)

 

This story does not include:

  • recovery of the user account with recovery codes if the user can not use the second factor that has been registered: the user won't be able to log in anymore
  • any kind of management by site administrators or project administrators: it is not possible to disable the second factor nor to enforce the usage of MFA to be able to access the Tuleap instance or specific project

 

story #11577 have mattermost bot that doesn't depend on site administration configuration

Bot should be configured project per project

Existing usage of central bot should be duplicated at project level
 

story #11360 apply my right to be forgotten

As a site administrator

I can "anonymize" a user uppon request

  • realname will become "Anonymized #id"
  • login will become "anonymoyous_#id"
  • email will become "" (empty string)

All other informations will remain, especially those stored in external tools like git, subversion. Personal data stored in files uploaded on server cannot be modified (FRS, docman, trackers, etc)

As a regular user

I can request "the right to be forgotten" on my settings page.

story #11358 see privacy and personal data information

From Tuleap footer and Help page, I have access to a Privacy page that list what Tuleap collects in term of personal data.

There is a mention about exclusion of usage that can be made of trackers (or wiki, etc) in term personal tracking.

If a wiki or a tracker are being used to collect personal data, it's responsability of user to control, disclose and manage it's own GDPR compliance.
 

story #11122 delete several artifacts from one tracker

As site admin, 

  • I can configure the threshold for number of artifacts that can be deleted at once (by default 1)
  • This configuration is global to the platform and apply to all trackers

As tracker admin,

  • When site admin configured that more than 1 artifact can be deleted, I can enter several artifact ids separated by comma (field is enlarged)
  • I can only delete artifact that belongs to the tracker I'm IN.
  • I get a confirmation screen with a table that lists following fields (according to semantics)
    • ID
    • Title
    • Creation date (with time ago + actual date)
    • Last update date (with time ago + actual date)
    • Status (actual value)
  • When there are no semantics for title and status, entries are empty.
  • Then I can confirm the deletion
  • The deletion of artifacts is recorded in project history  with artifact id and date (so it might be found in a DB backend)

story #11105 get email notifications on pull requests - second stage

Add / remove reviewers

After having created a PR, on the PR view, there is a list of reviewers that is empty.

I can click on "Edit" to add people:

Both with auto-completers (I cannot add raw email address)

When people/groups are added they get a notification about the PR to reviews.

It's possible to remove reviewers with the same process.

"Owner" of the PR is automatically part of the notification list. Who is "owner":

  • creator of PR
  • commit author => NO, we don't want to notify linux kernel contributors
  • push author

Notifications

What triggers a notifications

  • A new comment (there will be one email per comment) (done in story #14190)
  • A new push in the branch (done in story #14190)
  • A Jenkins update of the branch
  • Being added as a reviewer (only new reviewers are notified, existing reviewers are not notified about add/remove) (done in story #14190)

There is a check of permissions as well as an email de-duplication at sending time to avoid leaking informations.

The code should also respect "Truncated Emails"

Notifications are handled with Backend Workers (Redis) whenever possible to avoid slowdown on push/comment & co.

Content of the notification to be defined

  1. On reviewer added:
    1. commit summary (id, shortlog)
    2. stats (list of files + status)
    3. link to the PR (done in story #14190)
  2. On comment: (done in story #14190)
    1. link to the PR
    2. comments + context (file, code fragment)
  3. On push:
    1. link to the PR (done in story #14190)
    2. shortlog of modified files (/!\ force push)
  4. Merge/abandon (done in story #14190)
    1. link to the PR
    2. status of PR
  5. Jenkins
    1. link to the PR
    2. CI status (only for the last commit of the PR, only if the CI status change)
  6. On title/description change? => NO

Bonus: The information of reviewers added/removed is displayed in the PR log

story #10972 Be able to import a project with is own configuration and data

Done:

- all trackers and artifacts, cardwall structure (integrated in Tuleap 8.18)
keep link, even if project uses natures of artifact links (integrated in Tuleap 9.0)
- svn repositories:
export and import (integrated)
migrate core into plugin (with settings)
- Kanban import
- Dashboard import
- Mediawiki export
- TTM import/export

Under review:
git repositories export

To do (order by priority)
Kanban export
Dashboard export
FRS export
svn core import into svn plugin (web UI)
Services order
Import SVN notification should be able to import users and ugroups
Kanban report selector

story #10955 have real-time update of artifact edition and drag & drop

To be confirmed with Product Owner

Given Alice and Bob are viewing the Release "Version 1"
When Alice edits an artifact in the backlog or in a sprint "Sprint 1"
Then Bob sees the update of the artifact (e.g. card fields)

When Alice changes the artifact's status from open to closed,
Then the card becomes grayed out in Bob's view (because the artifact is closed). Depending on Bob's preferences (show / hide closed backlog items), the card disappears.

When Alice moves a card from the backlog to "Sprint 1", or from "Sprint 1" to the Backlog, or from "Sprint 1" to "Sprint 2",
Then the same change is done in Bob's view

It does NOT deal with artifact creation : creating a User Story in the Backlog, creating a User story in "Sprint 1", creating a Task child of a User Story, creating a milestone "Sprint 3"

story #10843 upgrade to mediawiki 1.27

Tuleap Mediawiki 1.27

Extensions

List

  • CategoryTree => 1.23+
  • Cite => 1.25+ / PHP 5.4+ / Integrated with MW 1.21
  • ImageMap => Integrated with MW 1.21
  • InputBox => Integrated with MW 1.21
  • Labeled Section Transclusion => 1.18+ / PHP 5.4+
  • Parser function => Integrated with MW 1.18
  • PdfBook => 1.25+
  • SyntaxHighlight => Integrated with MW 1.21
  • WikiEditor => Integrated with MW 1.18
  • MLEB => External package from tuleap.net

Result

  • CategoryTree => OK
  • Cite => OK
  • ImageMap => OK but 404 on https://tuleap-web.tuleap-aio-dev.docker/plugins/mediawiki/wiki/tuleap-dev/resources/assets/poweredby_mediawiki_88x31.png
  • InputBox => OK but some css is broken
  • Labeled Section Transclusion => OK
  • Parser function => OK
  • PdfBook => OK without tab
  • SyntaxHighlight => /!\ Error with pygmentize inclusion and highlight does not seem to work (version 1.1 provided by dependance by viewvc & 2.1 MW 1.27)
    • Need to use virtualenv to load properly
  • WikiEditor => OK
  • MLEB => /!\ Does not seem to work + lot of warnings on use: https://www.mediawiki.org/wiki/Topic:Tyrinqx8pef1l7lg
    • WILL NOT BE SUPPORTED IN 1.27

Upgrade 1.23 -> 1.27

PHP 5.6 is mandatory

Upgrade path

  • Decided by global mediawiki administators or project administrators
  • Project by project
  • All new projects uses 1.27 (regardless of template)

Permissions

  • Session => create new classes with MediaWiki(UserLoadFromSession hook is deprecated in 1.27) => https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager#As_a_provider && https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/Updating_tips#UserLoadFromSession_hook

  • Groups & users seem globally OK

Theme

  • Use standard Vector Theme
    • Standard Vector Theme is weel displayed (without Tuleap content)
    • Tuleap123 is displayed, but some CSS must be rewritten
  • Upgrade MW embbeded into Tuleap to Burning Parrot
    • Inclusion "works" => some styling to be redone + BP style rewrite a lot of MW styling rules
  • Upgrade MW admin pages to Burning Parrot

Resources

  • Download MW 1.27: https://releases.wikimedia.org/mediawiki/1.27/mediawiki-1.27.3.tar.gz
  • Extract to /usr/share/mediawiki-tuleap-127
  • Database upgrade > /usr/share/tuleap/src/utils/php-launcher.sh /usr/share/tuleap/plugins/mediawiki/bin/migrate_to_127.php tuleap-dev --conf /usr/share/tuleap/plugins/mediawiki/www/LocalSettings.php
  • Download Pdfbook extension: https://code.organicdesign.co.nz/extensions/zipball/master
  • Download Labeled extension: https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdistname=LabeledSectionTransclusion&extdistversion=REL1_27
  • Download CategoryTree extension: https://www.mediawiki.org/wiki/Special:ExtensionDistributor?extdistname=CategoryTree&extdistversion=REL1_27
  • Download MLEB: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2017.07.tar.bz2
  • Database upgrade > /usr/share/tuleap/src/utils/php-launcher.sh /usr/share/tuleap/plugins/mediawiki/bin/migrate_to_127.php tuleap-dev --conf /usr/share/tuleap/plugins/mediawiki/www/LocalSettings.php
  • Gerrit draft: gerrit #9844

story #10772 have a global docman administrator

Introduce the same permission for docman than what is already done for mediawiki or tracker: a permission that allow to administrate all docmans across the platform regardtheless the actual permissions of users within projects.

For private projects, global docman administrators can only see the docman service

story #10728 encrypt OpenID Connect server client secret key before storing them in the DB

As site admin, in the OpenID Connect plugin administration:

  • A warning is displayed on OpenID Connect servers whose client secret is stored (or has been stored) in cleartext

At OpenID Connect server creation or update only the encrypted client secret is stored and the cleartext client secret is nulled if existing.

When a OpenID Connect server is used, the password is decrypted before usage

 

It leverages the existing Tuleap cryptography API.

story #10727 encrypt credentials used to access Jenkins instance before them into the DB

As project admin, in the continuous integration plugin administration:

  • I have a way to set credentials to access a Jenkins instance better than putting them in the URL used to access the Jenkins instance URL
  • If possible, a warning is displayed on configured Jenkins jobs with credentials in the URL

The credentials used to access the Jenkins instance are stored encrypted in the database and decrypted before usage.

 

It leverages the existing Tuleap cryptography API.

story #10726 encrypt Gerrit credentials before storing them in the DB

As site admin, in the Gerrit section of the Git plugin administration:

  • A warning is displayed on Gerrit servers whose password is stored (or has been stored) in cleartext

Then, at Gerrit server creation or update only the encrypted password is stored and the cleartext password is nulled if existing.

When a Gerrit server is used, the password is decrypted before usage

 

It leverages the existing Tuleap cryptography API.

story #10710 search on fields with duck typing

See principle of duck typing in story #10709.

The same constaints apply for search terms

Technical side

  • Field selector like columns in story #10709
  • No impact on code mirror or TQL
  • Search only on fields already supported by TQL
  • Generate the Ultra Fat Query

story #10709 display search results duck typing on columns

Principle

Allow to search on custom fields (aka fields defined freely in each tracker) without too much overhead in the query definition or column selection.

Apply "duck typing" principle: if it has the same name and has a compatible type, let's assume it's the same thing.

Compatible types definition:

  • All numerics (initial_effort could be fload or int): float
  • All list with same bind (eg a select box with static values and check box with static values)
  • String and text fields
  • Date
  • Date time

Date and date time are separated because it's hard to guess what's the expected result when the query is "start_date >= 2017-04-24 07:15" and the field is a date (without time).

Are excluded:

  • rank
  • computed fields
  • artifact links
  • open list
  • permission on artifact

A field is selectable as a column if and only if

  • The name is present in all trackers of the query
  • The types assocated to this name are compatible
  • The user can read the field in all trackers

Technical side

  • No change on column selector (still button + drop down)
  • Group permission verification for Permissions on artifacts
  • Fetch data to display with same strategy then current tracker table renderer

story #10708 sort on one of the selected column

  • First click on column name: sort on it with ASC
  • Second click on column name: sort on it with DESC
  • Third click on column name: desactivate sort

There is no multi sort

story #10707 select, drag'n drop and resize columns from ATF and semantic

Allow customization of the report with Always There Fields and Semantics.

This customisation can be saved for future reload of the widget.

Technical side:

  • Drag'n drop can be done with dragula (like Planning, Kanban, Dashboards, ...)
  • Need to find a lib for column resize (maybe in vanilla js)
  • Column selection is done with a button and a drop down

Behaviour on how save will be done (see mock-ups in epic)

story #10705 define a query with id field

  • Define a query on "Id"
  • Should behave like a numeric field (see TQL definition for that)

story #10593 search on computed field values in trackers

Functional concerns

  • A limit is defined in tracker.inc to define how many artifacts are "too many" when trying to filter using at least one computed field. This limit is arbitrary set to 100.
  • Computed fields are available in search criteria only in normal mode (not in Tracker Query Language)
    • There is a way to distinguish Computed fields in the search criteria so people are aware that the behaves differently and have some limitations (UI/mockup needed)
  • Error handeling
    • When the initial -SQL- search returns more artifacts than what is defined by the limit no results are returned and an error message tell users that they must refine there non computed fields search criteria with the number of matching artifacts w/o computed fields & the threshold (UI/mockup needed). In addition to that, this error is logged in tracker.log
    • All tracker logs (this new one, workflow, email gateway, etc) are centralized in a new tracker.log with truncation & log rotation.

Please note that all this (esp. limit) was thought with 1 computed field in mind. It's very likely that is a tracker admin with tens of computed fields on a report with very deep hierarchy is going to be hit by a major slowdown, a fatal error or a blank page (and probably the 3, one after another). This is not covered by this story.

Technical concerns

Computation

  • The filter on computed field must be done only after the other search criteria are done

How to avoid heavy computations ?

There are no ways to do the filtering at SQL side as the value must be computed in PHP. The global idea is to leverage the computation that is done for rendering and to filter out based on that. The rational is that if we can display the value, we can apply a filter on it.

There might a threshold on the max number of artifacts a query can contain before computing computed fields. This might even be a good idea for current "display only" situation. Let say that the threshold is 100, computed fields values wouldn't be computed (neither for display nor for search) if the query, without the computed field part, has more than 100 results.

story #10469 choose if I receive a notification when I create/update an artifact

Given I configure in my account settings that I don't get notification on my actions

When I'm doing one of the following actions in Tuleap trackers:

  • Create an artifact
  • Update/comment an artifact

I'm not notified, even if I'm part of a group that should be (global notification, CC, assigned to, already in commenter list, etc).

story #10468 configure notification on closed artifacts

As tracker administrator, in Tracker admin "email settings", I can select

  • A user, an email or a group of people
  • And check if they are notified
    • New []
    • Closes []
    • All (auto checked & disabled New and Closed)

The "Close" notification is computed based on Status semantic and is proposed only if this semantic is available. A warning will be added in the semantic page, mentionning it may imply tracker global notifications.

If the semantic is removed :

  • if a notification is only on "Closed", then the notification is removed
  • if a notification is "Closed" and "new" or "all" then the notification is updated

If no semantic status, the closed column is not displayed.

A forge upgrade is handling the new values within global notifications.

The xml import/export is not included (story #10505)

story #10297 highlight workflow configuration in matrix

Based on new workflow:

  • Introduce 3 icons to identify for each cell, whether this
    • a mandatory field
    • a permission set
    • a post action
  • On each cell, on hover, the configuration is displayed
    • list of mandatory fields
    • list of groups that are allowed to perform the transition
    • list of post actions

In addition to that, the switch popup (Advanced <-> Simple mode) should be updated to be more accurate on what's lost at switch (if there are frozen fields for instance).

story #10276 have favorites beside nav history list in navbar

  • I can add or remove nav history items
  • I can clear the list
  • Tuleap bookmarks are fully removed, not migrated (widget included)

story #10275 see test campaign access in navbar

The "access recording" is bound to GET campaigns REST route

story #10274 see FRS access in navbar

story #10273 see mediawiki access in navbar

story #10272 see svn repo access in navbar

Only the SVN plugin is taken into account. Core is excluded.

story #10271 see docman items access in navbar

Exclude folder access

story #10259 see git repo and pull requests access

  • For PR, the "access recording" is bound to GET pr REST route
    • There is a link to the correponding git repository (dest) as a quick link

story #10246 Customize SAML2 provider

story #10245 log in into a Tuleap instance using only a SAML2 provider

- It is possible to choose SAML2 as the unique authentication provider for the Tuleap instance
- I should be able to login with openid connect from the front page
- The user account creation should be hidden in favor of OpenID connect login + account creation.

story #10177 New create account

  • LDAP:
    • ​​No Create account button on homepage so no modal
    • If Login/New account pages have been merged, there's only the login pane displayed (as we can see in Tuleap 9.6)

story #10151 know what is computed in each statistics category

For each statistic pane should described what the stat corresponds to and how values are computed.

For csv export, there should a summary of what each file corresponds to.

Quote from a site admin

For instance in https://tuleap.example.com/plugins/statistics/index.php I have no idea of what is a session ?
I don’t know as well how to see all user who have an access to Codex (whatever the access)
Git read acess are in a UI only, git push in a csv export only.

The plugins/statistics/data_export.php provide only a csv file which is impossible to import in excel because export of project description and several other field prevent import.
I think before we had the possibility to have a global view without csv. Now we have nothink.

A good documentation to me would give :

· service per service, what is possible to have in term of statistics.

· Globally (in a summarized way), what is possible to have at platform level.

story #10145 configure what is accepted as backlog item type

I Scrum admin

  • I can define which trackers of my project can hold "backlog items" (see attached screenshot)

Impact on "Planning" configuration

  • The select box that used to drive "what can be planned" in this planning disappear.
  • Need to update the way cardwall configuration is retreived

Impact on Planning view:

  • The "Add an item" select box (in milestone or sub milestones backlog) now list all possible backlog items
  • The "Add a child" select box now list all possible backlog items

story #10144 remove backlog hierarchy in favor of artifact link type

  • Underlying SQL queries should rely on "_is_child" instead of Tracker Hierarchy to look for children.
  • There is a new artifact link type "has_backlog" that allow to identify what is the Backlog of a given milestone. This replace the implict link bewteen planning & hierarchy
    • Until now in order to decide what to display as backlog of a milestone we add to look for
      • Artifact links of the milestone
      • Filter this list based on "Allowed Backlog trackers" of the corresponding planning
      • Display only what is allowed to be planned in submilestones (for instance when release is holding epics but sprint only accept user stories as backlog items. AKA the nightmare to manage)
    • With "has_backlog" and Scrum v2, to decide what to display as backlog of a milestone:
      • We look for artifact links with "has_backlog" type (with milestone as source)
  • The "has_backlog" type is added to all Agile Dashboard (even Scrum v1) - TODO: verify if it's manadatory to apply to scrum v1 or if it's easier to keep 2 separated execution paths: one without has_backlog, one with);
    • the consistency in Scrum v1 is ensured be Tracker Hierarchy and Planning Configuration
    • the consistency in Scrum v2 is ensured by Planning interface

Impact on "Planning view" drag'n drop

Warnings:

  • When a solo item is added as child of another backlog item, the "has_backlog" link of the milstone is removed AND the "has_backlog" link on all parent milestones must be removed recursively as well.
  • When a solo item with children is added as child of another backlog item, the "has_backlog" link of the milestone is removed AND all its children must also be removed from the milestone and sub-milestones recursively.
  • When a backlog item is removed from a milestone, all its children must also be removed from the milestone and sub-milestones recursively.
  • When a child is removed (to become a solo item) we must create the "has_backlog" link with the milestone AND the "has_backlog" link on all parent milestones must be created recursively as well.
  • When an element (eg user story) is create directly in a sub milestone as solo item we must create the "has_backlog" link with the milestone AND the "has_backlog" link on all parent milestones must be created recursively as well.

Impact on Carwall

Cardwall queries must be rewritten to take into account:

  • is_child link for cards children
  • has_backlog for cardwall swimlanes & solo items

 

 

story #9577 Display the Readme Markdown in a widget on the project dashboard

story #8861 allow underscore in project short name

story #8286 Have a beautiful password recovery page