Add hyphens to add-member and remove-member occ group commands

[phil-davis]

Description

Put hyphens in the group:add-member and group:remove-member occ commands.

Related Issue

#20629

Motivation and Context

Other occ commands use hyphens between words. It is better to be consistent, and to change this now, before it gets released into userland.

How Has This Been Tested?

To group:add-member and group:remove-member occ commands in a test system.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality) (non-breaking because the first implementation has not been released yet)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

Doc PR owncloud-archive/documentation#3201 updated.

[phil-davis]

Backported to stable10 PR #28321

[phil-davis]

How did I break Jenkins?
The log has a test failure:

    Then as "user1" gets properties of folder "/merge-test-outside-groups-renamebeforesecondshare-renamed" with                                        # FeatureContext::asGetsPropertiesOfFolderWith()
      | {http://owncloud.org/ns}permissions |
    And the single response should contain a property "{http://owncloud.org/ns}permissions" with value "SRDNVCK"                                       # FeatureContext::theSingleResponseShouldContainAPropertyWithValue()
      Cannot find property "{http://owncloud.org/ns}permissions" with "SRDNVCK" (Exception)
    And as "user1" the folder "/merge-test-outside-groups-renamebeforesecondshare" does not exist                                                      # FeatureContext::asTheFileOrFolderDoesNotExist()

in scenario at https://github.com/owncloud/core/blob/master/tests/integration/features/sharing-v1.feature#L914
@SergioBertolinSG do you have any idea why this can fail?

[SergioBertolinSG]

Just rebase, it needs #28310 .

[phil-davis]

It tells me that it is already up-to-date. So I did some "double-rebasing" over to #28312 and back to master.
That has managed to add the 3 commits from #28312 to here - but that will do no harm, they will disappear from here once #28312 is merged.

[DeepDiver1975]

@phil-davis did you merge commits in here from #28312 by intention?

[phil-davis]

I needed to rebase to force Jenkins to run again. And it said my branch was up-to-date. So I rebased across to that other PR and back, which results in the 3 extra commits.
I see you merged the other PR just now, as I am typing. So this one will just happily merge in on top of it, with just the 2 "real" commits.
It is anoying trying to work out how to force Jenkins to do another run.

[DeepDiver1975]

It is anoying trying to work out how to force Jenkins to do another run.

for the time being: ping me to retrigger builds

[DeepDiver1975]

I see you merged the other PR just now, as I am typing. So this one will just happily merge in on top of it, with just the 2 "real" commits.

will you cleanup the commit history then?

[phil-davis]

I could, but actually I don't think it matters. git and GitHub are smart enough to not repeat the 3 commits here that are now already in master.

[DeepDiver1975]

I could, but actually I don't think it matters. git and GitHub are smart enough to not repeat the 3 commits here that are now already in master.
Merge state

those 3 are not in master - but one which is the squashed version - githib cannot resolve this.

[DeepDiver1975]

Backported to stable10 PR #28321

please let's do the backports AFTER merging into master - keeping branches in sync is too much work and causes confusion - THX

[DeepDiver1975]

let me fix that all quickly for you ...

[phil-davis]

Thanks, I was looking at how to get rid of those 3 commits - now I don't have to.
It will be nice if CI runs reliably one day. At the moment it requires interrupting train-of-thought to go back and check on PRs to see if some CI thing went wrong, then work out how to get it going again, then another 2 to 3 hours later check again...
That is why I had made the backports as soon as the code was approved. That gets the CI chugging away.

[DeepDiver1975]

It will be nice if CI runs reliably one day.

this is what we are working on ....

[phil-davis]

Backport to stable10 #28332

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.