One of very good examples would be the fact that We need to refer to https://access.redhat.com/solutions/6663481 in the hotfix instructions for BZ https://bugzilla.redhat.com/show_bug.cgi?id=2103522#c39 

And there are many example BZs present for Sat 6.10 i believe where users are required to republish repository\content-view version metadata to fix\workaround certain bugs. 

So unless, There are some really obvious reasons + technical blockers, that why 

* We stopped providing the UI actions 
* We don't provide any hammer option to republish individual repository metadata

We should consider bringing those features back in future releases to deliver a positive customer experience.

The UI actions were removed because regenerating repository metadata can be destructive if you use a certain mirroring policy, I believe.

In https://projects.theforeman.org/issues/34762 we added a `hammer repository republish` command to make things a bit easier.

We could think about adding the feature back to the UI, but it would have to take into account the dangers.

Link to upstream discussion with some more context: https://community.theforeman.org/t/katello-4-3-cannot-republish-repository-metadata-or-view-packages-of-a-repository/27045/8?u=jeremylenz

While the discussion makes sense, We are still only considering just the one mirroring policy here. 

There could be a number of situations where a repo metadata regeneration could be needed ( specifically the ones needing a hotfix to fix a few stuff and then republish the repodata ) and we need to rely on API or rake ( and in some cases hammer ).

The fact that we do provide the hammer way, should pose the same danger as the UI way since they are triggering the same action. So hiding\removing the option from UI is doing no good here if customers are anyway using the CLI options. 

It's simply my perspective but I will leave this to the dev-team .

I can see "hammer repository republish" in Satellite 6.12 , So that's much better than using the API.

*** Bug 2186276 has been marked as a duplicate of this bug. ***

For this issue, I think the right approach would be to allow the republishing again from the UI, but disable it for "complete mirror" repositories because the metadata should be a 1:1 with the repository and hence a "regeneration" is unneeded. Plus, if the metadata is regenerated, the repository is no longer a complete mirror of the upstream.

One tricky corner case that we discussed is the following: if a user has a non-filtered content view version with a repository that was "mirrored completely" and they change the library repository to no longer be mirrored, Katello will lose all track of whether or not that CVV repository was mirrored. At that point, we would have to assume that the CVV repo could have its publication regenerated. That would mean that old CVV repos would be changing from mirrored to "pulp generated".

I'm worried that users may regenerate the publication and then wonder why their old CVVs suddenly are behaving differently. Perhaps we could gate it with a "this could be dangerous, make sure you understand the consequences".

Knowing that this this will occur potentially to content view repositories, is this okay? Alternatively, if we're gating the feature with a warning, should we always allow them to regenerate publications even when they were mirrored?

While the suggestion makes sense and so as the other facts pointed out, I believe we are thinking in a bit wrong direction. 

It's not that what you are suggesting is not happening today. When it's needed or suggested by RedHat for something or googled for an RH KB to solve any package count issue, The end-users end up using hammer\API to perform metadata regeneration of content-view versions or repositories. 

So the problem you are pointing out is applicable even without having the GUI option present and that should not fall in the scope of this BZ. It should be a completely different RFE that includes the suggested WARNING in hammer\API\WebUI no matter who triggers that task.

All I had requested about this BZ was to bring back the UI option to do the metadata republish as that is far easier for an end-user to use instead of hammer\API.

Created redmine issue https://projects.theforeman.org/issues/36417 from this bug

> All I had requested about this BZ was to bring back the UI option to do the metadata republish as that is far easier for an end-user to use instead of hammer\API.

Okay. We decided we will bring it back to the API, but will disable it for repositories that use complete mirroring (you'll still have to use API/Hammer for that.)

sorry, I meant bring it back to the Web UI

Opened https://bugzilla.redhat.com/show_bug.cgi?id=2208535 as a followup

*** Bug 2211489 has been marked as a duplicate of this bug. ***

Verified 6.14.0 snap 1

Republish Metadata for a single repository:
1. Create a product, sync one or more repos.
2. Navigate to the info page for an individual repo.
3. The 'Select Action' dropdown contains the option to 'Republish Repository Metadata'.

Republish Metadata for all repositories in a ContentView Version:
1. Create a product, sync two or more repos.
2. Create a content view, assign the synced repos, and publish a new version.
3. Navigate to the Versions tab of the ContentView.
4. Next to the 'Promote' button, the triple colon widget contains the option 'Republish Repository Metadata'.

Expected and actual results:
The republish task is started and completed without issue.
Only the repository or CV repositories used to initiate the action have their metadata republished.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Satellite 6.14 security and bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2023:6818