I have noticed that it is possible to re-open a closed RedMine issue when using one of the default trackers e.g. the "Defect" tracker. However, it appears that if you create your own tracker, it is not possible to open a closed issue. I believe I have checked "roles and permissions" but feel it is down to the tracker configuration.
Has anyone else noticed this and, if so, how have you overcome the problem?
In Redmine, when you login as admin, you will see Administration menu item, at top menu.
Once you click on it, besides Roles and permissions, which you tried to change, there is Workflows menu item, which lets you change issue transition statuses. It is possible that in your case, for Defect tracker, that issue cannot be re-opened.
Once you click Edit, you will be able to change that, here is how issue transitions look like in my case:
So, in your case, you will have to tick few boxes to allow issue to be re-opened, on your matrix.
Related
I'm following all the (easy) steps in the documentation, but I'm stuck at clicking the "CREATE" button. When I click it, the process runs for a few seconds, then the button re-appears, like I never clicked it.
If I go back to the "Managed Notebooks" page, no instance is present.
Am I missing something basic? Has someone the same problem as mine?
Don't know what it was, but today the issue seems resolved!
In one Dashboard that I inherited from a colleague, I see the following kind of tabs:
"meta" tabs that float above dashboard. Note that these are attached to the title element on the page.
On a new dashboard, I can't figure out how to replicate this arrangement. If I go into edit mode and add a "tab" component, it shows up below, "within" the dashboard like this. I want to replicate the first kind. Does anyone know how to do this?
there was a bug for a few weeks on master that disabled top level dashboard tabs but it's since been fixed.
What version of Superset are you using (if you're using a versioned release)?
I don't see a difference, simply that the first example has a lot more tabs while the second only has one tab, and the dashboard hasn't been saved with that one tab, so you can't see what is the selected tab yet.
I'm working on implementing a three step workflow for my company's Sitecore 8.2 installation.
Originally I had the final step set up to not have any action or command because we want to manually publish. But, manually publishing does not seem to remove the final workflow state.
Screenshot of the items workflow state after manually publishing
Then when I edit the item, it doesn't move back to the draft state. It's my understanding that when you publish an item that made it to the final workflow state version 1 is created, and editing that item should create a new version and restart the workflow. Is this correct?
After realizing that manually publishing does nothing, I tried setting up a command and action on the final workflow step:
Screenshot of final workflow step command & action
But this does nothing. Is it possible to set up a workflow action to publish? Or is the out of box auto-publish action the only option?
Why are the items getting stuck in this final step and how do I fix this?
Edit: The workflow was getting stuck because I am an admin. When using the roles I set up for Content Author and Approver, I was finally able to get the item to start version 2. I would still like to know if it's possible to set up a command and action to publish? Or is this not necessary if we want to manually publish anyway?
I think i know the issue. I had similar issue while setting up my sitecore workflow and i solved it with some changes in the security settings.
I wrote a blog just now about how to setup Sitecore Workflow. Here is the link for that:
https://tectraveleat.wordpress.com/2018/06/01/sitecore-workflow-setup-v8u2-v9-0-1/
In your case, since you have already setup everything. You might want to take a look at the "Assign security permissions to the roles" section of the blog.
Also, it is necessary to give the roles/users permissions to the datasource. From what i understand, you have setup everything properly, except a minor security permission at the workflow level.
Let me know if this helps. If not, can you share your workflow setup and permissions for the roles? I can take a look at it and see it i can help.
You can follow sample workflow of sitecore. Workflow publish state is final state. It can not move to draft. This process of workflow like this: Draft -> Approved -> Published. Workflow done at here.
If you wanna create version or make page to draft you have to edit it. If you still wanna your page published -> draft, you can custom pipeline of command in workflow. But this solution have many risks, I asked Sitecore support before and they answer it just their logic and you can custom if you want.
For last two updates of Glass (XE19.* and XE20*), whenever I load my Glass app onto a device it seems to get auto-deleted after a few hours. Has anyone else noticed this behavior and have a workaround to prevent it?
This question seems to indicate that if your apk has the same package name as one that is going through the review process, that it may be removed. Use a package name that is different or go through the review and whitelist process.
Update: The whitelist process allows you to permit a select group of people to be able to access the apks as you update them while they are being reviewed. You should be able to ask the review team about this once the process is underway.
What is the great motivation behind integrating Redmine with a source control repository ? If it is only for monitoring reason, developers already have access to repository and they can do whatever they want diff, history with their IDE. For other people do they really need? I'm afraid, I can't see the real reason. Can you please help me to see ?
When you fix a bug that exists in Redmine's issue tracker, you can refer to the issue id in the commit message and Redmine will automatically associate the commit with the issue (or even close the issue).
This saves you the double work of referring the issue in the commit message and closing the issue in Redmine.
By the way, this is not Redmine-specific - you can do it with most bug trackers that offer source control integration.
I don't remember the exact syntax in Redmine right now, but most of the time, the syntax is something like:
fixes #123
...which would cause Redmine to automatically close issue #123, and create a link from the issue to the commit (and vice-versa).