Scheduling the publication of Joomla Articles or Modules on certain dates and hours - joomla

How can I schedule Joomla Articles and Modules being published or unpublished on certain dates and hours? How can I repeat the publishing state hourly, daily, weekly, monthly, yearly?
Example: I have 4 articles on my Joomla site.
- I want to publish the "Article 1" and the "Article 2" only on week days and unpublish them on weekends.
- Also I want to publish the "Article 3" every day between 1:00 and 5:00 PM, and the "Article 4" publish it every Monday.

The Regular Labs Advanced Module Manager might help
With the pro version of the extension, you can publish / unpublish modules based on dates, times, and days of the week.
I can't think of an option to do the same for articles, but what if you had a few articles, with next to no content, just embedded modules? And these articles are always published.
Then you use the Regular Labs extension to manage the publishing and unpublishing of the modules on each page?
Good luck!

It is a good idea but not a perfect solution and the it cost's money.
For now I'll publish/unpublish the articles manually. Thanks a lot!!!

You can create a cron job using a joomla CLI application to set these for you.

Related

How to report on hours per period in Azure Devops?

I can't work out how to report how many hours per week were recorded by each team member.
For example if a task is 20 hrs, and 10 hours was done last week, and 10 this week, how can I tell how meany hours were recorded against the task each week?
I saw some time tracker plugins, they are not what I'm talking about. They require that the user start and stop time tracking kind of like upwork.
The developers already enter completed hours as they progress the tasks. So if devops remember the dates of each entry then I should be able to query how many hours were added this week, or month, or whatever per user per task.
Here is an excerpt from a discussion we had about it:
Meh, as far as Im concerned:
I make the tasks in notepad usually, so someone can add them to devops.
Someone adds them to develops.
The developers receive them in devops and record their status and times as they develop.
Devops doesnt seem to report on weekly times to us, so we ask the developers to write everything down in notepad or doc and pass us a
list or what they did with times.
We get the developers lists and use them to report to mgmt.
SO
What is the point of steps 2 and 3? May as well just pass the guys
their task in plain test list as I make it in notepad, it will be
easier for them to add their times and pass it back. For us devops is
just extra unwanted work while ever we cant work out how to report on
developer hours.
I think, you can use several ways:
Way 1. Use PowerBi reporting.
Each developer updates work hours every day.
You can use Analytics view to get task history:
Add Completed work to this view.
Connect to Analytics with Power BI Data Connector. Then you can find revisions for each tasks and calculate hour difference
Way 2. Customize your process template.
Add to your process template new work item type (like Time or Activity). Add to these work items new field (like Activity date) or use existing field Target Date. Add to these work items the Completed Work field. Add a custom work item type, Add a custom field to a work item type.
You developers add a new Time work item as child work item to their task and update the Completed Work field. You can use work item queries to see time updates.
TimeTracking in Azure Devops is pain. We have developed our custom solution to track time in DevOps. You can install extension https://marketplace.visualstudio.com/items?itemName=Sense4code.Sense4code-Manday. For more info you can visit also https://www.manday.io/doc/azure-devops-getting-started for more info.

How to set up reminders to complete tasks in VSTS

Is anyone able to suggest the best way to set up a recurring reminder within a VSTS (Visual Studio Team Services) project? I want it to act like an Outlook Calendar recurring reminder that the whole team gets once per week.
I've looked at creating a Story / Epic / Feature and trying to assign a recurring team reminder to that but can't see a way to do it. The task concerned would be ongoing so in an ideal world of someone new to VSTS, I'd create one of the aforementioned things, set a recurring reminder on it, the team do the task when the reminder comes up and add a note. And that continues until we switch it off.
I've had a look online but can't find anything as yet.
The best thing that comes close is a dashboard widget that uses #me in its query.
VSTS doesn't have a scheduled reminder or alert system.
You can probably cobble something together using the REST API and a scheduled build. Calling a work item query and sending email is pretty easy from PowerShell.
As jessehouwing said that you can do it through Scheduled build, there are some extensions related to email in VSTS marketplace, such as Send Email.
On the other hand, there is Outlook add-in extension: TeamCompanion For Outlook.

How to add actual time taken to finish a task or a story in Visual Studio Team Services?

