Description of problem: While users are now able to use UTF8 characters while assigning names to various resources, any link containing that name will have the UTF8 characters stripped from it. Version-Release number of selected component (if applicable): Nightly How reproducible: Always Steps to Reproduce: 1. Create a new Compute Resource (or anything that will have its name in the url) 2. Mouseover or copy and paste the link given to allow you to access or perform an action on the object you created. 3. Observe the URL Actual results: UTF8 characters are stripped from URL Expected results: UTF8 characters are included in the URL Example: Compute Resource name: asdasdѠѡѢѣѤѥѦѧѨѩѪѫѬѭѮasdasdasdѷѸѹѺѻѼѽѾѿ Resulting URL: ../compute_resources/37-asdasd-asdasdasd
Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
Connecting redmine issue http://projects.theforeman.org/issues/6710 from this bug
Moving to POST since upstream bug http://projects.theforeman.org/issues/6710 has been closed ------------- Tomáš Strachota The problem with not being able to edit unicode-named resources was fixed by <pre> commit 8b737c9c7648b3726dadb3b2e4708fcb43af02a8 Author: Joseph Magen <jmagen> Date: Tue Sep 23 12:02:52 2014 +0300 fixes #4386 - gem friendly_id to simplify find by id, name, label, etc </pre> which conflicted with my solution but was merged faser. I updated my PR and keep it open as it still makes the url look nicer (keeps unicode characters there) and fixes links in various ui templates. ------------- Anonymous Applied in changeset commit:e768c9761528c64fcc289c391091fcce63e82ff8.
verified on rhel6.5 and rhel 7 qe-foreman-rhel65.usersys.redhat.com-foreman-client-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-apache-1.0-1.noarch foreman-vmware-1.7.0-0.develop.201410232354git5e8706d.el6.noarch ruby193-rubygem-foreman-tasks-0.6.10-1.el6.noarch foreman-libvirt-1.7.0-0.develop.201410232354git5e8706d.el6.noarch qe-foreman-rhel65.usersys.redhat.com-parent-cert-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-foreman-proxy-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-qpid-broker-1.0-1.noarch foreman-release-1.7.0-0.develop.201410232354git5e8706d.el6.noarch foreman-compute-1.7.0-0.develop.201410232354git5e8706d.el6.noarch ruby193-rubygem-foreman_bootdisk-4.0.0-1.el6.noarch foreman-1.7.0-0.develop.201410232354git5e8706d.el6.noarch foreman-ovirt-1.7.0-0.develop.201410232354git5e8706d.el6.noarch foreman-selinux-1.7.0-0.develop.201410210825gitaab37c6.el6.noarch rubygem-hammer_cli_foreman_tasks-0.0.3-2.201409091410gitc96619d.git.0.37f3704.el6.noarch foreman-postgresql-1.7.0-0.develop.201410232354git5e8706d.el6.noarch foreman-gce-1.7.0-0.develop.201410232354git5e8706d.el6.noarch ruby193-rubygem-foreman_hooks-0.3.7-2.el6.noarch ruby193-rubygem-foreman_discovery-1.4.0-0.1.rc4.el6.noarch rubygem-hammer_cli_foreman-0.1.3-1.201410151235gitbc8c449.el6.noarch foreman-proxy-1.7.0-0.develop.201410221520gitccd77aa.el6.noarch qe-foreman-rhel65.usersys.redhat.com-qpid-client-cert-1.0-1.noarch qe-foreman-rhel65.usersys.redhat.com-puppet-client-1.0-1.noarch
This bug is slated to be released with Satellite 6.1.
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, 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-2015:1592