Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Posts

  • Joined

  • Last visited

  • Days Won


J.Drake last won the day on August 13 2020

J.Drake had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

J.Drake's Achievements


Explorer (4/14)

  • One Year In
  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done

Recent Badges



  1. Seems like a quickie. Just allow us to change more fields on the discharge screen. One that we constantly need to change now is combat position for example from fireteam member to civilian. Maybe there are more fields that could be changed too? Just a bit of a hassle to discharge someone and then still have to go into their entire p-file to change that field in particular when doing personnel updates in bulk.
  2. Ok understandable. The dev folder shouldn't contain anything "secret", it's simply what builds up all the XMLs and JSONs that are then used to load the default theme files, emails and translations in the database when you install the module or revert to the default templates. So that's why I brought up that we can get them anyway, it's just be much simpler if it could be shared so 3rd party developers can run a development IPS environment with PERSCOM installed & enabled. Now we constantly need to switch IN_DEV on to do our changes, build our app, turn IN_DEV off and then see if it worked if we're working on PERSCOM hooks for example. It's a major pain to debug. And yes, it's an IPS application, same as core, forums, pages and PERSCOM. So we can interact with everything on a deeper level and have our own controllers, templates, hooks, database schema, sources, settings,.......
  3. I assume you're talking about the REST API? Thus far we've always just edited the templates in our theme but we want to go way more in-depth, building an expansion of PERSCOM for our specific needs, working really closely with PERSCOM code. We already migrated a big chunk of our modifications to an application, but we've been holding off on those that require template modifications. So far, it's been smooth sailing with PERSCOM code and it's a lot more semantically correct, more maintainable and a lot more comfortable for a developer to work on. Our previous implementations used the REST API and hackish JavaScript implementations to achieve our goals, but as these modifications grew out of proportions we really needed a more solid foundation so we started developing our own application to fill the gaps. As far as my knowledge goes, the dev folder just holds all the files that you can find in the backend/theme area anyway. It could be extracted using something like the IPS Dev Toolbox but it seems like they're not entirely compatible with 4.6 yet as it's giving me some errors at the moment that I didn't have on 4.5 so I've had to disable that application. Getting it from the source, Deschutes, will probably be the most accurate anyway. So if you won't provide these files, we'll simply have to look at these alternative methods of extraction or manually convert what we can from the default theme. As for the licensing error. On the top of our development version (localhost) we have a banner notifying us we've got a limited PERSCOM development license and limits may apply. Which is fine, it's just for development, nobody but the developer will see that. We never entered any license and didn't copy the database. It's a completely fresh IPS install and fresh PERSCOM install. If it gives issues in 30 days, we can just repeat the process to refresh it I assume?
  4. Seems like everything is fine in terms of installing without a license, I just exported the application from our production and imported into my localhost dev environment. There's just one thing... We can't enable dev mode without having the PERSCOM dev folder. Is there any way we could get these files so that we can create hooks and interact with PERSCOM code while running IN_DEV = true?
  5. We would love to interact with PERSCOM inside of our application. Our application is developed locally, but on local installs the marketplace is disabled. Is there any way we can run PERSCOM locally so that we can use PERSCOM sources and so on to build on top of it? I suppose licensing would be another issue we'd run into if I were to just copy the PERSCOM application files from our production environment. Has anyone attempted this before? How would I go about getting the marketplace version of PERSCOM on our dev machines? Thanks in advance.
  6. @Jon Erickson we set it to 366 days and now it does show 1 year in the entry. So it is probably just a slight offset causing it.
  7. We set up automated Time In Service messages for people's 1 year anniversaries. However currently it constantly shows "11 months" in the user's service records instead of 12 months or 1 year or 365 days. Did we wrongly configure it for our requirements or is this a bug?
  8. I'm not sure if I got this correctly but I read on a different topic the activity tracker runs on a task that adds TIS/TIG every day. We currently have it set so for example LOA is a separated combat unit. Can the implementation not have a setting where certain combat units are blacklisted from receiving TIS/TIG? We currently have the same issue with both LOA and Retired personnel. Both are defined as "Combat Units" in PERSCOM.
  9. The same can also be done with custom pages/databases from the IPS Pages module.
  10. Thanks for looking into it! Do you know when it will be released? We're currently on 1.4.1 (marketplace) and don't have the option yet.
  11. Understood. Thanks for coming back to us about it. Perhaps if we all create enough support tickets with Invision they'd be more inclined to take a look at it ?
  12. We used copy to create a new field but instantly got a MySQL error stating that "Column 'personnel_field_x' already exists". Surprisingly the field was added though, so after seeing that error we deleted the field again and created a field from scratch. However because that copied field had a link to the column in perscom_personnel it deleted the original column. We had to partially restore the table from a backup to get back to where we were. Perhaps some defensive programming is required on this section, I suspect adding custom application fields is going to cause the same issue.
  13. Sorry for the extremely late response, we've just started running into it again, and I'd say the system works as indented but the user interface isn't clear at all. When you get the PERSCOM notification for not reporting in for X days, and you click it, it brings you to the operation center. Over there you must now click on a record on top of your report in history to complete reporting in. A lot of users expect to be able to press the "report in" button instead of having to go into their history and find the record with a different text. I'd suggest changing the report in button to not only filter by date, but also filter by reportin status. I've noticed that people with this error all have a reportin record with status 2. So some logic to make the report in button handle those with status 2, or ignore those with status 2.
  14. Has anyone been able to test/confirm PERSCOM's compatibility with 4.5? The 4.5 update appears to be mostly visual.
  15. Currently it is only possible to select 1 status for re-enlistment. We would like to have multiple statuses be able to re-enlist. I don't think it'd be a huge change?
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.