I am working on scrum with VSTS(Visual Studio Team Services)
I am able to add estimated effort to backlog items as well as estimated hours to different tasks.
I was wondering if there is a way that allows me to add the actual time taken to finish a specific task. So that I can later have a report or so to see the difference between estimation and actual in order to enhance the team estimation.
Not in the SCRUM Template. That template is all about remaining time. I believe the AGILE Template will let you enter original estimate, remaining time and time spent. So perhaps look into that.
Failing that, you could use an add-on. Have a browse of the Visual Studio Marketplace
This one looks like it might work for you: TFS Time Tracker
Completed Work field is only available for the Agile Template. I believe you can still create a custom template to be able to configure fields in the default template (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-field).
However, VSTS is probably not intended for time tracking. You can try and use time sheet extensions to VSTS.
For example, TFS timesheet (https://www.teamexpand.com/product/tfs-timesheet) allows inputting hours directly from a Work Item tab and generate detailed reports that show how many hours were spent to complete a task with a day-by-day breakdown. It also allows to keep track of actual time vs. estimated time.

Google play publish again

I have uploaded my apk-file as release version and published it. After some time(half day) I unpublished it to fix something. Now, 1 week later, I want to publish it again.
Would it affect promotion? I heard that "new, just published" applications have more chances to get to top apps list.
So, if I publish my application again, it would be "new app", or only first publish considered?
I have not noticed any "penalty". Amount of installs per day grows as it was in first time.

Work log in JIRA for daily meetings, retrospectives and specifications [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I hope that somebody with more experience (bad or good) can help me out here: I am setting up a project tracked in JIRA. The whole process with user stories, documentation, sprints, workflows, bamboo and fisheye integration, etc. is set up. But now I have a rather administrative question:
Where should developers log their work in meetings, such as stand-ups and retrospectives and for writing specifications (detailed descriptions of user stories to come)? I really cannot see what makes sense here, as I need the developers (obviously) to track this work, too. As far as I can see, the possibilities are:
Separate PROJECT-ADMIN JIRA project with simple, non-agile issues
Separate and parallel sprint with admin tasks
Administrative tasks for each sprint
Other versions??
Option 2 seems very hackish, as parallel sprints are just in a beta-stage for the JIRA agile (former Greenhopper) module. Option 3 seems a bit much work to setup for each sprint, and I am not sure, how this influences my velocity (ideally, I want to see the possible amount of story points that can be achieved in a sprint). Option 1 seems the most reasonable to me, but others have advised against it, unfortunately, without offering a solution. I haven't really looked into option 4, as IMHO this is very similar to option 2.
I couldn't see any best practices anywhere, so I would very much welcome any advice from more experienced people. Thank you very much.
We use Tempo to log our billable work against JIRA issues, whether a single Epic for a small project or individual tasks for a larger project. For non-billable work we have a single project where people can optional log work, and we also use it for planning our time. So option 1 is the closest there. We could also have categories for different work logged in Tempo and handle this case that way.
So I face this exact issue with my team and this is what is working for us (for now) YMMV.
Our current structure is that we have a Roadmap type project (call this Planning) where all issues come into at first. Thereafter we create issues in related product projects (call this Product).
In the beginning of the lifecycle, any meetings, scoping, etc will have sub-tasks created and the time will be tracked on Planning. Once scoped and scheduled for work a new issue is created on Product and linked to this original issue.
Once the Product issue is assigned and the dev is called to any meetings whilst this issue is in a sprint we will create a sub-task on Product and assign the time. If the issue is not in a sprint we go ahead and create a new sub-task in Planning and assign the time there.
When then also have a project where we do Housekeeping type work. So if we need changes to JIRA, Stash, Confluence we will create the issues here. We will then create a new issue on Planning, link the issue and schedule that accordingly.
We have a meta project that acts as a bucket for anything that doesn't fall into the other categories which we sift through every now and again to identify if we need to create separate projects.
I have created a custom field that rolls up all the times of any linked issues found on the Planning board
Have a look at the Twitter blog Visualizing Epics and Dependencies in JIRA by Nicholas Muldoon maybe this can help you in some way too.
One caveat we are still exploring the best way to do this. Each environment is different and what works for us might not work for you.
I have faced the same issue trying to track team member hours that are unrelated to the project or related to the project but not to a specific story or task.
Initially we went with option 3 & had several administration tasks that persisted across sprints. While this was relatively easy to implement it failed for us as we had team members that sat across multiple projects & as a result these administrative tasks that resided in each project were impossible to manage / report on for these team members.
In the end we went with what you have described as option 1. By creating a separate project with "non task related" issues such as Planning Meetings, Technical Issues & Client work then installing the JIRA Misc Time Log & Report Extensions plugin we could provide users with an easy means of logging times without having to change projects or boards (since the plugin adds a dropdown menu to the top navigation).
The plugin then allowed us to get reports on where team members we logging time off project regardless of how many projects they worked on concurrently.
I was having the same issue, and I know some time has passed since the moment this question was posted but maybe this is useful for a lot of people:
Tempo has a dedicated feature for that thing you want to achieve and is called Internal Issues. not to be confused with Internal activities.
You can go there by navigating to Config>System and then click on the add-ons tab. Then scroll down to the Tempo section in the menu on the left bar and there you'll find a link that reads Internal Issues. There you can create the issues. Please keep in mind that before creating internal issues you have to create the tasks, for instance "Sprint Planning" or "Retrospective" in the project without assigning to anyone, just to the project.
When your users go to log their time for those "Internal Issues" they go to Tempo > Timesheets and then click in the upper right button that reads log work. There, in the right menu they'll see the "internal issue" option where they can pick those internal issues you previously created and log the time that the team spend on SCRUM Ceremonies.

Resources