•  
     
    story #13811 Have a customisable reactivation period for the account
Summary
As a site-admin
Have a customisable reactivation period for the account
The suspension rules does not apply on the account during this customisable period
- 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
Houssem Eddine Azzouz (heazzouz)
Status
Empty
Canceled
Development
  • [x] Does it involves User Interface? 
  • [x] Are there any mockups?
  • [ ] Are permissions checked?
  • [ ] Does it need Javascript development?
  • [ ] Does it need a forge upgrade bucket?
  • [ ] Does it need to execute things in system events?
  • [ ] Does it impact project creation (templates)?
  • [ ] Is it exploratory?
Empty
Details
#13811
Nouha Terzi (terzino)
2022-05-11 15:38
2019-08-27 16:40
3944

References

Follow-ups

User avatar
Hello Manuel,

An first fully functional change in relation with this story has been pushed and is currently pending review.

BR,
User avatar
  • Attachments reactivate-user.png, Slide3.PNG, Slide4.PNG, Slide5.PNG, Slide7.PNG, Slide8.PNG, Slide9.PNG, Slide11.PNG, Slide2.PNG, Slide6.PNG, Slide10.PNG removed
User avatar
last edited by: Houssem Eddine Azzouz (heazzouz) 2020-04-20 18:03

Yes, we do agree on not segregating front/back unless it is necessary. Fortunately, for this change we will not be altering the way old code behaves, it consists mainly of adding rather than modifying. We have tried to come up with propositions (attached file) on how are we going to divide the feature with a focus on having a functional feature from the first change that gets enriched later. How can we improve the proposed changes? 


  • Attachments Slide3.PNG, Slide4.PNG, Slide5.PNG, Slide7.PNG, Slide8.PNG, Slide9.PNG, Slide11.PNG, Slide2.PNG, Slide6.PNG, Slide10.PNG added
User avatar

We are not really fan of front/back split because they are often really tight and nourish themselves.

What we are used to do is:

  • Start with the front (because most of the time it will drive how users will use your feature)
  • find the minimal surface that does something (think in slices of features instead of layers) in front and back
  • if too big, start by the smallest thing you can do in front and do only that (hidden with a feature flag)

You could for instance start by having a fixed grace period "1 week" for instance, not configurable. With that, you could even implement most of the logic without having to deal with the multiple values. But I don't know if it's small enough.

And, in any case, as ususal, if there are refactoring needed to introduce the new features they must come first. That is to say, if you plan to modify a code that was not already ready to receive your modification, you need to make it ready to accept modification first without introducing new features.

User avatar

Hello, I would like to know what you think about the criteria to be used in dividing this story into multiple changes. The story as it is been developed now, consists of:

  • Back-end changes: adding a new table in the DB as well as its forge upgrade buckets, a DAO and a manager for clever reactivation and impacting clever reactivation on the code that suspends users (inactive users and non project members)
  • Front-end changes: modify the user details page to give the site admin the possibility of using clever reactivation when reactivating a user account. 

Is this dichotomy the best suited ? 

User avatar

Hello, 

I have a question: 

If I am to set the reactivation period for two users:

  • User 1: one week
  • User 2: 3 days

This information becomes a user-specific field. How will we store it in the DB?

 

User avatar

Just to let you know, you should not add new variables to local.inc, variables should be managed with `tuleap config-set` with values stored in DB nowaday.


  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
User avatar
Nouha Terzi (terzino)2019-08-27 16:42
  • I want to
    -Have a customisable reactivation period for the account reactivation 
    +Have a customisable reactivation period for the account 
  • Acceptance criteria
    Something went wrong, the follow up content couldn't be loaded
    Only formatting have been changed, you should switch to markup to see the changes
  • Attachments reactivate-user.png added
  • Checklist set to Does it involves User Interface? , Are there any mockups?