When 'master' replication is enabled, the 'Replication Changelog' tab is not updated. Can we trigger an update there?

Console error:

1. Enable Master replication;
2. Create an agreement with a name 't02' (not sure if it's related);

3. Try to init the agreement (probably something wrong with a agreement name):

   Uncaught TypeError: cmd.startsWith is not a function
   at log_cmd (index.js:181209)
   at ReplAgmts.initAgmt (index.js:172781)
   at HTMLUnknownElement.callCallback (index.js:107984)
   at Object.invokeGuardedCallbackDev (index.js:108034)
   at invokeGuardedCallback (index.js:108091)
   at invokeGuardedCallbackAndCatchFirstError (index.js:108105)
   at executeDispatch (index.js:108396)
   at executeDispatchesInOrder (index.js:108415)
   at executeDispatchesAndRelease (index.js:108515)
   at executeDispatchesAndReleaseTopLevel (index.js:108523)

@spichugi - fixed repl agmt issue issues, please review...

1. Okay, once again Cockpit has updated the UI and some of the alignment is broken (most of the Replication tab). I think we should fix it in some other PR and then rebase this PR... Or we can fix it here. It's up to you...
   Either way, it is broken now (you saw it on a scrum)

2. Enable Replication modal window:
   It states that either Bind DN and password OR Bind Group DN should be chosen.
   I think it should be clearly distinguished input wise. Maybe we can have it in different columns? Or we can grey out one of them if another has input... Either way...
   Now it just is not obvious for the user which one will be used when he hits the Enable Replication button.

3. The console has some errors in it:

   [DOM] Found 10 elements with non-unique id #pagination-row-dropdown: (More info: https://goo.gl/9p2vKq)
   <button id=​"pagination-row-dropdown" role=​"button" aria-haspopup=​"true" aria-expanded=​"false" type=​"button" class=​"dropdown-toggle btn btn-default">​…​
   </button>​ <button id=​"pagination-row-dropdown" role=​"button" aria-haspopup=​"true" aria-expanded=​"false" type=​"button" class=​"dropdown-toggle btn btn-default">​…​</button>​
   

   I haven't seen it before. Could it be related to this PR?
   It has appeared when I've opened Replication tab and then pressed Enable Replication button.

4. I think it makes sense to add some note or a hint to the Export LDIF button. The hint which points to the menu where we can restore from the LDIF. Not it is not connected by any words and it is a bit confusing. (later we can add a hyper link to another component and refresh the list of LDIFs - when we'll have the full react)

5. I press Disable Replication button but the content stays the same after the loading is finished (I didn't have any agreements to begin with. I've tried to disable it just after the enablement). If I try to disable it again - the button just doesn't react.

6. The [5] issue has appeared because I wanted to change replica ID. And it is impossible (I forgot to set it to another number). Additionally, can we remove the default RID from the field? It highly possible that the user will forget to change it while creating and then he will need to set once again and it can create a mess (if it is done too late in the Replication setup)

7. Error updating replication configuration - Server is unwilling to perform - Invalid value for nsds5ReplicaPreciseTombstonePurging: true Value should be "on" or "off"

8. I've tried to change the Changelog fields with some dummy values and it went bad:

       CMD: saveSettings: Applying replication changelog changes ==> dsconf -j 
           ldapi://%2fvar%2frun%2fslapd-master1.socket replication set-changelog --max-entries=1222 --encrypt=true
           cockpit.js:589 usage: dsconf [-h] [-v] [-D BINDDN] [-w BINDPW] [-W] [-y PWDFILE] [-b BASEDN]
                     [-Z] [-j]
                     instance
           dsconf: error: unrecognized arguments: --encrypt=true
           p @ cockpit.js:589
           m @ cockpit.js:599
          v @ cockpit.js:494 
           a.onmessage.o.dispatch_data @ cockpit.js:424
           e @ cockpit.js:280
           postMessage (async)
           (anonymous) @ index.js:11
           a.onmessage.o.dispatch_data @ cockpit.js:422
           VM524:1 Uncaught SyntaxError: Unexpected token u in JSON at position 0
             at JSON.parse (<anonymous>)
           at Function.<anonymous> (replChangelog.jsx:191)
           at s (cockpit.js:962)
           at cockpit.js:974
           at n (cockpit.js:880)
   

Okay, once again Cockpit has updated the UI and some of the alignment is broken (most of the Replication tab). I think we should fix it in some other PR and then rebase this PR... Or we can fix it here. It's up to you...
Either way, it is broken now (you saw it on a scrum)

Yeah "hr" and some headings have different css now :-(

Enable Replication modal window:
It states that either Bind DN and password OR Bind Group DN should be chosen.
I think it should be clearly distinguished input wise. Maybe we can have it in different columns? Or we can grey out one of them if another has input... Either way...

But you can set both. It's not one or the other. IPA uses both for example. Not sure how to make it "cleaner"

Now it just is not obvious for the user which one will be used when he hits the Enable Replication button.

The console has some errors in it:
[DOM] Found 10 elements with non-unique id #pagination-row-dropdown: (More info: https://goo.gl/9p2vKq)
​…​
​ ​…​​

Right this a patternfly thing - nothing we can do about it

I haven't seen it before. Could it be related to this PR?
It has appeared when I've opened Replication tab and then pressed Enable Replication button.

I think it makes sense to add some note or a hint to the Export LDIF button. The hint which points to the menu where we can restore from the LDIF. Not it is not connected by any words and it is a bit confusing. (later we can add a hyper link to another component and refresh the list of LDIFs - when we'll have the full react)

Right, nothing we can do about it now, but I'll update the hint/title.

I press Disable Replication button but the content stays the same after the loading is finished (I didn't have any agreements to begin with. I've tried to disable it just after the enablement). If I try to disable it again - the button just doesn't react.

After fixing a reload issue I can not reproduce this.

The [5] issue has appeared because I wanted to change replica ID. And it is impossible (I forgot to set it to another number). Additionally, can we remove the default RID from the field? It highly possible that the user will forget to change it while creating and then he will need to set once again and it can create a mess (if it is done too late in the Replication setup)

Well I want to use a "number" input field so no one can enter invalid values. I'm not sure what your concern is here though. If you enter the wrong rid yes you must start over. But the default value is fine. You can have different backends use the same same rid. It's the remote replica that can not reuse a rid for the same suffix. I see no easy way to pick a "better" default RID.

Error updating replication configuration - Server is unwilling to perform - Invalid value for nsds5ReplicaPreciseTombstonePurging: true Value should be "on" or "off"

I've tried to change the Changelog fields with some dummy values and it went bad:
CMD: saveSettings: Applying replication changelog changes ==> dsconf -j
ldapi://%2fvar%2frun%2fslapd-master1.socket replication set-changelog --max-entries=1222 --encrypt=true
cockpit.js:589 usage: dsconf [-h] [-v] [-D BINDDN] [-w BINDPW] [-W] [-y PWDFILE] [-b BASEDN]
[-Z] [-j]
instance

    dsconf: error: unrecognized arguments: --encrypt=true
    p @ cockpit.js:589
    m @ cockpit.js:599
   v @ cockpit.js:494 
    a.onmessage.o.dispatch_data @ cockpit.js:424
    e @ cockpit.js:280
    postMessage (async)
    (anonymous) @ index.js:11
    a.onmessage.o.dispatch_data @ cockpit.js:422
    VM524:1 Uncaught SyntaxError: Unexpected token u in JSON at position 0
      at JSON.parse (<anonymous>)
    at Function.<anonymous> (replChangelog.jsx:191)
    at s (cockpit.js:962)
    at cockpit.js:974
    at n (cockpit.js:880)

Ahh, yeah encrypting the changelog is not implemented in dsconf yet. I'll remove the option from the UI

Well changes made, please review...

It states that either Bind DN and password OR Bind Group DN should be chosen.
I think it should be clearly distinguished input wise. Maybe we can have it in different columns? Or we can grey out one of them if another has input... Either way...

But you can set both. It's not one or the other. IPA uses both for example. Not sure how to make it "cleaner"

Okay, can we then update the text in the modal window? It's a bit confusing because it says or... Or I misunderstood something.

Well I want to use a "number" input field so no one can enter invalid values. I'm not sure what your concern is here though. If you enter the wrong rid yes you must start over. But the default value is fine. You can have different backends use the same same rid. It's the remote replica that can not reuse a rid for the same suffix. I see no easy way to pick a "better" default RID.

I was thinking about setting some 'blank' value there. Maybe 0 then? So the user is forced to update it.

I'll finish the review tomorrow morning!

It states that either Bind DN and password OR Bind Group DN should be chosen.
I think it should be clearly distinguished input wise. Maybe we can have it in different columns? Or we can grey out one of them if another has input... Either way...
But you can set both. It's not one or the other. IPA uses both for example. Not sure how to make it "cleaner"

Okay, can we then update the text in the modal window? It's a bit confusing because it says or... Or I misunderstood something.

It can be cleaned up, but I wanted you to know that having one or the other or both is acceptable.

Well I want to use a "number" input field so no one can enter invalid values. I'm not sure what your concern is here though. If you enter the wrong rid yes you must start over. But the default value is fine. You can have different backends use the same same rid. It's the remote replica that can not reuse a rid for the same suffix. I see no easy way to pick a "better" default RID.

I was thinking about setting some 'blank' value there. Maybe 0 then? So the user is forced to update it.

Well with the "number" input field they want a min and max value. So it sort of needs to be 1 through 65534. Like I said it really doesn't matter what it defaults too. Most customers only replicate one backend anyway. Even if you have 10 backends, they can all use rid 1 if they want to. You just can't have multiple masters for the same suffix using the same rid. Seems overkill to try and query all the masters recursively to provide a valid range across the topology when enabling replication on a suffix in the UI.

Well with the "number" input field they want a min and max value. So it sort of needs to be 1 through 65534. Like I said it really doesn't matter what it defaults too. Most customers only replicate one backend anyway. Even if you have 10 backends, they can all use rid 1 if they want to. You just can't have multiple masters for the same suffix using the same rid. Seems overkill to try and query all the masters recursively to provide a valid range across the topology when enabling replication on a suffix in the UI.

Okay, agree! Probably I am overthinking the subject...

So about a few issues I've found:

1. While trying to set `Fast Tombstone Purging':

   Uncaught TypeError: config.attrs.nsds5replicaprecisetombstonepurging.lower is not a function
   at Function.<anonymous> (index.js:184254)
   at s (cockpit.js:962)
   at cockpit.js:974
   at n (cockpit.js:880)
   

2. Winsync agreements initialization suffer from the same issue that was fixed for our agmts...

   Uncaught TypeError: cmd.startsWith is not a function
   

3. When I try to demote master to consumer it demotes it but the error is displayed - {"desc": "bad operand type for unary +: 'str'"}

Aand I think that's it. Other stuff works and looks good!

@spichugi - committed next round of fixes, please review...

LGTM! Ack

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3728

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.