nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Renaming Site url/shortname causes Authority Not Found error

cybertoast

When creating a site in /share and renaming it in /alfresco there's an inconsistency introduced in the site's group. For example, if a site is created in Share as SiteA, alfresco creates a user group called SiteA which has implicit site-manager roles. If the site is then renamed to SiteB from /alfresco's management interface, the group remains the same, but the site's URL changes. But when retrieving sites using the API call remote.call('api/sites'), I get the error:

org.alfresco.repo.security.authority.UnknownAuthorityException: 01010007 An authority was not found for GROUP_site_siteb_SiteManager
‍‍‍

But I don't seem to have a way to rename the URL through /share API.

Steps to reproduce:
* Create a new Public site in /share - Title = Site A, URL = SiteA
* Go to /alfresco as admin (or site creator)
* Change the "Name" value of the site (Company Home -> Sites -> SiteA -> Modify) to SiteB
* Create a dashlet in /share that retrieves a list of all public sites:

result = remote.call('/api/sites?');
‍‍‍

* Result will contain the exception message above.

Is there an API call to both rename a site's short-name and set the appropriate internal Groups? Or is there a way to rename the group in /alfresco so that I can avoid this problem? Or am I just going about this the wrong way?

Find more posts tagged with

Comments

cybertoast

The same error occurs if I rename the site using WebDAV as well.

mrogers

I don't think you should be able to change the "shortName". If there's something attempting to do that then that is going to cause problems.

cybertoast

But the short-name is not just an internal representation of the site - it's actually visible to the outside world through the URL and through WebDAV. So if we have a project-name that changes (and we tie Sites to Projects) then we need to be able to rename the Site. This is a pretty common occurrence and I believe a standard workflow.

The "shortname" is allowed to be changed in WCM (/alfresco) so I would think that this is a permitted action for Share as well. What I don't understand is how the Group assigned to a site is hard-tied to a site's shortname and there's no way to change this.

From your response mrogers, it seems that this restriction on renaming URL/shortname/Name is by design. But could you please clarify what "If there's something attempting to do that then that is going to cause problems." means? Are there other features that expect the shortname/Group to be tied together?

mikeh

I'm guessing it's you who has just raised this in JIRA as a "critical" bug: http://issues.alfresco.com/jira/browse/ALFCOM-3800

I'll paste my response here:

Renaming a Site is -as you've discovered- unsupported currently. You can rename the Site's name and description through the Share UI, but not the URL.

More importantly, modifying ANY Site parameter via the Explorer ("/alfresco") web client is very risky and can cause all sorts of problems; which is why we present the yellow warning banner across that client when browsing within the Sites space or subspaces.

Having said that, you could probably programatically rename the existing Site groups if you did want to rename a Site's shortName, however we really wouldn't recommend this.

Whether you *should* be able to change a Site's url is debatable: all existing links to content within that site (whether on an external system or simply bookmarked by your users) will break. If you really must be able to change the URLs frequently, I'd suggest proxying Share's Tomcat server with an Apache server; that way you can introduce rewrite rules to modify the URL as you wish without having to worry about any other factors.

Thanks,
Mike

mrogers

Yes you are approaching it incorrectly - you should assume that the site's "short name" cannot be changed.

cybertoast

Thanks much. Just something I was not aware of and something I need to keep in mind when dealing with ongoing administration (particularly for WebDAV access).
Is there a webscript/api call to programmatically rename the existing Site groups?

mrogers

No. That's one of the reasons you can't rename a site. If you have renamed a site then I suggest you change it back.

cybertoast

Is there any way to have WebDAV use the Title instead of the shortname? Since both are "served" by Alfresco is this configurable?

andnyg

Of course it must be possible to change the short name of the site. There must be some kind of technical challenge that makes this hard to implement for the developers. Changing URLS is of course something you should avoid, but that must be up to the administrator of the site or server. Not very flexible otherwise.

joe_l3

Hi all,

the same error using CIFS :!:
Here my JIRA comment (http://issues.alfresco.com/jira/browse/ALF-1522) :

I found the same error on my stacktrace renaming site via CIFS (Alfresco 3.3 Community).

Steps to Reproduce:
* Log into Share as any user
* Create new Site, with Title = New Site, URL = newsite, PUBLIC
* Log in to alfresco CIFS as admin
* Go to Sites folder
* Rename folder "newsite" to "newersite"
* Log into Share as admin and
* Go to "search sites" form and click search button

java backtrace for programmers:
———-
……….
Caused by: org.alfresco.repo.security.authority.UnknownAuthorityException: 07050041 An authority was not found for GROUP_site_newersite_SiteManager
at org.alfresco.repo.security.authority.AuthorityDAOImpl.getContainedAuthorities(AuthorityDAOImpl.java:412)

Any news?

mrogers

No news - you still cannot change the site shortname.

There's an open enhancement request.

The enhancement request has zero votes at the moment.

sankatha

I'm guessing it's you who has just raised this in JIRA as a "critical" bug: http://issues.alfresco.com/jira/browse/ALFCOM-3800

I'll paste my response here:
Renaming a Site is -as you've discovered- unsupported currently. You can rename the Site's name and description through the Share UI, but not the URL.

More importantly, modifying ANY Site parameter via the Explorer ("/alfresco") web client is very risky and can cause all sorts of problems; which is why we present the yellow warning banner across that client when browsing within the Sites space or subspaces.

Having said that, you could probably programatically rename the existing Site groups if you did want to rename a Site's shortName, however we really wouldn't recommend this.

Whether you *should* be able to change a Site's url is debatable: all existing links to content within that site (whether on an external system or simply bookmarked by your users) will break. If you really must be able to change the URLs frequently, I'd suggest proxying Share's Tomcat server with an Apache server; that way you can introduce rewrite rules to modify the URL as you wish without having to worry about any other factors.

Thanks,
Mike

Same thing happens when you try to add a new role to sitePermissionDefinitions.xml for an existing site

mrogers

site rename is not supported.

sankatha

Hi mrogers

I get the same error when I create some custom roles on existing sites via sitePermissionDefinitions.xml. I know it may not related to the same issue which was discussed here but thought worth raising it up.

Every time this happens I have to delete the whole site and re-import my data and it all works fine after that. About to report it as a bug because I cant find any relevant information regarding this. Any thoughts of yours will be greatly appreciated.

Thanks

mrogers

There's a crude but effective fix working its way through the pipeline to prevent rename of the site through CIFS / Explorer etc.

Please raise your new issue in JIRA with as much details as possible (That means more than you posted here!)

kamielvdz

Hi mrogers

I get the same error when I create some custom roles on existing sites via sitePermissionDefinitions.xml. I know it may not related to the same issue which was discussed here but thought worth raising it up.

Every time this happens I have to delete the whole site and re-import my data and it all works fine after that. About to report it as a bug because I cant find any relevant information regarding this. Any thoughts of yours will be greatly appreciated.

Thanks

I had the same problem. The cause is similar and related to the above problem.

Upon site creation a number of group Authorities are created that are used for this site. E.g. GROUP_site_mynewsite_SiteCustomManager.

If you add a new permissionGroup in sitePermissionDefinitions.xml this authority does not get created automatically and the errors start appearing everywhere. So either you try and add this authority yourself in some way or you have to recreate your site like you suggested.

I hope the next version will be able to create these authorities 'on the fly'.

mrogers

There will be no changes unless they are logged in JIRA. Please make sure your issue is in JIRA, or even better contribute an enhancement.

kamielvdz

There will be no changes unless they are logged in JIRA. Please make sure your issue is in JIRA, or even better contribute an enhancement.

Ok, added to JIRA with possible enhancement. New to alfresco so not comming change unless validated/checked.

mvanle

When I want to rename a site's URL (shortname), I do the following workaround:

1. In Alfresco Share, create a new site with the desired URL name2. Delete all subfolders in the new site3. Click on "Repository", and navigate to Repository->Sites-><Old URL>4. Click the "Select" drop down box, and select "All" to select all folders5. Click on "Selected items …" and select "Copy to …"6. Select the new site's folder (ie. URL (shortname)) and click "Copy"You will need to reconfigure your dashboards.

Not sure if the above workaround will work for large complex sites.